Previously I spoke about a closed source Diebold electronic voting system which was proven to be faulty. An open source solution in matters of such importance does much more than merely provide something presumed to be cost-effective or “free” but rather establishes trust and confidence.
A manual ballot counting system is trustworthy as any person is entitled to view the counting of the votes and to observe the ballot box is not tampered with in any way.
By contrast, a closed source ballot counting system is a mysterious black box. Can the ordinary person on the street be confident it does not fudge the count? That it does not introduce errors?
In Diebold’s case, an open source Python program proved specific voting systems they sold were miscounting votes and the company even knew about the bug but never disclosed it to its customers.
This last week another closed source software program hit the news because of its failures. This time around it is the software powering a breathalyser, as used by police officers around the world.
The fact software powers such a device is news to me; I always just figured it was a chemical reaction going on, but thankfully my experience with breathalysers is fairly limited.
The case in particular is State v. Chun where defense counsel spent two years trying to obtain the source code for the Alcotest device. They succeeded and submitted the code to Base One Technologies who performed a thorough code review.
The review found a stunning 19,400 potential errors.
Base One Technologies even went so far as to state the program showed “ample evidence of incomplete design, incomplete verification of design, and incomplete ‘white box’ and ‘black box’ testing. Therefore,” they state, “the software has to be considered unreliable and untested, and in several cases it does not meet stated requirements.”
That’s barely the tip of it!
Base One Technologies noted several sections of the code were marked as “temporary, for now” indicating the programmers knew their work was incomplete but had failed to return and repair it.
If you wish to average a collection of readings you must consider them all. The average of 12, 18 and 21 is 17. However, the Alcotest unit would determine the average of the first two readings - giving 15 in the case of 12 and 18 - and would then take the average of this calculated number and the third reading – giving 18 in this example, the average of 15 and 21 being 18.
Such a flaw means the device does not succeed in its stated purpose, with all documentation explaining the unit calculates averages of a series of readings.
Another problem is that the microprocessor’s catastrophic error detection interrupt was disabled meaning that if an illegal instruction was encountered the device will still appear to run correctly even though it was executing arbitrary code.
These are staggering revelations. Indeed, Draeger – the manufacturer – may well find themselves on the end of a lawsuit from the state of New Jersey to recoup $USD 7 million.
Now, I’m all for stopping people driving when their judgment and ability is hampered, but using such buggy software means there cannot be any confidence in the results returned by this device. It is possible people have escaped penalty when they were legitimately over the limit, and similarly, it is possible other drivers have been penalised despite being less intoxicated than the machine indicated.
Regardless of the application of this specific unit, it hits hard that as we become more and more dependent on computer software for evidence and legal purposes and determining the will of the people, there must be a way to examine that software for accuracy and reliability.
It is an imperative that closed source applications used by Governments be made available for scrutiny and code review if the public can be expected to have trust and confidence in their results.
This is why we need open source.