Court Orders Breathalyzer Code Opened, Reveals Mess
Death Metal writes with an excerpt from the website of defense attorney Evan Levow: "After two years of attempting to get the computer based source code for the Alcotest 7110 MKIII-C, defense counsel in State v. Chun were successful in obtaining the code, and had it analyzed by Base One Technologies, Inc. By making itself a party to the litigation after the oral arguments in April, Draeger subjected itself to the Supreme Court's directive that Draeger ultimately provide the source code to the defendants' software analysis house, Base One. ... Draeger reviewed the code, as well, through its software house, SysTest Labs, which agreed with Base One, that the patchwork code that makes up the 7110 is not written well, nor is it written to any defined coding standard. SysTest said, 'The Alcotest NJ3.11 source code appears to have evolved over numerous transitions and versioning, which is responsible for cyclomatic complexity.'" Bruce Schneier comments on the same report and neatly summarizes the take-away lesson: "'You can't look at our code because we don't want you to' simply isn't good enough."
Poorly written code is one thing, but does it ultimately work?
not written well, nor is it written to any defined coding standard
Ah, so it's like most of the code in the world.
Because the output is used as evidence in court?
Ok, I'm not happy that some people almost certainly were measured inaccurately by these things. I'm not happy that this company was allowed to pull this kind of shit -- when you do government contracting, the government should own what you do.
However, I am very glad that the precedent has been set.
And I am especially glad that not only is there precedent, but there's a real live example of why we need this stuff to be open.
Don't thank God, thank a doctor!
80% of the code in business fits this description. With 20 year old legacy code written by 50 consultants, then upgraded in India, then ported from one platform to another to another, and a database engine switch or two. Code gets senile. What do they expect? Good thing we're all just commodities... human lego bricks easily replaced with cheaper plastic.
Disconnect your television. Do your own research. Draw your own conclusions. They're probably lying. Don't be a sheep.
Clearly their programmers were not drunk enough when making this. Or, they were too drunk.
How else would you suggest they test whether or not it works? Huh, smartguy?
Just read Schneier's comments. He cites some of the more important things:
Readings are Not Averaged Correctly: When the software takes a series of readings, it first averages the first two readings. Then, it averages the third reading with the average just computed... There is no comment or note detailing a reason for this calculation, which would cause the first reading to have more weight than successive readings.
That alone should be enough -- the readings are not averaged correctly. But it goes on:
The A/D converters measuring the IR readings and the fuel cell readings can produce values between 0 and 4095. However, the software divides the final average(s) by 256, meaning the final result can only have 16 values to represent the five-volt range (or less), or, represent the range of alcohol readings possible. This is a loss of precision in the data; of a possible twelve bits of information, only four bits are used. Further, because of an attribute in the IR calculations, the result value is further divided in half. This means that only 8 values are possible for the IR detection, and this is compared against the 16 values of the fuel cell.
So we know it's buggy and inaccurate, to a moronic degree. If that wasn't enough:
Catastrophic Error Detection Is Disabled: An interrupt that detects that the microprocessor is trying to execute an illegal instruction is disabled, meaning that the Alcotest software could appear to run correctly while executing wild branches or invalid code for a period of time. Other interrupts ignored are the Computer Operating Property (a watchdog timer), and the Software Interrupt.
So, basically, it's designed to always return some value, even if it's wildly inaccurate, and even if the software is executing garbage at the time.
In other words: It appears to be a very low-level equivalent of Visual Basic's "on error resume next".
Whiskey. Tango. Foxtrot.
So to answer your question: No, it does not work. Even if it did somehow work, there's obviously an unacceptably poor level of quality control here.
Don't thank God, thank a doctor!
Er, why would it need or be expected to be? It's a commercial product. I don't think most bank websites are "coded" to any specific standard either.
From the article:
1. The Alcotest Software Would Not Pass U.S. Industry Standards for Software Development and Testing: The program presented shows ample evidence of incomplete design, incomplete verification of design, and incomplete "white box" and "black box" testing. Therefore the software has to be considered unreliable and untested, and in several cases it does not meet stated requirements. The planning and documentation of the design is haphazard. Sections of the original code and modified code show evidence of using an experimental approach to coding, or use what is best described as the "trial and error" method. Several sections are marked as "temporary, for now". Other sections were added to existing modules or inserted in a code stream, leading to a patchwork design and coding style.
Ok. Would you want to have something that can cause you to get convicted because it wasn't documented or even tested fully - ("Oh, Crap. That constant should have been 0.001, not 0.01. Ooops. Blood Alcohol level was 0.008, not .08. Sorry !")
Common sense (if it WERE common) should indicate that there should be full tests for a wide range of values performed with the written tests and expected values verified and available to prove that the device/software actually does detect the proper levels of alcohol.
UPS Sucks
This will not stop the state from using this to make a felon of you.
The Navy Motto "IF it ain't broke Fix It" "A day is wasted if you don't learn something new"
If you got your hands on and analyzed the sourcecode to most DVD' players, TV's (Panasonic runs linux!) and other devices that are complex you will discover that in order to ship it earlier the code is an utter mess.
Programmers are not joking when we complain about the "It compiles? Ship it!" statement.
the fault is the Executive staff that refuse to listen to their experts (programmers) and do what they recommend. Instead we get morons that know nothing about programming making unrealistic deadlines and forcing death march coding marathons to give up the mess we have today.
Do not look at laser with remaining good eye.
Did they find any coding bugs,
Yes. RTFA.
2. Readings are Not Averaged Correctly: When the software takes a series of readings, it first averages the first two readings. Then, it averages the third reading with the average just computed.
There you go. It's also inaccurate:
The A/D converters measuring the IR readings and the fuel cell readings can produce values between 0 and 4095. However, the software divides the final average(s) by 256... Further, because of an attribute in the IR calculations, the result value is further divided in half. This means that only 8 values are possible for the IR detection...
And, if there were a catastrophic bug, you wouldn't know it, you'd just keep getting readings:
An interrupt that detects that the microprocessor is trying to execute an illegal instruction is disabled, meaning that the Alcotest software could appear to run correctly while executing wild branches or invalid code for a period of time. Other interrupts ignored are the Computer Operating Property (a watchdog timer), and the Software Interrupt.
This belongs on The Daily WTF.
Don't thank God, thank a doctor!
At a previous job we had to buy a third-party driver for an embedded PCMCIA controller. The software vendor delivered code that (the first time around) produced about 1200 lines of warnings when we compiled it. We queried them about it and they responded that "we don't compile with warning output enabled". Our reply to them was that our coding standard was that the compile would fail on warnings, and we wouldn't accept their code unless they fixed all the warnings... they cleaned up their act, and fixed a couple of previously unresolved problems in the process.
Less is more.
It appears that the NJ Supreme Court wasn't swayed too much by the source code evaluation. They're planning on reinstating the device with only minor modifications.
Xfce: Lighter than some, heavier than others. Just right.
10 REM Alky 0.1 A. Coder 2001
20 REM Turn off lights and buzzer
24 POKE 201,0
26 POKE 202,0
28 POKE 53280,0
29 REM Any Breath?
30 IF PEEK(200) = 0 THEN GOTO 30
32 REM Buzzer
33 POKE 53280,1
34 PAUSE(2)
35 POKE 53280,0
36 REM Lights...
40 A = 10 * RND(1)
50 IF A > 5 GOTO 80
60 REM Red light
70 POKE 201,1
75 GOTO 100
76 REM Green Light
80 POKE 202,1
100 PAUSE(3)
120 GOTO 20
AT&ROFLMAO
If I were the manufacturer, at this point I'd say: (1) lawyers are expensive; (2) competent programmers are expensive, but less expensive than lawyers; (3) our business is selling the beathalyzer, not the software, so we gain nothing by keeping the source secret; (4) this publicity is hurting us; (5) let's hire some more competent programmers to clean up the code, and then we can make it public; (6) profit!
This is different from the case of the voting machines. In the case of a voting machine, there are lots of people who might be motivated to hack it, lots of people have access to the machines, and it only takes one compromised machine to throw a close election. If you believe in security by obscurity, then there is at least some logical argument for keeping the voting machine code secret. In the case of the breathalyzer, there's not even that lame argument.
Find free books.
The good: This particular breathalyzer has been proven to be the unreliable POS that it apparently is. This unit, and others like it, will finally start being held to a stronger coding standard.
The bad: every sleezeball, ambulance chasing, "call lee free", douchebag of a lawyer will use this case to attack the credibility of any and all breathalyzers made in the past, present, or future, spreading enough FUD to juries everywhere that an unacceptable number of drunken idiots get the God given right to keep their license until they finally end up killing someone.
As a person, I think groups like MADD spend most of their time trying to scare monger politicians into pushing us as close to prohibition as possible. I believe that alcohol can be used responsibly. But I also know that this case is going to result in DUI's getting overturned for people that damn sure don't deserve it. Borderline cases will get knocked down, cases will get thrown out, and the people that broke the law, that did something wrong, will walk out of a court room 'vindicated.' They didn't do anything wrong when they had six beers and drove home, it was that confounded *machine* that *said* they broke the law. The *machine* was busted, ergo they didn't break the law. In short, this case is going to make a lot of O.J. Simpson's. The jury said they didn't commit a crime, so they didn't. No harm no foul. Technicality? Bah! They're as innocent as the sweet baby Jesus.
I'd like to think things will wash out in the end. This case will probably end up making it harder to get off on this particular technicality in the long term. In the short term? Here come the appeals. Maybe the state is partially at fault for buying shoddy equipment. (Or maybe not. Did they do a code review? Do they have the resources to one? Probably not. Did you do a code review of the 3com switch in your server room? Their selection criteria can certainly be questioned, but it probably doesn't change the fact that someone drank enough to blow a .22 then decided to drive home.)
But in the end, the drunks are still going to be drunks. And tomorrow some of them will probably get to file appeals, and some of the ones that shouldn't be on the road, or even in public, will get to slip out of this brand new loophole. I'm not sure that that deserves a cork-popping celebration.
(and yes: We all handle our booze differently. Arbitrary limits that determine "drunk" may or may not be the answer. Hardcore drunks will keep driving even after losing their license. DUI's are as much moneymakers for the States as speeding tickets. Yadda yadda yadda.)
There are some people that if they don't know, you can't tell 'em.
Perhaps they're coded inelegantly or poorly, but do they actually spit out inaccurate numbers?
Irrelevant - the test is: do they always spit-out provably correct numbers?
I work on embedded system stuff every day. At the end of the day, there are NO lint warnings in my code. First, I tend to avoid coding practices and designs that generate lint warnings. By and large, lint warns for a good reason most of the time. Second, in the limited number of situations where lint flags something incorrectly, there are methods for silencing the warnings via special comments. I'm currently working on a 50000 line project, and there are about 70 places in the entire code base were we had to tell lint to ignore a warning. Each warning suppression is documented as to why lint is incorrect.
Lint isn't a perfect tool by any means but in my opinion, anyone developing C code without it is not acting in a professional manner.
"DUI defendant finally gets access to breathalyzer code, ironically finds developers were probably drunk when they wrote it". http://www.fark.com/cgi/comments.pl?IDLink=4387892
OK, LOTS of strange posts from people who claim to have read the article but only see that it's bad code, not actually broken.
Read it again. It's broken from a legal liability and trustworthiness standpoint. It's broken from a precision standpoint. It's broken from an algorithm standpoint. It is not trusworthy, precise, accurate, or correct.
"It is clear that, as submitted, the Alcotest software would not pass development standards and testing for the U.S. Government or Military. It would fail software standards for the Federal Aviation Administration (FAA) and Federal Drug Administration (FDA), as well as commercial standards used in devices for public safety. This means the Alcotest would not be considered for military applications such as analyzing breath alcohol for fighter pilots. If the FAA imposed mandatory alcohol testing for all commercial pilots, the Alcotest would be rejected based upon the FAA safety and software standards."
Nobody in the government or military would be allowed to trust this, if it weren't already in use.
"Results Limited to Small, Discrete Values"
Sixteen values is all it displays! It throws away almost all of the precision of the 12-bit ADC, and reduces it to 4 bits! This is NOT precise enough!
"Catastrophic Error Detection Is Disabled"
"Diagnostics Adjust/Substitute Data Readings"
"Range Limits Are Substituted for Incorrect Average Measurements"
"The software design detects measurement errors, but ignores these errors unless they occur a consecutive total number of times."
It's not correct. It's not accurate. It's not good enough. The odds are VERY good that some people over the limit have gotten off lucky, and also that some people below the limit now have criminal records.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
With an attitude like that, it's obvious that you have little experience with embedded systems...
:(){
Equipment can break down and programming errors do occur. Because of the safety issues involved, signals are equipped with a "conflict monitor." A conflict monitor is a simple device, completely independent of the controller, that watches the signal operate. It does this by monitoring a number of conditions, including the voltage to the individual bulbs in the heads.
If a condition occurs which is not normal (for example opposing greens) the conflict monitor detects the condition and shuts down the intersection. Normally, it places the signal on "flash mode." The main street is given a flashing yellow, to indicate that the situation is not normal and caution is needed. The secondary street is given a flashing red light that should be treated like a stop sign. For safety reasons, the signal will not normally reset itself. A technician must visit the intersection, determine the problem and reset the controller.
Testimony is subject to cross-examination (at least in the US). Opposing counsel has the opportunity to exploit weaknesses in the witness's testimony. Also, the witness is subject to prosecution for perjury for lying. What penalty does a faulty (if it be faulty) device face?
Assuming the microcontroller has a 10-bit A/D converter to get the reading, I'm pretty sure such a chip could add 32 numbers together. With the speed of 8-bit microcontrollers these days exceeding 1MHz even at ~$1 price points, emulating 16 bit numbers to get your sum is not a problem. Take a power-of-two number of readings and your average can be a simple bit shift. It will take more horsepower to convert to base-10 on the display than to take the average.
This is not a cheap child's toy or a toaster, it's a law-enforcment grade breathalyzer going for above $100; there is no excuse for being so lazy. Code that runs on small systems should be *clean* because bugs are harder to find without easy I/O, and the efficiency of it needs to be obvious. Also, code that can put someone in jail should not be spaghetti, regardless of the scale of the system running it.