Despite MN Supreme Court Ruling, Breathalyzer Manufacturer Refuses to Turn Over Source Code
from the code-is-law dept
Earlier this month, the Minnesota Supreme Court ruled that defendants accused of drunk driving have the right to inspect the source code of the breathalyzers used in their arrest. This is the right decision for a number of reasons - not only have studies shown that breathalyzers are poorly coded, potentially leading to inaccurate results, but in a legal system with the right to confront one's accusers, being able to examine the source code for errors seems like a fair digital extension. Given that more and more law enforcement is being done through shoddy technical tools, assuring fair procedure in code is no different than doing so for police officer behavior.However, the breathalyzer manufacturer, CMI, is refusing to turn over the source code, claiming that doing so would reveal "trade secrets." Ed Felten points out that this is logically inconsistent with CMI's assertion that the source code is straight-forward calculations. If that is so, secrecy isn't what is stopping competitors from emulating CMI's product. The more likely reason for not revealing the source code, of course, is the same reason e-voting is so controversial: the code is crappy.
The obvious answer was posited years ago by Eric S. Raymond - given enough eyeballs, all bugs are shallow. The source code for breathalyzers, e-voting machines and other technical law enforcers should be open source to ensure that secrecy doesn't obscure important imperfections.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: breathlyzers, minnesota, source code
Reader Comments
Subscribe: RSS
View by: Time | Thread
Case Dismissed
[ link to this | view in thread ]
Also
[ link to this | view in thread ]
Hahaha
[ link to this | view in thread ]
[ link to this | view in thread ]
HA!
"We user zero comments in our code."
[ link to this | view in thread ]
Re: Case Dismissed
You sir, are evil.
[ link to this | view in thread ]
Put blame where it is due.
This is probably compounded because an officer pulled the defendent over because they were driving erratically in the first place.
But no matter what, the source code isn't going to even solve the dilemna. If they can't invalidate the source code, the next thing that they'll do is go after the sensor manufacturer. and then the batter manufacturer, and then the display manufacturer.
The reality should be that the analyzer should be tested using standard scientific principals and methods to assure proper reading. I believe that this would be done by blowing air with the specified concentration of alcohol through it and noting the readings.
It really doesn't matter to me what the code is, it's what the results are that is important.
[ link to this | view in thread ]
A bug does not exist until it's found
For instance in the e-voting. It's easy to think that no one would walk away from the machine without committing the vote. It's possible that the designers never thought that someone would try to do something funny with the breathalyzer, or that various other substances might trigger a false positive.
It's impossible to perform a 100% negative-test. (Give bad input, an get the proper response. There are too many possible bad inputs) It's much easier to do a full positive test. (All perfect inputs give the correct output.) I'm guessing that in the real world, there are problems with the code that these developers never imagined. And rather than simply own up to it, go back and fix the problems; they are doing what most developers are wont to do. "There's nothing wrong with MY code. Why do you need to see it?"
It's an easy trap to fall into. Unfortunately, that's the reason why so many software packages have so many problems. When a bug is found, swallow your pride and fix it. it'll make you a better developer.
[ link to this | view in thread ]
Re: Put blame where it is due.
And those "what's next?" cases you mentioned should ABSOLUTELY be tested and checked and rechecked. Who knows? Maybe they'll find out that the source code is very well written, free of memory links and fully capable of doing its job. Congrats, now you have precedent AND a leg up on competitors because you can say "proven in a court of law" (see case: foo vs bar blah blah blah).
Anything used in the public domain like this needs to be hammered at from all angles and it damn well better be able to stand up to the test.
[ link to this | view in thread ]
[ link to this | view in thread ]
Alternate Ideas
Of course the analyzer will show positive.
Wonder what the charge is for drinking in a public place??
[ link to this | view in thread ]
Re: Put blame where it is due.
[ link to this | view in thread ]
[ link to this | view in thread ]
[ link to this | view in thread ]
Why stop on software?
As someone already pointed out, it's results that important, not underlying process.
[ link to this | view in thread ]
this reminds me of...
bool isDrunk = false;
try
{
isDrunk = CheckBreath();
}
catch (CrappyCodeException)
{
isDrunk = false;
}
return isDrunk;
[ link to this | view in thread ]
Re: Alternate Ideas
[ link to this | view in thread ]
Re: this reminds me of...
suspect.CheckBreath();
if ((suspect.suspectWantsSourceCode())== true){
suspect.BeatDown();
}
[ link to this | view in thread ]
Re: Why stop on software?
Putting input into a black box and having that black box render a verdict that greatly affects lives is unacceptable.
[ link to this | view in thread ]
Re: Hahaha
[ link to this | view in thread ]
Re: Why stop on software?
Unless you understand how something works (i.e. the underlying process), you can't fully understand where it can fail. As we increasingly become dependent on our accuser being technology, it is vital that we have full and open access for not only the software/code, but hardware design, chips, and full product part traceability and validation processes.
Software is nothing more than a set of procedures that a chip/design follows. We have access and can be critical of law enforcement procedures/steps used with a department, etc., but we can't do the same for software?
For those that think a validation process (i.e. testing certification without source code access) is enough. How can any device be certified without examining the source code? You could perform literally millions of test combinations and certify the product is functionality correctly and you'll still the miss the one where it wasn't.
When it comes to using technology to throw my a** in jail, I expect to have the right to examine every aspect of a device, procedure, process, etc., that says I'm guilty.
Freedom
[ link to this | view in thread ]
Ambulance chasing lawyers looking for loopholes to get guilty people off. Again.
[ link to this | view in thread ]
technology....
[ link to this | view in thread ]
[ link to this | view in thread ]
Re: Put blame where it is due.
for a breathalyzer to have a prayer of standing up in court it has to be properly serviced at very regular intervals. from the bitter experience of a friend of mine I know that the service techs DO NOT follow proper procedures. those procedures are vital to ensuring the accuracy (to the extent they can be accurate) of the readings taken.
a breathalyzer needs to be serviced BEFORE it goes in the field. in that service it has to be calibrated against known standards so that it can be trusted to make an accurate measurement while in the field. when it come back AFTER being in the field it must be compared against those same standards BEFORE any of its parts are touched otherwise you have invalidated any measurements taken. once that comparison is made you can repair any problems and then recalibrate it before sending it out. that process takes time and lots of techs will simply make repairs, calibrate and sign it off...
if it were me, I would have simply attacked that area first. then i would have gotten into the very science of breathalyzers. if there ever was a definition of "junk science" there is a picture of a breathalyzer next to it!
breathalyzers INFER blood alcohol volume (BAV being the basis of the legal definition of impairment in most states) from alcohol residue in your breath. that measurement is based on an idealized curve of alcohol transferring from your gut to your blood to your breath (via the lungs). that idealized curve was based on some scrawny 150 pound male at the time I learned about all this crap. EVERYONE metabolizes alcohol differently and that idealized curve is a really bad joke.
while i feel that people ought not drive drunk i also feel that our "legal system" (code for "revenue enhancement gang") is geared to shoving people into a classification that will allow the "long arm of the law" (and the insurance companies and the people who will collect your "driver responsibility fee" and the chucklehead who will berate you at those bad driver clinics and ...) to take cash from your wallet over and over again...
as for the source code, serve a warrant and lock the place down. that will get their bloody attention. oh, but wait, that might disrupt the revenue stream from this scam we call "drunk driving enforcement" so who would want to do that?
[ link to this | view in thread ]
Re:
[ link to this | view in thread ]
The point you are all missing
[ link to this | view in thread ]
Re: Re: this reminds me of...
Person suspect;
suspect.CheckBreath();
if ((suspect.suspectBlackMale())== true){
suspect.ShootWhileFleeing();
}
[ link to this | view in thread ]
Re: Re: Put blame where it is due.
Ah yes, the "jeez, I only had a couple of cans" defence.
It's really very simple - if you're going to be driving, DON'T DRINK. At all.
Personally I don't drink and drive. Not because I don't want to get caught, but because I don't want to hit a kid. But feel free to keep justifying your position.
[ link to this | view in thread ]
Re: Alternate Ideas
[ link to this | view in thread ]
Re: Put blame where it is due.
[ link to this | view in thread ]
Importance of Accuracy
Breathaylzers NEED to be accurate and their code NEEDS to be clean and consistent.
I have said it before and I'll say it again. There are two reasons not to let your code go public. One is intellectual property rights and the other is because you know that your code sucks and you don't want anyone to find out! The interests of public safety (i.e. we need accurate breathalyzers to keep non-drinkers safe) should trump intellectual property rights.
Unless the code sucks embarrassingly, they should just turn it over.
So much talk goes on about the reliablility of breathalyzer code and somewhere in most discussions, it is brought out that the basic computations involved are 'well-established' and commonly available.
I'd like to see a new open source breathalyzer on the market. But here's how I think it needs to work ...
There needs to be an open source core which performs the true calculations wrapped within a digital cloak of additional features adorned by the authors. The core should be open, well-documented, and not impacted by wrapper code.
With such a scenario, Company A and Company B, both produce breathaylzers which yield EXACTLY the same results consistently, although they operate, look, or cost different. The marketing needs to be independant of the coding because the coding should always be the same.
[ link to this | view in thread ]
Re: Why stop on software?
[ link to this | view in thread ]
Re: Importance of Accuracy
While being somewhat successful in software, open source in hardware is simply non-existing.
Now, people here seems to think that by "examining" some kind of "source code" they can reach the conclusion whether results are accurate or not.
It doesn't work this way. The correct one is to check results against reference model, nevermind open sourced or not.
This thread makes me say only one thing: "what a bunch of incompetent dilettantes".
[ link to this | view in thread ]