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.

Filed Under: , ,

Rate this comment as insightful
Rate this comment as funny
You have rated this comment as insightful
You have rated this comment as funny
Flag this comment as abusive/trolling/spam
You have flagged this comment
The first word has already been claimed
The last word has already been claimed
Insightful Lightbulb icon Funny Laughing icon Abusive/trolling/spam Flag icon Insightful badge Lightbulb icon Funny badge Laughing icon Comments icon

Comments on “Despite MN Supreme Court Ruling, Breathalyzer Manufacturer Refuses to Turn Over Source Code”

Subscribe: RSS Leave a comment
34 Comments
Ed says:

Put blame where it is due.

I believe that the accused probably has a right to have called for a blood test. But they probably decided that they would rather fight what was probably an obvious case of DUI than to stop drinking and driving.
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.

B says:

Re: Put blame where it is due.

Your comment is a bit misguided. You don’t know anything about the case beyond the fact that they’re ACCUSED of DUI. Innocent until proven guilty, and if the instrument used to make the assertion is faulty, then the case is invalid.

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.

dennis parrott says:

Re: Put blame where it is due.

there is more to this business than just grepping their lousy code, or the follow-ons suggested by Ed in #7. let me explain…

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?

Eclecticdave (profile) says:

Re: Re: Put blame where it is due.

> EVERYONE metabolizes alcohol differently and that idealized curve is a really bad joke.

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.

RGS says:

Re: Put blame where it is due.

My, my! An intelligent comment and it pinpoints the obvious problem…….the “accused,” not the code. And since this clown seems determined to take this to the supreme court and beyond, the manufacturer should offer a scientifically monitored court demostration of the device to determine its accuracy. Preferably with the very device used in the arrest. GET HIM! (or her?)

spencerMatthewP says:

A bug does not exist until it's found

I’m a software engineer. One thing I’ve found is that problems don’t exist until they’re found. It’s entirely possible that in the design phase of the product that no one thought the scenario of use would come up.

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.

John Doe says:

Taken to the logical conclusion; you could call into question the code behind any digital evidence gathering device such as gene sequencers for DNA testing, imaging code used in the digital camera the photographed the scene to the BIOS used to run the radar gun. The code is not important, because the judge, jury, lawyers, defendant, prosecutor and so-on would have no way to make heads or tails of the code. What is important are the test results. Can the manufacturer demonstrate the device is accurate based on a 3rd party, independent testing facility?

Freedom says:

Re: Why stop on software?

>> As someone already pointed out, it’s results that important, not underlying process.

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

Anonymous Coward says:

Anyone claiming that what happens inside the code of the breathalizer is not important, that it can’t be understood, other than by testing the results, must think that inside the breathalizer is some sort of alcohol-sniffing gnome that consults spirits from the Otherworld to determine whether a person is guilty or not of DUI.

Mike Mixer (profile) says:

The point you are all missing

This isn’t about lousy code versus good code anymore, this is about accountability. Do the police buy the equipment that works the best? yes. Do police define what works the best by how many people get convicted of a crime using that equipment? yes. Does that create a situation where a manufacturer might use faulty hardware or software to make their equipment show more false positives thus resulting in more convictions? if you say no you’re an idiot

Allen D. Porter (user link) says:

Importance of Accuracy

The ability to measure alcohol in the blood combined with numerous studies (read thousands and thousands of subjects) on the physiological effects of alcohol on the senses, and the setting of .08 as the legal limit for intoxicated driving makes up the basis for our DUI laws. But complaints regarding the accuracy of breathalyzers raise an important issue.

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.

Yosi says:

Re: Importance of Accuracy

Open Source core? You seem to be clueless how any complex hardware and ASICs being developed. There’s no single vendor that provides hardware core as open source.
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”.

Add Your Comment

Your email address will not be published.

Have a Techdirt Account? Sign in now. Want one? Register here

Comment Options:

Make this the or (get credits or sign in to see balance) what's this?

What's this?

Techdirt community members with Techdirt Credits can spotlight a comment as either the "First Word" or "Last Word" on a particular comment thread. Credits can be purchased at the Techdirt Insider Shop »

Follow Techdirt

Techdirt Daily Newsletter

Techdirt Deals
Techdirt Insider Discord
The latest chatter on the Techdirt Insider Discord channel...
Loading...