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?
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.
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.