Judge Rules Defense Can Get DUI Machine Source Code 270
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."
Re:Why not prosecute? (Score:3, Insightful)
They probably lost the source code and are too ashamed to tell anyone.
Idiotic (Score:5, Insightful)
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.
Re:cheers! (Score:5, Insightful)
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.
Well, there's one solution to all this ... (Score:5, Insightful)
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.
Re:Sixth Ammedment (Score:5, Insightful)
imho (Score:1, Insightful)
breathalyzers should never be the final answer.
you get pulled over for erratic behavior
you get breathalyzed and/or FST and if either merit suspicion you should then and only then be taken in for blood and/or urine done by a scrutinized lab.
the breathalyzer should be an indicator, not evidence.
Keep this idiot away from any kind of electricity (Score:5, Insightful)
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.
Courts deal with this kind of thing a lot (Score:3, Insightful)
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?
Is there a legitimate interest? (Score:5, Insightful)
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.
Re:A few points.... (Score:3, Insightful)
... as opposed to the defense attorneys who will do their jobs?
Fixed that for you.
I disagree. (Score:5, Insightful)
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.
Re:A few points.... (Score:3, Insightful)
If the device can't be proven to be accurate, then it's no different than an expert witness who testified against the defendant later refusing to disclose his credentials that would, in theory, show him to be an expert in the field. Courts do throw out such testimonies, and sometimes even declare mistrials (if the judge feels the fraudulent testimony cannot be ignored by the jury). And such "experts" don't get used, anymore (if not actually jailed for contempt).
Of course defense attorneys try to get their clients off. That's their job. Prosecutors also try to get the defendant convicted. That's their job. The defendant is either really innocent or really guilty and it's the judge's job to make sure the process is headed to finding the correct answer.
Re:Sixth Ammedment (Score:5, Insightful)
If the police officer relies on the reading from the device, then it is not really the police officer's judgment being presented, but just a re-iteration of what he read. Is the police officer able to testify about the accuracy of the device? Is the police officer able to testify about whether a device driver that reads values from an ADC register is doing so with the correct clock synchronization to ensure that does skew the time differential meaning of the results?
Re:A few points.... (Score:3, Insightful)
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.
Law enforcement will soon come to grips with the fact that it cannot get a conviction with CMI. Law enforcement will then buy other equipment or use some other sobriety test.
At that point, CMI will be able to sell DUI products only in states that have already ruled that the source need not be turned over. Eventually, they will go out of business or cave.
Re:cheers! (Score:3, Insightful)
Re:Why not prosecute? (Score:3, Insightful)
Re:Source code is irrelevant (Score:3, Insightful)
Your assumptions that the manufacturer of the tester wants a fair test is unverified.
I'm not saying that this is the case, but what if the manufacturer, who is selling to law enforcement, wants to build a tester that will err on the side of too many positives? For example, what if the auditing the source revealed that the tester takes 5 readings and reports the highest value?
I think that it is reasonable for someone accused of a crime by a machine to know how that machine works.
Re:Is there a legitimate interest? (Score:3, Insightful)
However, unlike the Intoxilyzer 5000, it isn't patented, so defense experts can't obtain the diagrams and source codes needed to figure out exactly how it works, Nesci said.
I think they're using this as the reason to keep the code secret.
Re:Why not prosecute? (Score:3, Insightful)
No, see, you want someone NOT hired by any governmental body so it has a chance of being less bias and corrupt.
The judge should appoint someone not involved any way in the case to inspect the code.
If the judge appoints someone to inspect the code, then the government (via the judiciary) has hired someone (the engineer). Your request is paradoxical.
"Not a trade secret" (Score:3, Insightful)
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.
Re:A few points.... (Score:4, Insightful)
Getting their clients liable for huge amounts of fines is hardly the outcome a lawyer would aim for... Any lawyer would probably recommend they turn over the code so as to comply with the court order.
Why is it so important to them not to turn over the code? They must have something big to hide, because handing over the code to the court so the defense can examine it is hardly a huge burden... Not like they're being compelled to release it to the general public.
Re:A few points.... (Score:3, Insightful)
The components have established tests to ensure they are not defective and haven't been tampered with, especially if they are off the shelf components which are also used in other devices. Since they are components, intended for third parties to use to construct larger devices, their function and interfaces will be well known and documented.
The software is presumably bespoke, and is an unknown quantity, it could also potentially be used to hide backdoors. It is not intended to be sold as a separate component for integration with other components, and is thus not fully documented if at all.
Re:Why not prosecute? (Score:4, Insightful)
If a bug is revealed in their code there is likely to be a class action lawsuit against them on behalf of everyone that was ever convicted of driving while intoxicated on account of their device. The costs associated with a single conviction far exceed the cost of one of these machines. The company would go bankrupt if that were to happen.
Re:cheers! (Score:3, Insightful)
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.
Screw the source code... how is it tested? (Score:5, Insightful)
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.
Re:Sixth Ammedment (Score:3, Insightful)
Re:I disagree. (Score:2, Insightful)
I don't understand why the source code itself is the distinction between something being verifiable or non-verifiable. It seems the results of the machine under standard testing would.
If we stood your biocube up to the similar tests that any real device would go though (being presented with samples with a known alcohol percentage) your system would get some right, some wrong and you could then say, of a sample size X, the device accurately determined the BAC of Y samples with a accuracy window of Z.
This data (as well as the device itself - generally) would be available for use during any case which this was used in. For example, if (for the sake of argument) the initial tests came out with 100% accuracy - the defense would have the device available to conduct another set of tests (And another, and another) until they could show evidence that the measuring device itself was faulty - or at least inconsistent. In an ideal system, this would lead to reasonable doubt that the test worked, and the defense would win the case.
I don't see why the real device wouldn't be put up to the same test regardless of what drives the device (hardware, software, vanilla pudding, whatever) to determine if it is providing data in an accurate enough way to be used as evidence. If the device is known to have inconsistencies like the summary states, it would seem like testing would be able to show this (caused by software or not) - hence reasonable doubt of any readings. It's up to us (as people who would be on a jury) to determine whether Y correct out of X samples is accurate enough to convict someone in our society.
I'm all for the company to release the software - but I'm not 100% convinced that a software bug being shown in court would cause a device like this to fail on the above criteria.
Lets say (for the sake of argument) that the device consists of:
a physical sensor of some sort
a way to adjust the input of the sensor (since there's always variance on those sorts of things),
software which reads this adjusted input and displays the result (perhaps averaging samples over time, etc, etc).
A normal production model would go through the testing described above, have the input adjusted until the results displayed by the software met standard criteria, then the adjustment would be locked and the unit would ship.
Even in the case where the software could have a significant bug, like always adding .15 to every read, the system as a whole would be adjusted to compensate for this.
And while the bug in this case would definitely be used in court - I have the feeling it would be more of the "get an guilty person free" rather than the "showing true reasonable doubt of the system" type of use - since the device as a whole would be accurate and precise, whether that bug existed or not.
Re:no (Score:5, Insightful)
Where did you get that idea? I take it you've never read the "Truly Tasteless Joke" book series?
Ethnic jokes are told all the time....it is just that if you have a group of people, they might look over to make sure no one of said ethnicity is around to hear the joke, but, that is the extent of it. Look, all of us have funny attributes and general behaviors. You just can't have too thin a skin, and need to have a sense of humour. And let's face it....these behaviors and traits didn't come out of the blue......many of them are based on real observable things in life.
Relax a little, and learn to laugh at yourself a little.