Slashdot Mirror
Florida DUI Law and Open Source
pete314 writes "A Florida court this Friday will hear arguments in a case where the accuracy of a breathalyzer is being scrutinized because the manufacturer refuses to release the source code. A state court ruling last year said that accused drunk drivers are entitled to receive details about the inner workings of the "mystical machine" that determined their guilt, and defense attorneys are now using that ruling to open up the device's source code.Is this part of a larger trend? With software bugs being a fact of life, consumers and organizations could claim that they need to be able to verify an application's source code before they accept that their calculations are accurate. Think credit card transactions, speed detecting radar guns, electronic voting machines..." Here is our previous story when this first became an issue in Florida.
If, ideally, the government exists soley for it's citizens. Would it be in our best interest to be able to view the source code of non classified projects? If the government is in fact using our tax dollars to pay programmers, should we be entitled to view the outcome of their work and does it become public domain if paid for by public funds?
2. So is this kind of ruling going to spread to radar detectors, baggage-scanning equipment, automated video cameras, etc?
I'm sorry, I am all for open source and think it should be promoted. But if the breathalyzer's accuracy has been tested and verified, not being open source should not be a reason to let a drunk driver off the hook, in my opinion.
I'm still wondering if this is being used as a legalistic loophole or an honest concern about false arrest. I mean, there is a blood test that has been shown to be just as good or better than a breathalizer.
I don't get it.
The larger problem here is that a lot of these tools (breathalyzers, RADAR and LIDAR guns, etc) are dealing with ambiguous data in the first place. For example, the algorithm used to determine BAC in a breathalyzer may be implemented correctly, but what if the algorithm itself is wrong? You're dealing with many variables (a person's mass, their metabolism, etc), and those variables have different values for different people. It's well-known, for example, that women will blow higher on a breathalyzer than a man simply because they're generally smaller.
Similarly for LIDAR (laser speed detection), the underlying principle is using distance and time to determine rate. Sounds straightforward, as d = r * t, but how do you know you've got the right values for d? It's been shown that rapid movement of a LIDAR gun can cause even inanimate objects to register a rate. How do we know the LIDAR gun measured the distance your car traveled over a period of time, rather than the distance of your car at one point in time and the distance of some other reflective object (say, a much closer stop sign) at a different point in time? At the distances in question, we're talking sharpshooter skills as a requirement for using a LIDAR gun, but it seems that every cop on the force has one. Can they expect us to believe that every cop is a sharpshooter, or that several cups of coffee won't induce shaking in the cop's hands that could cause false readings?
It's a good precedent, forcing the breathalyzer source to be opened to inspection, but the assumption is still that the underlying algorithm is accurate when it's not. I don't understand why courts continue to rely on technology such as the breathalyzer or the LIDAR gun when there are better, proven tests that could be used instead (blood tests, RADAR or pacing with a calibrated speedometer). Worse, once a court has chosen to allow such evidence (this is not arbitrary, but once the admissability of such a test is challenged and lost it's almost impossible to re-challenge), you can no longer argue that the underlying tool is bad (without extenuating circumstances that would bring the acceptability of such tools back into question). You can argue that the machine wasn't properly calibrated or maintained or that the officer using it was untrained or unqualified or out of practice, but you can't argue that the tool itself is inadmissable as evidence even if the facts are on your side.
... friends don't let friends code drunk.
It's important to remember that visible source code isn't the only requirement for Open Source. For software to be Open Source, it's not only necessary that the source code be available, but also that users are free to modify it and redistribute modified or unmodified copies. There's no real chance that the software in this case will be released under those terms. After all, one of the arguments that the lawyers are using is that the software has been modified without being recertified. It would be much more difficult to ensure that software in use hadn't been modified from a certified version if any user were free to modify it.
There's no point in questioning authority if you aren't going to listen to the answers.
If the software is complex enough to require "numerous software upgrades", then it is complex enough to have bugs. And it seems to me that not all bugs would necessarily show up under testing.
You go to a bar. Someone buys you ten beers. So your intoxication was free as in beer. Then you get pulled over and get a breathalyzer test which gets thrown out of court because the software was not free as in speech. So then you walk out of court, free as in Willy!
One of the easiest ways to get a speeding ticket overturned/dropped (at least in the UK) is to request all of the calibration reports for the particular camera/radar gun used to take your speed.
If the reports cannot be produced or are older/outside the statutory testing period, then the data produced by the machine will not hold up in court, and so the case will be dropped.
In some cases, the police simply cannot be bothered/do not have the time to do all of the necessary paperwork, and so the case may just be forgotten/ignored.
I don't know if this could be applied to a breathalyser, but it would be an interesting to see what would happen...
[All Your Fish Are Belong To Us]
Even if the brethalyzer's accuracy had been tested, so what?
Think about easter eggs and date bugs: How do you know the software works correctly on leap year day? On Sundays? On the 295th test? If the cop enters "124341+" on the keypad just before running the test?
You don't.
The output of a machine is NEVER evidence in a trial. What is evidence is the expert testimony of a human - hired by the prosecution - that the output is correct. (This has an incentive structure that encourages both fraud and rose-colored-viewing on the expert's part.)
To mount a defense the accused needs to be able to hire his OWN expert and let HIM examine the machine and identify any ways it could have made a false indication. Then you get a conviction if, and only if, the prosecution's expert is able to show that none of those occurred, so the reading is accurate.
For the defense expert to be able to do his job on a software-using system he needs access to the source. If the prosecution is able to deny him that, he has been denied - by his opponent - his due process right to challenge the evidence against him. So the evidence MUST be thrown out if he is to have a fair trial. IM(NAL)HO that's cut and dried.
Imagine if the machine was a witness. The prosecution gets to question the witness. The defense does not get to cross-examine him. See where that would lead?
How about a program that allegedly (according to a prosecution's expert witness) examines evidence and says "he's guilty" or "he's innocent"? Without a defense expert examining the code how do you know it's not:
g = "innocent"
repeat until eof
if input line == "officer O'Malley saw a rabbit"
g = "guilty"
print "he's " g
So it's:
1) open the software generally,
2) open the software to a long string of (expensive) defense expert witnesses,
3) not use the software's output if challenged, or
4) deny due process.
If they try to settle on 2) it's easy to argue that not going to 1) denys due process to the poor, since they can't take advantage of the expensive experts.
Result: No closed-software devices can be used by the procecution if challenged (unless the courts decide to deny due process).
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I've never forgotten that lesson. If I know what algorithms are, and how they work, and what a particular language can (and can't) do, I can certify a project, based on the look on the programmer's eye when they answer The Questions.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Here in Australia, the road-side breath test (RBT) just gets you dragged to the police station, where they take a blood sample. It's the blood sample that gets you convicted, not the RBT... additionally, they take two blood samples: one for you, one for them.
Aren't blood samples used in the US? Do you not have that option?
> With software bugs being a fact of life, consumers and organizations could claim that they need to be able to verify an application's source code before they accept that their calculations are accurate
:(
Similarly, back before the Y2K bug was seen as a huge technological burden on companies, the FDA had proposed some regulations regarding drug manufacturing / quality control that required the process to be fully reviewable during an FDA inspection. As usual the regulation was intentionally vague as to allow for interpretation where deemed appropriate. I was lucky enough to be working for very compliant and thus, proactive company (now BMS) and got to see how things ideally could be in the pharmaceutical industry: The original guidance given by the agency seemed to require that all equipment and devices have least have some sort of documentation from the vendor saying that they would allow the FDA to look at their source code. It was a MAJOR pain to get companies to agree to such things (as they didn't wanna be held liable for poor code) and thus began the notion that OSS would be used if available. In one notable instance, the manufacture of a UV spec waffled until it came time to fax a document assuring the FDA could look if necessary. Our company ended up returning the whole unit and ordering a different brand. If it weren't for the Y2K worries already burdening the industry, it likely would of turned out that the whole industry would have had to work on VALIDATED and open software -- too bad
Remember that states here are somewhat independant and DUI law is largely up to the state. Many, perhaps even all, states will allow a large, more accurate breathilizer to be used as evidence. You are taken to the station and then tested with it. It's cheaper than a blood test, and easier (many people, myself included, hate needles). Now in all the states I know of you can demand a blood sample be taken as well, and your lawyer can have an independant expert examine it. However, I know DUI law for only a couple states, so it may be that's not true in all states. Also, the police usually don't have to tell you that, and if you don't ask you are SOL.
In generaly, we are pretty convict-happy on DUI offences. There are some very effective lobby groups that have convinced the public that DUI is a major, major problem that needs a strict response. The laws have been steadily getting more baised on the prosecution side, where it takes less alcohol in the blood to be considered drunk, and it's harder to challenge the results in court.
I've built medical devices before. This is in essence a medical device. If this were being used in a medical laboratory for medical purposes, source code changes which were not properly recertified would void the FDA approval for the device. There's a reason for that.
It's a truism in software that you can't verify the absence of bugs by black-box testing, no matter how complete the test vectors. This is doubly true when the software is interacting with the real world, in a nontrivial manner.
Consider: The device undoubtedly measures a change in itself that occurs in response to the presence of ethanol. A voltage is produced, a current is seen, or a color change occurs in some sensitized material. Some chemical reaction occurs, and produces a detectable change in the device state. But because chemical reactions are susceptible to variation in temperature, in the age of the reagents, in the particular lot of the reagents, and in subtle machine-to-machine differences between reaction sites, the software for the machine must contain built-in adjustments for all of this. If you have a half-dozen linear adjustments that you have to make (not uncommon, in laboratory equipment), the six-dimensional test vectors that you have to check are massive. If you have a dozen such factors, you literally can't test enough combinations to be sure that every combination works. And even worse, you have to verify that the machine is in a known state at the beginning of such a test, and without access to the source you have no way of knowing.
The question isn't whether the machine can be made to work in a laboratory setting. The question is whether the machine worked this time, in the middle of the night, in an un-airconditioned drunk tank in God-knows-where, as the thirty-fifth breath test that night. If you don't have the source code, you literally can't possibly know what the chances are that it really worked.
As much as I hate drunk drivers, and as much as I think that the machines are probably pretty good, I'm with the defense attorneys here: produce the source, or stop pretending that this machine can produce proof beyond reasonable doubt.
Prosecuter: Your Honor, Mr. Smith was travelling at a high rate of speed, swerving side to side. He was pulled over, and the officer, upon approaching the car could smell alcohol. Mr. Smith was asked to submit to a breathalyzer test which he agreed to. His blood alcohol level was 1.6, twice the legal limit.
Defense Attorney: Your Honor, this is preposterous. How can anyone sit there and expect me to think that the machine they are using is accurate. I have good information that these machines are in fact filled with raspberry jam and spit out completely random numbers. In fact, your honor, if you look hard enough you can even find a hack that will convert the machine into an mp3 player. It's quite obvious that we need to examine the source code that runs this snack dispenser or let my client go.
Judge: I'm going to ask you for the last time. Remove the foil hat, the glare off of it is really starting to bug me.
Karma means nothing to me, so suck it...
How can people get forced to go to AA meetings when the 12 steps involve god? I shouldn't be forced to attend religious meetings, no matter what crime I've done. Freedom of religion and all that.
in some way shape or form for the last 18 years, I can tell you that breathalyzers are tested regularly. Each agency that I have worked for/with has had its machine tested and calibrated on (at the worst) a monthly basis. Logs and printouts of the tests are kept for a period of time (last I remember it was 5 years, but that may have changed). The machines are tested against a predetermined and certified air/alcohol mixture, and sent back for recalibration if they fail to report a correct alcohol level past a very minute tolerance. The machines work. Any standards and training officer worth his salt can rip this defense to shreds with documentation on his agency's breathalyzers.
It is called the Government Printing Office. The GPO publishes books, magazines. posters and CD-ROMs in hundreds of categories. Titles like "The American Practical Navigator" have been in print for two hundred years. U.S. Government Online Bookstore
As opposed to the massive advantage of being rich? I'm not rich, but I'm decently technical, where's my piece of the advantage pie?:-)
Here in Austria its the same, and in Germany too.
But it has always been that way, I don't think breath tests are accurate enough to prove a case in court. They are only an indication if a blood test is needed or not.
And often somebody is just above the limit in the breath test and just below the limit in the blood test.
This is about the worst advice for verifying the engineering of a complex device that I could think of.
The person's ability to play it cool under this kind of unsually direct question is probably inversely correlated with their ability to program.
You described a litmus test for good CEO's, not good engineers. A good engineer is aware of the complexities of the real world, doesn't see things in black and white. When pressed in this manner, a good engineer is immediately going to start second guessing themselves for the thousandth time, as they should.
Is that only in Louisiana? I thought most states had laws on the book which stated that refusing to take the test was legally equivilant to blowing above the limit, and would get you a DWI.
I lived in Louisiana when I was young, it is a strange state... There was a drive through bar less than a mile from my family's house in suburban Shreveport. One of the 'things to do' was to get a 'go cup' and cruise the streets. I heard they have an open container law now though...
"I'll have a Guinness, no wait, make that a Coors Light" -Grad student I work with, who shall remain anonymous...