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.

Comments

Calibration of Speed Traps

[Burning Plastic]

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

Re:Calibration

[TheMohel]

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.