Perhaps the funniest/scariest snippet of the article is a chat transcript:
[03:31:27] <2/1BDE_BAE_FSE> IMMEDIATE Fire Mission, POO, Grid 28M MC 13245 24512, Killbox 32AY1SE, POI GRID 28M MC 14212 26114, Killbox 32AY3NE, MAX ORD 8.5K
[03:31:28] <CRC_Resolute> 2/1BDE_BAE_FSE, stby wkng
[03:31:57] <CRC_Resolute> 2/1BDE_BAE_FSE, Resolute all clear
[03:32:04] <2/1BDE_BAE_FSE> c
[03:41:23] <2/1BDE_BAE_FSE> EOM
[03:41:31] <CRC_Resolute> c
It's a like a normal botnet, except it's commanding our troops.
I thought it would be cool to do something like this as a hackathon project proof-of-concept; apparently I'm too late. Doing something like this for civil defense purposes would be pretty cool.
The funny bit is that it is almost exclusively referred to as "mIRC chat."
I don't know how extensively it is used elsewhere, but IRC is considered a primary communications method (and often the preferred vs. land lines, sat phones, and secure radios) for UAV pilots communicating with Air Traffic Control and the Control and Reporting Center.
A friend of mine worked in dis/connections support at an ISP+phone company. Proof-of-ownership was something they needed for any connection, and the acronym was used regularly throughout the workday. But she said on the phone, you'd sometimes forget and ask the customer things like "what poo can you give me?".
The funny part is that they transmit fire missions through IRC instead of using a proper artillery data network. Of course you do that through plain old-fashioned radio when no data connection is available, but it you can transmit through IRC then you certainly have enough bandwidth for communicating through a better integrated system such as ATLAS (http://articles.janes.com/articles/Janes-C4I-Systems/ATLAS-a...)
Yet again we see that simple text is a preferable messaging layer for any purpose. I imagine that this gets the job done "well-enough", and anything more fancy would just be contractor life-support.
Upon reflection, I find that it's not at all surprising that IRC is so widely used in the military establishment.
Military operations are, by definition, carried out by different coordinating groups sometimes thousands of miles apart. IRC is ideal for such a task as it provides a conferencing platform that is easy to use, develop, and deploy (in both the software sense and the military sense.)
It's unconcerned with the transport layer, so a wide variety of transport systems (which can include any manner of authentication and security) can be used: from a General or Admiral at a desktop client to drones mid-flight to boots-on-ground soldiers carrying a pocket-sized device. IRC is also a common technique for C&C in certain malware families.
The main advantages of using IRC over radio comms is that:
* It's way more reliable than radio comms (you don't need to ask people to repeat everything all the time, you read your grids right the first time).
* It's concurrent, you can have multiple units reporting at the same time.
* It's buffered, you can skip stuff and come back to it later.
* It's cheap, anybody can get a window opened on the current ops and see what's going on, without needing all the hardware of a radio.
* It makes the reporting very fast.
* It makes collation/data collection much easier.
* It's scriptable, you can automate the collection of some messages, or the emission of some others.
They got that integrated at pretty much every level, and I think it's one of the most enabling thing available right now for C2C nodes, in many armies (not just US).
The creator and developer of mIRC - Khaled Mardam-Bey - is Syrian and Palestinian, I wonder how often his software is used for tactical purposes against those countries?
It surprises me that IRC is used. In part because IRC is old and crufty and, I fear, not very secure. Also because IRC isn't some milspec contract that made some insider hundreds of millions of dollars. It's great to adapt an existing chat technology but it surprises me.
I recently read "Predator: The Remote-Control Air War over Iraq and Afghanistan: A Pilot's Story" and it talks a lot about how UAV pilots hang out in chat rooms sharing intel during operations. Asynchronous text is the perfect medium for this kind of thing; low bandwidth, doesn't require a lot of attention. Just crazy to think it'd be IRC.
It is easier to ensure absolute security of the transport layer and the physical facilities the computers are in, as opposed to designing absolute security of every application.
I often come across these types of comments about the IRC protocol being 'crufty,' 'old,' etc. I recently (a year ago) implemented a subset of the IRC protocol for a project and I thought it was fairly modern, and not difficult to work with.
Yes, IRC has some problems, it wasn't built with security in mind. I think dsl below offers a solution to some of these concerns.
But this still leads me to ask the question, what does a modern distributed chat protocol look like?
Indeed. The client "mIRC" has a few well-known security bugs and hasn't been maintained for ages, but there indeed is nothing wrong with the protocol when using more modern clients. It can be as secure as necessary through various extensions, and ofcourse running it over SSL.
At the very least, IRC let use encrypted SSL connection. Then, they may have their own IRC server implementation with special security requirements. I'm more concerned they use windows and mIRC, actually.
Defense (Coombs): D6 machines used primarily for...?
Fulton: Analysis.
Defense (Coombs): mIRC chat as a baseline?
Fulton: Yes.
Defense (Coombs): In fact, mIRC chat was installed on your machine as an executable desktop application?
Fulton: I think so.
I wonder if they have netsplits over there.. gives a whole new meaning to EPIPE (Broken pipe).
Truly, it is the only way to roll! I run IRSSI on my server, allowing my to stay perpetually connected. Additionally, I can join from any device that supports SSH! It's a great solution, even if it's a bit hard to get used to at first.
I've found it vastly more convenient to run ZNC (or the like) on the server and use irssi locally. Otherwise I typically have to fight with key bindings and finicky settings on each machine (some of which I can't change). This also lets you use any number of clients.
For example, I'm running irssi on my laptop, colloquy on my iPhone, and a few scripts which handle pushing notifications, all from the same connection.
I've always used screen, but may switch to a bouncer next, mainly to get better support on mobile, and the ability to route notifications. It does seem like a more elegant solution.
If you want a GUI I'd recommend Konversation (if kdelibs is OK). There's a Qt-only client called Quassel as well (which also supports a UI/core separation so you can close the program and remain logged in)
IRC is great and relaying on such a simple and well understood process is smart. It provides group chat, persistency, and is much clearer than trying to decipher a dozen people talking on a radio frequency.
The company I have just started at uses skype for its chat requirements. I hate it for a few reasons, but mostly because you can go back and change an existing chat message, leaving no trace that there'd been an edit.
I loathe it because of the repeated privacy concerns, reliance on a central company for not only its development but its OPERATION, and the presence of many competitors.
The SF guys I hung out with had/were using IRC on their laptop back in 2004 to communicate with other elements and their HQ which was God knows where. I was airborne infantry and we had an SF team on our camp, we worked mostly separately but hung out together a lot. After he showed it to me he told me the call signs were never to be repeated. I couldn't remember them if I wanted to. They had the laptop hooked up to sat coms. It was pretty cool for back then.
I think about this sometimes, and I think it ultimately comes down to how society acts as a whole, which is mostly out of our direct control. Society can use any tool for good or evil; just as a knife can cut bread or hurt a person, so too can Apache serve Wikipedia or serve the MPAA/RIAA's intranet.
There's definitely a cutoff point (if you're designing a nuclear-tipped rocket, there's usually just one reason for that) but stressing about whether or not the general-purpose software we create will be used for evil will only frustrate the cause of good.
What if your nuclear arms are never meant to actually be used, but the implicit threat of having that capability will keep your country from being bullied by other countries?
Not even nuclear weapons are entirely black-and-white.
A nuclear tipped rocket is indeed not a great example.
On the other hand, say you had someone with a passion for rocketry and space, who found that the best way to pursue their dreams at the time was to build conventional bomb tipped rockets with slave labor...
Still not exactly black and white, but a good deal less fuzzy I think.
Playing chicken with the world in order to prevent another conventional war between two superpowers... justified.
Otherwise, a hardline faction in any government could have easily pushed for it. Not the mainstream political force in the USA, most probably. (Though, who really knows, looking at Vietnam.) Also, my understanding is that the USSR was in an echo chamber that led it to believe capitalist USA would collapse on itself (hence the "we will bury you" line), so probably they wouldn't have attacked neither. Though the USSR had clearly the edge in a ground war, and I'm sure plenty fanatics could have been found. So there was still that possibility.
Of course, the perfect solution would be a perfectly-balanced economic/political federation of countries, policed by a neutral organization. That couldn't happen then, and that won't happen in the future. Neither Western countries, nor China+Russia, nor specially Arabic countries, will submit to a UN decision that violates their core political tenets, be it justified or not.
You seem to imply that "a little bit of negotiating leverage" is of trivial consequence rather than a question of how many people were at the mercy of a corrupt and perversely-incentivized bureaucrat or an abusive factory owner.
We didn't fight the cold war over which side you butter your bread on.
I wouldn't be able to view it so black-and-white. For example, what about waging war for independence against a tyrant or waging a war to prevent genocide? What is considered highly unethical is also highly subjective.
Nit-picking: Wars are not waged to prevent genocide. Countries are left alone to kill their own people, and afterward we may punish the perpetrators, but no action is ever taken before or during a genocide. Also, waging a war for independence is typically called an "insurgency" or "terrorism", sometimes with a more heroic title such as "revolution" or "uprising".
What's not subjective is that war is (almost) always fought for the wrong reasons. As far as ethics, "Just War" is pretty ridiculous; that the highest officials in power think it's a good idea to murder people, but only in specific ways, is just a joke.
What about TOR? It's used for war and child porn but it also has a thousand other use-cases where it's helping fight repression and supports free speech, privacy, etc.
You could add a clause that states that your software can't be used for certain purposes. That might not stop its use in some cases, but large corporations that supply the military would likely think twice.
That said, in (almost) whatever country you're in, there are people out there putting their lives at risk to defend your freedom. Sometimes they probably end up bullying people for no good reason (perhaps even over the course of years) and engaging in self-sacrificial operations, but that's not their _only_ function.
> You could add a clause that states that your software can't be used for certain purposes.
At which point it ceases to be considered "open source" software under the usual definitions. So you might as well just leave it closed source and refuse to sell licences to people you don't like.
Well apart from the definitions, you give up a lot of practical stuff that goes along with it.
For example, if your software doesn't meet the Debian Free Software Guidelines, then it won't be packaged in the main repos. And that has downstream impact on other distributions such as Ubuntu.
If your software works people will use it for something ethical or something unethical. If it works well unethical people will use it and ethical people won't touch it, because it isn't approved by the establishment of ethical people, it isn't the status quo etc.
This really happened with nginx. A group of people in 2003 or so wouldn't use nginx because youporn used it.
To be fair, I'd imagine that the majority of this money and effort is spent on highly secure and fault-tolerant transport protocols, and IRC is just a layer on top of those. So it's likely not being totally wasted.
And even the comm protocols designed to replace the IRL level? Think of those from an agile-development perspective; if they don't build it to test their assumptions in the real world, then they could be making an inefficient product. And in this business, an inefficient product can mean lives lost.
EDIT (since it's too late to actually edit the post): IRC, not IRL. There's some sort of pun dangerously close to surfacing here, but since this isn't Reddit, I'm not going to resist taking the bait.
What really saddens me is there's ways to kill people using IRC and i'm only finding out now. It would have made trolling a lot easier back in the day.
I thought it would be cool to do something like this as a hackathon project proof-of-concept; apparently I'm too late. Doing something like this for civil defense purposes would be pretty cool.