PDA

View Full Version : Breathalyzer Source Code


tiki
08-09-2007, 3:51 PM
http://news.com.com/Police+Blotter+DUI+defendant+wins+breathalyzer+sou rce+code/2100-7348_3-6201632.html?tag=nefd.top

FreedomIsNotFree
08-09-2007, 7:11 PM
http://news.com.com/Police+Blotter+DUI+defendant+wins+breathalyzer+sou rce+code/2100-7348_3-6201632.html?tag=nefd.top


This is great news. Not that the circumstances fit any of my legal fights, but its reassuring to hear that the Bill of Rights still has a place in the 21st century. Unfortunately, for the most part, we seem to be moving further and further away from the founding ideals of this country...

adamsreeftank
08-10-2007, 2:16 AM
Good news for civil rights.

Bad news for intellectual property rights.

FreedomIsNotFree
08-10-2007, 7:23 AM
Good news for civil rights.

Bad news for intellectual property rights.

How is this bad for IP rights? If the designer of a particular system, in this case source code, sells that system to the State, they have received their benefit in the form of payment. The State now owns said system and if the State is going to use that system in any type of criminal prosecution the defendant has a right to examine that system for accuracy.

How is this bad for IP rights?

Paratus et Vigilans
08-10-2007, 8:15 AM
I also fail to see the IP issue here. The source code is copyrighted, and protected in that fashion from copying. To the extent the source code is a trade secret, the trade secret status of it can be preserved by appropriate court orders. I have tried numerous trade secret cases, and the court can easily conduct these trials and make appropriate orders to protect any trade secrets that must come into evidence in the trial.

The arguments are specious on both sides. First, the defense does not need the source code to tell if the machine accurately detects BAL. It can easily be determined whether it works or generates random numbers by testing a statistically significant number of subjects with the machine and also with a blood test and comparing the results. What a BS argument by the defense. The prosecution is only resisting because to counter the argument it needs to go hire software expert witnesses, and to do that in a DUI case is way over budget.

Shame on the judge for getting hoodwinked on this issue. I hope the appropriate arguments were raised in the trial court that will get this stupid ruling reversed on appeal. Just MHO.

Paratus et Vigilans
08-10-2007, 8:22 AM
Oh, yeah, BTW, the state is not likely in possession, custody or control of the source code. The machines the police buy have only the object code, the executable program, stored in them, either on some kind of hard drive or other accessible memory or perhaps burned right into the ROM chips that run the machine. So, they've got an order they can't comply with because the owner of the source code is not before the court - - at least not that one could tell from reading that report. All you techies out there who know more than I do about this correct me if I'm wrong, but the MOST the state could do would be to turn over the object code to the defense and let it run it through a decompiler, right? And that may or may not get you an accurate picture of the source code, correct?

leelaw
08-10-2007, 8:40 AM
It's highly unlikely that the State has the source code. The individual breathalyzers either have the compiled code burnt to a chip or being run by software on the machines.

It's kinda like asking me for the original blueprints for my car - I own the finished product, not what was used to create it.

Prc329
08-10-2007, 8:55 AM
It's highly unlikely that the State has the source code. The individual breathalyzers either have the compiled code burnt to a chip or being run by software on the machines.

It's kinda like asking me for the original blueprints for my car - I own the finished product, not what was used to create it.

In this case it looks like the state may own the source code. Looks like te contract was for the state to retain rights to the code. So it would be like buying your care and the rights to the blueprints.

Minnesota's original bid proposal that CMI responded to says that "all right, title, and interest in all copyrightable material" that CMI creates as part of the contract "will be the property of the state." The bid proposal also says CMI must provide "information" to be used by "attorneys representing individuals charged with crimes in which a test with the proposed instrument is part of the evidence," which seems to include source code.

Paratus et Vigilans
08-10-2007, 9:25 AM
Good catch, PRC329!

That's what I get for reading too fast! :o

leelaw
08-10-2007, 9:26 AM
Good catch, PRC329!

That's what I get for reading too fast! :o

Same. In that case, I can't see an argument for the State.

bwiese
08-10-2007, 11:54 AM
I also fail to see the IP issue here... source code is copyrighted and protected in that fashion from copying. To the extent the source code is a trade secret, the trade secret status of it can be preserved by appropriate court order.

Regardless of such legal issues and court-ordered access to source, more problematic situations (generally speaking, not just breathalyzer issues) exist when the device mfgr is:

outta business, source code unavailable anymore


has problems with availability of source code (you'd be surprised how many small companies that have been building an unupgraded product for an extensive time period can't recreate their object code from source any longer and essentially have 'frozen' product not upgradable without complete code re-creation. Appears to be the case with many consumer products - including the HP-12C financial calculator. Reverse engineering can help but there'll still always be areas of code, esp in embedded systems, having specific reasons for existing but as time goes on and staff changes and with no comments, no one remembers why. Way more common than you think esp when companies buy each other out, relocate operations to different buildings or cities, hire contractors for projects, and servers w/old soruce accidentally don't get backed up or old archives are unreadable.


Poorly-commented code combined w/high staff turnover. "Why the hell did Joe do this?": Joe's no longer around, refuses to talk w/company or can't be found/contacted. Joe may've masked a hardware bug that was long forgotten with a software tweak - and then hardware gets updated and software tweak no longer necessary (or is even harmful).


Above goes on all the time in small companies and small divisions of large companies that were acquired and not organic. Stuff gets released as a fix without going thru a whole testing cycle. Ask GMC about the Cadillac air conditioning driveability tweak to ECU firmware - didn't go thru emissions test lab, slightly above emissions limit, $60 Million EPA fine.

First, the defense does not need the source code to tell if the machine accurately detects BAL.

True, you can monitor general trends. But these are criminal cases and 'reasonable doubt' exists when the exact value arrived at is not traceable/provable.

Given that typical complex instrumentation has algorithms for variabilities like sensor aging, temperature, EMI/RFI alleviation (were you parked by a 50KW radio station when being brethalyzed?) there's multiple failure points and corner cases that can well exist in specific combinations or ranges. Also, what if the programmers used crazy rounding strategies? I've seen lotsa bad math/bad assumptions/"easy way out" stuff during schedule crunches in software/firmware. These can have varying and nonlinear effects in various points. When stuff needs to ship, things start getting crossed off the list quickly.

(Roughly similar end effects could actually happen in the old 'analog meter' world - what if a typical D'Arsonval meter movement had binding in it affecting its needle's return to a lower value? And calibration history of radar detectors is indeed useful in traffic defenses. I would expect, as radar/LIDAR guns use firmware that this FW defense'll come up too.)

can easily be determined whether it works or generates random numbers by testing a statistically significant number of subjects with the machine and also with a blood test and comparing the results.

That measures general trends but not discrete quantized values that are the starting, intermediate or final results of a calculation. There can well be bugs that apply to subset ranges of quantized values or individual discrete values (i.e, bit patterns representing a given number/value) for all the above reasons - or even just bad math algorithms sensitive to certain bit patterns.

Remember Intel's Pentium math bug? The one occurring in division - only happened with certain dividend/divisor value combinations? It was caused by a hardware design bug in the Raidix-4 SRT division algorithm where trial divisor table (IIRC) had problems with address decoding. Slipped by testing, and low-level chip testing is pretty damned extensive.

Remember the mid-80s GM fuel injection system bug, cars ran rough because of (again) a division failure?

Source code can help detect object code errors. 1987/88 Porsche 911s (with Bosch Motronic-II EFI systems w/4KB of firmware) had a dead 00 byte in the part-throttle fuel map. This caused a lean spot that was averaged out into less-lean by surrounding fuel delivery values. Nevertheless if driving regime regularly traversed into this load/RPM region engine damage could've resulted from excess lean. I suspect the nature of the way they burned their EPROM chips may have introduced this error. Again, there's always a chance that, somehow, some way, what's burned on the machine got tweaked accidentally from what was intended. Checksums/CRCs of the programs and various data structures can avoid that - but these may not be common on a 1988 instrument using a Z80 CPU and 8K of (EP)ROM.

From 1976 to '81 most every Texas Instrument extended function calculator (mostly LED ones with the 5x8 Klixon keypad, and including the famous high-volume TI-30) had bugs in multiplication algorithm because their guys appear to have decided to do multiplication backwards - most significant to least significant digit order! - and compensate later in the calculation. Unfortunately the fixups didn't work: low-order digits were often in error. From http://www.vcalc.net/ti-accry.htm


...TI was the only calculator maker which used a wrong method for multiplication, causing the final digits of many products to be incorrect! For example, 1.9999999*4.9999999 happens to be exactly 9.99999930000001 so that any self-respecting "truncating" calculator giving 8 to 14 digits of result should have given the answer as 9.9999993; however, the TI Programmer (and *all* other TI models of that era having internal registers that kept 9 significant digits and rounded the display to 8 digits) would have displayed 9.9999987 or so! Other models which kept 11 internal digits (but still displayed only 8) also had this same fundamental bug, but the errors were usually concealed by the fact that the last three digits of the internal result, which were incorrect, remained unseen; you can nonetheless "see" the hidden incorrect digits by subtracting out the correct leading portion of the result (e.g. subtract 9.99999 in the above example), which will then disclose all the following digits (a final multiplication by, say 100000, may be necessary also, to shift all displayable digits into view).

All scientific models which used algorithms to derive other functions (log, trig, etc.) were likewise affected by the fact that every time they did a multiplcation as part of that algorithm, the answer came out a bit too small, producing a distinct tendency for "chained" results (e.g. 30 SIN INV SIN SIN INV SIN ...) to keep dropping in value.

My analysis of how TI did this feat is that instead of correctly starting with the least-significant multiplier digit, and then shifting rightward the fully-developed rightmost digits of what otherwise would have been a fully correct double-precision result as each successive more-significant multiplier digit was used, some hacker at TI decided to start with the most-significant multiplier digit, and then shift rightward the other factor, dropping off its least significant digit even before the second most-significant multiplier digit was used, etc.

...you can see immediately that the product of the least significant digits of each factor will never be included in this scheme; in fact many other of the "digit cross-products" are neglected as well. If you look at the numerical example I gave above, even the very least significant "9*9" product is essential for generating a "carry" which propagates all the way leftward into the eighth most-significant digit position of the correct answer, so obviously the result of the "hack" method is already clearly going to be incorrect. If you take into account the internal register widths actually used and the sum of all the "lost" digit cross-products, you successfully predict the exact wrong results which those TI calcs delivered for several years!

While you may think the above problem's small, if this bad value is used as a divisor of a division, end error variance can get magnified nonlinearly. Somewhere/someplace a calculation may well have been made for a go/no-go decision based on such an bad result.

HP financial calculators (orig HP12C vs. new 12C/Platinum) use different firmware/algorithms and rounding strategies. Two Wall Street types figuring bond yields will get two different answers with differing calculators.


What a BS argument by the defense ... prosecution is only resisting because to counter the argument it needs to go hire software expert witnesses, and to do that in a DUI case is way over budget.

It's what a defense lawyer's supposed to do. State has burden to prove beyond reasonable doubt a crime occurred. Little companies with proprietary software living on gov't gravy contracts may well have gotten sloppy since they sell a fixed product over long period of time. There's so many layers of indirection from sensor to readout there are multiple failure points possible.

Shame on the judge for getting hoodwinked on this issue...hope the appropriate arguments were raised in the trial court that will get this stupid ruling reversed on appeal.

No, and you can expect more of this. As our lives get touched by firmware more and more, these issues will come into play in both civil and criminal matters.

tiki
08-10-2007, 12:42 PM
... the defense does not need the source code to tell if the machine accurately detects BAL. It can easily be determined whether it works or generates random numbers by testing a statistically significant number of subjects with the machine and also with a blood test and comparing the results. ...

I would like to volunteer for the test group.

eta34
08-10-2007, 12:55 PM
Are there any arguments against the accuracy of the blood test so far? Why not simply submit to a blood test of the accuracy of the results is in question?

bwiese
08-10-2007, 1:03 PM
Are there any arguments against the accuracy of the blood test so far? Why not simply submit to a blood test of the accuracy of the results is in question?

Actually the blood test instrumentation could have the same issues outlined above as the breathalyzer. It's all machinery with firmware now. Calibration history could play a part too. This is not really an argument about blood vs. breath, it's about due process and reasonable doubt issues relating to criminal charges and how traceability, calibration, complexity and software/firmware composition all add doubt to the process.

Really, all electronic metering for criminal matters ultimately may require readings on 3 or more different metering devices from different manufacturers with completely different sensors and firmware.

Also, some people don't like needles, the breathalyzer is a roadside test if I recall correctly, and some folks may think things will go faster. People do - last time I checked - have a choice of alcohol tests in CA.

eta34
08-10-2007, 1:19 PM
Based on this article, I believe it is referring to the Intoxilyzer, which is the large machine in the jail. The roadside test (PAS Preliminary Alcohol Screening Device) is the small, hand-held device that is completely voluntary. The blood/breath test can be refused, but the DMV automatically suspends your license for a refusal.

And yes, you are correct...you have your choice of blood or breath tests.

Smokeybehr
08-10-2007, 1:37 PM
Based on this article, I believe it is referring to the Intoxilyzer, which is the large machine in the jail. The roadside test (PAS Preliminary Alcohol Screening Device) is the small, hand-held device that is completely voluntary. The blood/breath test can be refused, but the DMV automatically suspends your license for a refusal.

And yes, you are correct...you have your choice of blood or breath tests.

Urine is also a choice.

Prc329
08-10-2007, 2:18 PM
Are there any arguments against the accuracy of the blood test so far? Why not simply submit to a blood test of the accuracy of the results is in question?

I am no law professor but wouldn't if the firmware was found to be flawed make the original arrest invalid so anything occurring after the original arrest null and void? Kinda like when a person is not read there rights?

bwiese
08-10-2007, 2:57 PM
I am no law professor but wouldn't if the firmware was found to be flawed make the original arrest invalid so anything occurring after the original arrest null and void? Kinda like when a person is not read there rights?

I'm guessing if the firmware were found to be flawed the case would be dismissed. Proving it flawed could take effort. Proving it not flawed could take more effort/cost by DA.

Plea to reckess driving might be offered by DA, not sure, in an initial bid to keep case alive.

Officer testimony about impaired driving still might be useful.

Paratus et Vigilans
08-10-2007, 5:17 PM
So Bill,

Can I put you on my expert witness list the next time I've got a software case? :)

I respectfully withdraw my "BS" call on the defense argument re the breathalyzer.

However, I think that, for reasons of practicality, we ought to have a law that provides that electing the breathalyzer test over blood or urine waives any challenge to the accuracy of the test. Maybe no one would choose it then, but I think that to go through this kind of challenge makes the use of it not cost effective for LE and the courts.

I have spoken with colleagues who do DUI defense and have been told that the smart test to seek is the blood test because by the time they get you to the station to get a blood sample you may already be past your peak BAL, in case your are close to the limit, and will likely test below .08 when breath or urine would show .08 or higher. Or maybe it's urine you should take. S***, just don't D & D and don't worry about it!

bwiese
08-10-2007, 6:05 PM
So Bill, Can I put you on my expert witness list the next time I've got a software case? :)

I respectfully withdraw my "BS" call on the defense argument re the breathalyzer.

Haha, withdrawal accepted.

You wouldn't want me as an expert witness, I have no college degree or certification. I'm just a dude who writes firmware and a few things or two about ARs :) If that does come about I'd be glad to take a look at something, do the prep work and then you get a Reg'd Professional Engineer to testify. (Not that any Calif. Prof. Engineering EE standard is remotely relevant, but at least that's a credential - I don't think there's very many Reg Prof Engineers in Silly Valley doing chip design as the formal state EE certification mostly deals with motors and generators etc.)


However, I think that, for reasons of practicality, we ought to have a law that provides that electing the breathalyzer test over blood or urine waives any challenge to the accuracy of the test. Maybe no one would choose it then, but I think that to go through this kind of challenge makes the use of it not cost effective for LE and the courts.

The problem is, those machines that do analysis of blood or urine can or do suffer the same flaws as a Breathalyzer: they're fallible instruments with hundreds of failure points in hardware/software btwn the sensor and the actual reading.

I think any government-owned instrument used for criminal prosecution needs a publicly-traceable calibration history and available source code for analysis.

FreedomIsNotFree
08-10-2007, 8:03 PM
Radar guns faced the same scrutiny in the beginning. They, law enforcement, has since set strict guidlines in terms of when and how the units must be tested/calibrated and how those records are stored and made available to defendants in criminal prosecutions. I believe there should be such a standard with any test the government chooses to use against the people. Machines may be unbiased, but they are not infallible.

On a side note...you dont need to blow a .08 to be found guilty of drunk driving. An officer can testify in court that your .04 or .02 made your driving unsafe and you can still be found guilty. Of course, this type of prosecution is uncommon and tougher, from the prosecutions standpoint, but not impossible.

Jicko
08-10-2007, 8:27 PM
As long as you DO NOT perform the Monkey-Test, and the roadside Breathe-Test..... (yes, it is your right to refuse to do those test, just agree that you WILL take the test @ the station)

It will give a good lawyer a good chance to fight you out of your DUI case.

Because, consider this scenario:

You live 5 minutes from the place you are drinking, you didn't drink ANYTHING for the whole night, and you drank 3 shots of Vodka right before you jump onto your car, you drove for 3 minutes and got stopped buy the cop.... at that VERY moment, you probably not NO alcohol in your blood AT ALL (BAC ~0.00).

You refused to take ANY test on the roadside, the cop ended up arresting you, and taking you to the station for either a breathe or blood test..... and by the time the test was taken, it is 30min-1hr, from the time you were stopped, and the 3 shots of Vodka are absorbed into your blood, and your BAC is now 0.10 or more, ie. over 0.08 legal limit....

But if the cop hasn't stopped you, you would be home in 5 minutes, and you probably STILL have NO alcohol in your blood, and you will just stayed home and let the alcohol get into the blood.... hence you really DID NOT "drive" under influence.... since the alcohol hasn't hit you yet at the time when you are driving!


So, as long as you DO NOT take any roadside test, which give them "immediate evidence" that you are "under influence" when you drove.... and the ONLY "evidence" of your BAC is taken LONG after you drove, back at the police station, they will have to prove that you weren't EXACTLY in the above quoted situation..... and the jury cannot *easily* "without a doubt" end up in a GUILTY verdict.

But then, to get away.... it will cost you probably $5-$10k..... yet, it is still better than a DUI conviction..... so REMEMBER, NOT TO TAKE the roadside monkey-test and breathe-test..... that monkey-test, even if you are completely sober, you will still fail it.... it is designed to fail people....

FreedomIsNotFree
08-10-2007, 8:39 PM
As long as you DO NOT perform the Monkey-Test, and the roadside Breathe-Test..... (yes, it is your right to refuse to do those test, just agree that you WILL take the test @ the station)

It will give a good lawyer a good chance to fight you out of your DUI case.

Because, consider this scenario:


So, as long as you DO NOT take any roadside test, which give them "immediate evidence" that you are "under influence" when you drove.... and the ONLY "evidence" of your BAC is taken LONG after you drove, back at the police station, they will have to prove that you weren't EXACTLY in the above quoted situation..... and the jury cannot *easily* "without a doubt" end up in a GUILTY verdict.

But then, to get away.... it will cost you probably $5-$10k..... yet, it is still better than a DUI conviction..... so REMEMBER, NOT TO TAKE the roadside monkey-test and breathe-test..... that monkey-test, even if you are completely sober, you will still fail it.... it is designed to fail people....

There may be reasonalbe doubt in your mind, from the above scenario, but I can tell you from experience that juries are not fond of drunk dirvers and they are most likely to side with the prosecution unless given good reason. Just because there is reasonable doubt in your mind or my mind or EVEN the juries mind, this does not mean a defendant wont be found guilty. Quite often jurors on the fence get talked to one side or the other so the jury can finish the trial and go home...its a reality.

Jicko
08-10-2007, 8:52 PM
Sure.... no guarantee that it will WORK....

But, know your rights... and if you are "just so happened", in that "one time", that you know you may have some alcohol in your blood.... and "unfortunately" got pulled over...

You are better off NOT DOING THOSE TEST..... and drag the potential testing time as long as you can....

Which means... not take roadside tests, get to the station..... ask to take the blood test, which they have to find a registered nurse to come take the your blood..... and then RIGHT before they take it.... freaks out, and ask to take the breathe test...... and then keep burp'ing, and keep coughing (all these actions, invalidate the test; or reset their requirements to monitor you for a continuous 15minutes)..... and at the end, they probably will either take your breathe test.... OR, ended up taking you blood sample....

All of the above have no guarantees..... YMMV..... yet MUCH better chance of getting away than giving them "immediate evidence".... (and don't even think that you can BEAT the roadside test and the cop will let you go.... all they want is to arrest you.... so, almost any result, you are going downtown anyways!!)

With "immediate evidence", you probably don't even have to try to go for a jury trial, since... it is a slam dunk for the DA for that DUI conviction!

RudyN
08-12-2007, 10:42 PM
The best thing to do is DON'T drink and drive period. I have no sympathy for anyone who drives after drinking and gets caught.