Slashdot Mirror
Judge Rules Defense Can Get DUI Machine Source Code
pfleming alerts us to developments in Arizona on a subject we have frequently discussed (e.g. FL, MN, NJ): efforts in DUI cases to obtain source code to devices that analyze blood alcohol levels. On Friday a Pima County Superior Court judge ruled that the software that powers the Intoxilyzer 8000 must be revealed to defense lawyers. "Defense attorneys representing more than 20 people arrested on felony DUI charges agreed to consolidate their cases into one and to argue it before [Judge] Bernini ... The source codes are crucial because the Intoxilyzer 8000 sometimes gives 'weird' or inexplicable results ... Six other states have been battling CMI [maker of the Intoxilyzer] over the source code — Minnesota, Florida, Louisiana, Massachusetts, Tennessee and New Jersey... CMI has currently racked up over $1.2 million in fines in a civil contempt order for not disclosing the source code in Florida."
I'm sorry, but if a company is making it impossible for DUI prosecutions to be done fairly, the company officers should be sitting in jail whilst we wait to find out if they can get the source code together or not.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
In court documents, Deputy Pima County Attorney Robin Schwartz said the defense attorneys' requests "bear all the hallmarks of a fishing expedition." Common sense shows that people rely on software and source-code information for everyday matters, Schwartz argued. One just looks at the results to know if something works or not. Schwartz used electricity as an example. "No one . . . needs to see a schematic of wiring to know that when he flips the switch on the wall, the light will come on," Schwartz said.
Um, that assumes that you are comparing the result with a known value. The point of a breathalyzer is to determine an unknown value.
Unless of course this attorney is saying that they already know the accused are drunk, in which case the breathalyzer is redundant.
"Anyone who [rips a CD] is probably engaging in copyright infringement." - David O. Carson
Weird numbers? What weird numbers...?
This isn't about OpenSource.
It's about making sure that the device providing so-called scientific evidence for use at trial is producing evidence properly and -accurately-.
I'm surprised it isn't already on the books that source code for devices such as this be disclosed for that purpose already.
the accused shall enjoy the right ... to be confronted with the witnesses against him;
In this case the withess is a machine, he has the constitutional right to know how that machine works
rule that all programming used for government functions be open source, unless there's an overriding reason for it to be closed. This outfit appears to have manufactured and marketed a fundamentally flawed piece of technology that may very well have resulted in prison time for innocent people. Not acceptable ... a manufacturer's need to maintain a competitive edge should not be held more important than our right to not be falsely accused and wrongly imprisoned. Now, of course there may be other issues with CMI's product other than the firmware, but a detailed examination of the code is a good first step.
Furthermore, the people responsible for the decision to market the Intoxilyzer should be held accountable for the device's failures, especially if they sold it knowing that the design was defective. Sure, it costs more money to properly certify a design, and to implement effective quality controls. Still, if auto manufacturers have to suffer multi-million-dollar lawsuits over tiny flaws in vehicle design, these guys should hardly get off scot-free.
The higher the technology, the sharper that two-edged sword.
I work as a law clerk in Minnesota, and while (being a clerk and all) I haven't "ordered" per se the source code be turned over, I've written many orders doing so -- until the Minnesota Supreme Court created a very high hurdle to getting it and no one has since requested. As stated by the attorney in the article, CMI won't turn the code over. Period. They simply will not obey court orders to do so. Minnesota is currently suing CMI in federal court, and we'll see how that turns out. But barring a federal court order, I assume they will simply continue to refuse to turn the code over. The result? Hundreds of DUIs being thrown out in Minnesota alone. Nice to see that the company cares more about their IP than the safety of our roads.
Even in such a simple case there are many things it should be testing. Is the A/D output sane? Does it take 3 quick samples while someone is blowing and average them or just take it once (which could be wrong for some reason)? According to the article, it doesn't look like it does. It calibrates the wind sensor, but doesn't check that the calibration is sane. It doesn't report errors unless they happen 32 times in a row. It disables the watchdog timer. It disables the interrupt for illegal instructions. It doesn't meet any coding standards. It contains code with things like "this is temporary for now" in it. There is an obvious reason why they didn't want the code released.
This was a partial summary of another breathalyzer source code that was opened up in another case. This has nothing to do with open source this has to do with software that is half-ass'd but determines if someone has to go through years of court hearings, meetings, suspended license, and a whole waste of money because some company rushed their software engineer to write code that may be giving wrong results all together.
This code should be open to public discrimination, there would be no trade secrets if the law protects the code from someone else using it after its been opened to public discrimination because every company would have to disclose their software.
Then there needs to be a way to prove that the source code provided matches the binary code being executed. But if they can't provide the source code, then there's no reason at all to believe that it's honest.
I think we've pushed this "anyone can grow up to be president" thing too far.
While there may prove to be some problem in the source code that destroys accuracy, it would be far more likely that any error is caused by the actual sensor. The only real error I can see them making in the source code would be averaging multiple readings from the sensor together.
The real way to determine if the Intoxilyzer is accurate is to do repeated lab tests using known concentrations of alcohol in air. This would take both software and hardware into account.
Schwartz used electricity as an example.
"No one . . . needs to see a schematic of wiring to know that when he flips the switch on the wall, the light will come on," Schwartz said.
And what would this guy do if he finds that sometimes the light doesn't come on? Or the light goes off on its own? Or comes on by itself? Or flickers and buzzes? An electrician would need to know the wiring involved. A diagram or schematic would be used, if available, or else he would have to trace the wires (reverse engineering).
And this analogy doesn't even apply to a measurement device. What if he uses a volt meter that says the voltage is 120 volts ... does he assume that because the meter deflected that it's reading is correct? It could be a 240 volt circuit that has each wire only 120 volts relative to ground.
Any device that cannot be independently verified as operating correctly at all times should not have any of its results submitted in court for any purpose other than to argue that the device is defective in a case against the manufacturer.
now we need to go OSS in diesel cars
They just have an expert witness examine the code. It would be someone with experience in the kind of assembly code involved, and experience developing firmware for measurement devices like this. It is the testimony of the expert, not the source code itself, that would be presented to the jury. Just because you can't grok assembly code doesn't mean no one can. Obviously someone had to write the stuff.
Sadly, it may be the case that this manufacturer hired someone like you to develop it, and it was their first time writing for that CPU architecture, and under the memory and speed constraints involved in the hardware selected for the device. Perhaps it gives flaky results simply because values are not read from registers in sufficient time for it to have the correct meaning. The hardware may be providing the next interval reading, but the software assumes it's from an earlier time interval, and differentiates the values incorrectly. There are lot of other possible problems that can happen when interfacing between software and hardware. Just look at all the bugs device drivers in common computer systems have.
Don't forget here that we are talking about a device that gets substantially less testing than a driver in Windows, and gets deployed for use in mobile environments that subject the device to hostile conditions like vibration and mishandling. And consider that there are fewer of these devices made and sold than there are beta test copies of a new version of Windows. Which will have the greater scale of testing in the intended environment?
now we need to go OSS in diesel cars
The software should be available to those who have a legitimate interest. The source code for ANY machine being used to gather evidence should be available to the defense. The judge in such a case should get to decide if the defense needs to see the source code. If closed source software is leaked to the public, then some sort of sanction would be appropriate.
This raises the issue of software on election machines... The entire voting public has a legitimate interest about haw their votes are counted. The only way around this is that the software running should be publicly available. It doesn't have to be open source as far as copyrights are concerned, just the public should have the right to examine the source code.
This has already happened with radar guns. If they are not calibrated frequently they will register a tree moving at twenty miles an hour.
That being said, in Florida, even if you are below the legal limit, you can still be charged with driving while impaired if it can be shown that your driving was impaired.
One of my closest friends is a Criminal Defense Attorney and he tells everyone he knows, "Don't drink a drop and drive". Also, you are within your legal rights in all fifty states to request a blood test instead of the breath test. You will be booked, but the results will be indisputable in court. So if you're sure you only drank one beer it will be dead on.
At some point, the suspects were caught, and the state needed to collect evidence of their BAC. Unfortunately, the state, instead of using a device that could provide accurate, verifiable evidence, used a device that, due to the lack of source code, could not provide verifiable evidence. Since the evidence is not verifiable, then the evidence is not admissible. Next time, the state should buy and use breathalyzers that produce admissible evidence.
While their action is despicable, the breathalyzer vendor didn't agree to provide their source code as part of the purchase, and shouldn't be forced to do so after the fact because the state didn't buy a device suitable for the task.
It's a bit like if I went to the state and offered to sell them a breathalyzer, and delivered a bicube blood alcohol measurement device, which is used by giving the two cubes to the suspect, having them throw the cubes on the ground, and then counting the number of dots that are showing on the top faces of the cubes. The state should know my breathalyzer isn't going to produce admissible evidence and shouldn't buy it and try and use the results in court.
Just like voting machines, states need to learn to stop spending millions of dollars on technology that doesn't work.
paintball
The problem is the source code looks something like this:
if ($suspect == black) {
print ".12";
}
elsif ($suspect == hispanic) {
print ".14";
}
elsif ($suspect == irish) {
print "ERROR";
}
Sorry, in today's world there are two sorts of companies: those with IP and a product and those with a product.
The first sort exist in the US and Europe. The second sort are in China, Singapore, Indonesia, etc. Taiwan and Japan are sort of a mix.
Once you let the IP out, the second sort of company can easily eliminate the first sort from the market. They can make the product cheaper, faster and more efficiently and they have zero R & D costs. Sure, you can use all sorts of things like patents and copyrights to try to lock down the IP. Unfortunately, none of those apply in a Singapore courtroom. And US Customs really, really doesn't care. They will not block importation of materials based on patents, licensing or anything else like that.
If push comes to shove, the binaries could probably be extracted and disassembled. That would be expensive, I suppose, but given that this is a compact embedded system the code probably isn't that complex.
The higher the technology, the sharper that two-edged sword.
That's how things are wired in the USA for 240 volt circuits. The transformer secondary is tapped at the midpoint and grounded at that tap. All 3 wires are supplied to the building. 120 volt circuits can be wired between the midpoint neutral and either of the other wires. 240 volt circuits can be wired between the 2 non-neutral wires. While AC is, of course, alternating polarity in time, at any one instant, one of those wires is positive while the other is negative relative to the neutral. So the voltage difference between them will be 240 volts.
If you insert the two probes into the outlet holes for power, and one of those probes is broken, you can still get a reading that shows the charge potential for just one side. Digital meters pull so little current from the measurement that they actually can read charge potential alone. It could then show as much as 120 volts even for a 240 volt circuit, giving a reading that could appear to make sense since 120 volt circuits are the most common here, while the actual circuit is really 240 volts. A good electrician will cross check his meter to be sure it is not giving a faulty reading.
now we need to go OSS in diesel cars
In NYC the police using their breathalyzers (might be a different model) could trigger an intoxicated reading just by keying their radios nearby. The needle would jump higher and they could use that to lock you away for hours until a much slower blood test refused to confirm the reading. It is well known that they used this "ability" to harass and lock away people who annoyed them with no justification. There are all kinds of "tricks" that can be played with these machines and the defense is right to be very leery of any "evidence" provided by them.
And I know Pima county well enough to know not to rely on what their attorneys say as the final word on anything.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
To add on to the above post, in Florida, portable breath test unit results (breath tests in the field) are not admissible in court. They can be used for certain administrative violations, but not for criminal charges.
In order to be administered a breath, blood, and/or urine test, you must already be under arrest in Florida. The officer has already administered field sobriety exercises and determined that the subject is impaired by drugs and/or alcohol. The tests at booking or elsewhere are after the fact. And as the parent said, you can be arrested even if your BAC is below the per se limit. This is because some people can get completely smashed on a drink or two, some people drive with drugs (legal or illegal) in their system which impair their ability to drive, and some like to mix and match.
I suppose that this really does not have much to do with the device's source code, but I just wanted to point out that in Florida mindless drones are not using this machine alone to determine if someone is drunk. It is a little more complicated than that.
While I agree that government should not use "expert testimony" that can't be reproduced, I don't buy the following logic (from the story, haven't read the opinion yet):
So: if it's not patented and not under copyright then it's not a trade secret? Usually a company gets a choice: copyright/patent (publish but get protection) or trade secret (can't publish). No patent or copyright holds in favour of trade secret protection.
The real ruling should be that while the company should be free to keep the workings of their device secret, the government should not be allowed to rely on evidence produced via devices whose inner workings are secret.
That is fine. IF the driver was driving in an erratic manner they are unsafe. However ANY driver should be able to face their accuser and if the accuser is an electronic device they shouldn't have to tolerate "poof then magic occurs" This is to protect the innocent from an abusive state. Most cops are honest great people but anyone that does not think there is rogue and corrupt governments is gullible.
When the source code is compiled in the exact same manner that the binary the hash value should be the same for the compiled code as the binary used in the machine. Hash Function
I work in the State of Florida as a police officer, and I arrest and charge people with DUI on a regular basis.
In my opinion, this ruling was exactly on the money, and far too long in coming. If a company refuses to disclose evidence, the State should immediately stop using their product to obtain evidence.
As a certified expert witness, I am able to testify to the impairment of a subject without the need of a breath analysis to verify. About 20-30% of the cases I testify in have no breath results because the defendant refuses to provide a breath sample. We only forcefully obtain samples (of blood, not breath) when a traffic homicide is involved.
If the evidence is faulty, I *need* to know. I can only uphold my oath of office if I can testify in good faith that I am using proper methods of obtaining evidence. If this company is witholding vital information, they should not be allowed to sell their product to law enforcement.
His lawyers defense was that every man had the right to face his accuser, and that included the computers.
Captain Kirk was innocent. The computer records were falsified.
The DUI makers should watch this episode.
The bottom line is that, particularly in an embedded device working with sensors, many problems will simply not be apparent from the source code, no matter how good you are. The only way to know that this device gives good data is to give it the same sort of rigorous testing we give (for example) new drugs and electronics that go into airplanes and military hardware.
I would want to see this device subjected to adverse environments, radio interference, being operated on the side of the road, etc. etc., and still reliably producing results that closely correlated with those produced by reference tests (i.e. blood alcohol tests). If this sort of testing is done for each and every revision of the device's firmware then the company is right, source code is irrelevant. This isn't like a voting machine... it has a discrete, limited number of inputs, no operating system, and a small memory pool--the only way to tamper with it would be to alter the firmware, and that can be checked with a simple checksum. And if this sort of testing isn't being done, then these devices are worthless and shouldn't be used to send someone to jail, because anyone who knows anything about programming knows that any project of any complexity will have bugs, and this sort of testing is the only way to catch them.
So... does anyone know how these devices are tested? How rigorous is the testing? Is it serious, covering all conditions, and all revisions no matter how minor, or is it the usual "get the bad guys, screw civil liberties" sort of half-assed stuff that we've come to expect from American law enforcement?
I have no sympathy for drunk drivers... but I don't want anyone sent to jail on evidence that even MIGHT be false.
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1