Slashdot Mirror
CIA Drones May Have Used Illegal, Inaccurate Code
skids writes "Coders hate having to rush code out the door before it's ready. They also hate it when the customer starts making unreasonable demands. What they hate even more is when the customer reverse engineers the product and starts selling their own inferior product. But what really ticks them off is when that buggy, knockoff product might be used by targeting systems in military unmanned drone attacks, and the bugs introduce location errors of up to 13 meters. That's what purportedly happened to software developer IISi, based on an ongoing boardroom/courtroom drama that will leave any hard-pressed coder appreciating just how much worse his job could get. The saddest part? The CIA assumed the bug was a feature. The tinfoil-hat-inducing part? The alleged perpetrators just got bought by IBM."
It's amazing that drone hardware is fairly well designed, but its software design and implementation is so slapdash. Just last year, it was revealed that the Drones broadcasted its video feed in unencrypted form and was being used by militants to spy on us.
http://www.networkworld.com/news/2009/121709-drone-intercept-encryption.html
My postings are informational and does not constitute legal advice. Act on it at your risk.
The Romans had plumbing and they were occupying Jerusalem at the time the New Testament was written... but please don't allow facts to stand in the way of your religion-bashing.
Spying isn't limited to looking at the enemy's base. The patrol patterns of the drones, for instance, tells insurgents where US army forces are looking at. This allows them to move to new locations or hide if they notice the drones moving towards familiar territory.
My postings are informational and does not constitute legal advice. Act on it at your risk.
i don't think you understood the article or didn't read it.
The software wasn't the guidance system for the drone, control it in anyway, or even run on the drone itself. Its running in some data center some where tracking where people are when they use a cell phone or an ATM, etc.
Its just a mapping package for laying out data thats correlated to geography, its just "google earth - government edition".
I doubt the 13m really mattered, your not getting 13m accuracy anyway when tracking a cell phone via tower transitions.
The CIA was using it to find potential targets so they could send a drone toward them, they'd have to get more specific information as to the exact target location elsewhere.
The Cold War arose because of the Russian fear of the nuclear-armed US [...] and their desire to create buffer zones in the West of the Soviet Union.
You mean to the West of the Soviet Union. Places like Poland, East Germany, Czechoslovakia, and anywhere else they could roll in tanks and grab.
-- Alastair
An assertion failure means something went wrong that, in the normal operation of the system, could not go wrong. The most likely reason for this is of course a programming error, but there are others: some memory got corrupted, your CPU is malfunctioning, some peripheral is malfunctioning, or some other similar sort of thing. This makes handling assertion failures tricky because you can't assume the state of the system is sane. When I did embedded stuff, assert failures would act similarly to watchdog failures -- the system would disable all interrupts, try to write the assertion code to non-volatile RAM, then reboot. For our application it made sense to do this. For other applications something different might need to be done. But the point is that an assert failure is different than an ordinary error. You can't simply handle the error condition; the whole system state could be bad. You might want to shut the system down completely (e.g. if there's a backup which will take over). You might want to attempt to completely reset your state. Or you might just want to report the condition (somehow) and continue as if nothing happened until someone intervenes. But in any case, assertions have their place.