Computer generated evidence and defence access to source code

Today's Irish Times reports on an interesting clash between the rights of an accused person to a fair trial and what breathalyser manufacturers see as their commercial interests:

A solicitor from Co. Louth is seeking a judicial review of a drink driving conviction...

Paul Moore, a solicitor in Monaghan, is arguing that because the manufacturers of the Lion Intoxilyzer breath testing machine did not provide him with a hard copy of the software it uses that a conviction was made in the absence of full disclosure and therefore the constitutional rights of the accused person were not upheld...

At an earlier court hearing Judge Flann Brennan had made an order of disclosure. When pressed on why the software was not disclosed pursuant to that order, Mr. Blythe [a senior manager with the manufacturers] told Alan Doherty, defending, that "the company is adamant that it does not disclose software documentation". He also said he believed that this was for commercial reasons.

This is the first Irish case that I'm aware of where disclosure of source code has been sought in the context of a criminal prosecution, though there has been a good deal of litigation on this point in the United States, where companies have also refused to turn over source code with the result that many cases have been dismissed.

This is certainly the correct result - if a person may lose their liberty based on a number generated by a machine, they must be able to challenge the accuracy of that number - which they cannot do unless they know how that machine operates. The manufacturer's failure to comply with a court order on the basis of "commercial reasons" is astonishing - if they believe that their commercial interests are superior to the right of an accused person to a fair trial and are unwilling to comply with the order of the court then they should not be manufacturing this equipment nor should our justice system be purchasing it.

Ethan Zimmerman of the EFF has some insightful comments on the US cases, and draws an analogy with electronic voting:

Matt Zimmerman, a staff attorney for the Electronic Frontier Foundation (EFF), said it is just as important for people to know that products like breathalyzers or voting machines work correctly as it is for companies to protect their trade secrets.

"It's one of the few cases that we've seen recently where a court has come out and said it really is appropriate, if you're going to be making important decisions that affect someone's liberty, then you should be able to understand what's going on with these technologies that are helping make these decisions," Zimmerman said.

He said that in addition to various fears over losing proprietary advantages, companies may also fear that public examination of software would let the public know "there may be some flaws in the design, in the coding, that otherwise they wouldn't have to reveal."

"The government is outsourcing a governmental process," Zimmerman said of both e-voting and the breathalyzer questions. "It's not a case where you're alleging that a certain harm has been done to a specific person. You're making the allegation that the technology doesn't do its work quite as well as it could."

The key to both concerns is the potential for these devices to affect people's liberty and freedom, while the manufacturers do not provide the public with the information to know what is going on, Zimmerman said. Both cases, he said, should tell the government that the public has a right to know how technologies actually work when they have to do with individual liberty.

Update (10/8/07): Declan McCullagh has details of a recent Minnesota decision ordering disclosure.
Update (5/9/07): The code of one US breathalyser has now been analysed and found to be extremely sloppy:

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…

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 Food and Drug Administration (FDA), as well as commercial standards used in devices for public safety…If the FAA imposed mandatory alcohol testing for all commercial pilots, the Alcotest would be rejected based upon the FAA safety and software standards…

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

6. Diagnostics Adjust/Substitute Data Readings: The diagnostic routines for the Analog to Digital (A/D) Converters will substitute arbitrary, favorable readings for the measured device if the measurement is out of range, either too high or too low. The values will be forced to a high or low limit, respectively. This error condition is suppressed unless it occurs frequently enough…

7. Flow Measurements Adjusted/Substituted: The software takes an airflow measurement at power-up, and presumes this value is the “zero line” or baseline measurement for subsequent calculations. No quality check or reasonableness test is done on this measurement…

10. Error Detection Logic: The software design detects measurement errors, but ignores these errors unless they occur a consecutive total number of times. For example, in the airflow measuring logic, if a flow measurement is above the prescribed maximum value, it is called an error, but this error must occur 32 consecutive times for the error to be handled and displayed. This means that the error could occur 31 times, then appear within range once, then appear 31 times, etc., and never be reported…