Monday, February 02, 2004

Close your eyes and hum pretty songs and maybe the code will fix itself

San Jose Mercury news reports on the following, which does wonderful things for my confidence in electronic voting machines:

Poll workers in Alameda County noticed something strange on election night in October. As a computer counted absentee ballots in the recall race, workers were stunned to see a big surge in support for a fringe candidate named John Burton.

Concerned that their new $12.7 million Diebold electronic voting system had developed a glitch, election officials turned to a company representative who happened to be on hand.

Lucky he was there. For an unknown reason, the computerized tally program had begun to award votes for Lt. Gov. Cruz Bustamante to Burton, a socialist from Southern California.

I can totally imagine how this would happen. I bet they keep the list of candidates in a sorted list by last name. Somehow an index got incremented or decremented incorrectly, and they indexed into a location one prior to the one that was supposed to be referenced.

(This raises the question of how that index got incorrectly set on this machine, but not on most of the others. If it's a software error, then it has to be a bug on a rarely executed program path. It could also be RAM error. Are they using error-checking (ECC) RAM? Somehow I doubt it --- it's a baseline requirement for reliable hardware, but it's more expensive, and everything I've heard of these voting machine manufacturers leads me to believe they're a bunch of incompetent crooks.)

The thing is, this is a perfect example of how a tiny little mistake (incrementing a number wrong) can lead to a huge difference in election outcome. At least when a person misinterprets a hanging chad, it only messes up one vote at a time. A mistake like this can instantly misrecord a thousand votes or ten thousand.

As I've written before, every respectable computer scientist (and some non-respectable ones) believes that electronic voting is fraught with opportunities for abuse and error. It's outrageous for these companies to refuse to open their source code and assembly diagrams to public inspection based on trade secret law. They're the ones begging for our tax dollars, and asking us to trust them with the foundation of our democratic institutions. The burden of proof is on them to prove to us that they are worthy of this trust.

My proposal:

  • All voting machines' hardware components must be commodity off-the-shelf parts.
  • All voting machines' hardware designs should be open to public inspection (i.e., posted on a public web site).
  • All voting machines' software should be open source and available for public review (i.e., posted on a public web site for download).
  • All voting machines' software must be written in a type-safe language (where possible), and must be written using the best formal methods and automated software verification tools currently available. For example, software should be written in Cyclone rather than C wherever possible. If it absolutely must be written in C, it must pass the Splint checker at its most rigorous setting.
  • All voting machine company employees must have strict background checks.
  • All voting machines must be assembled, and their software installed, in a plant subject to public audit at any time.

If you can't live with these restrictions, you should get the fuck out of the voting machine business. And if your government can't bear to impose these restrictions of your voting machine company, your government should get the fuck out of the voting machine market.

UPDATE: Reading further down the article, I get even more disturbed:

``At no time were incorrect vote totals released,'' Diebold spokesman David Bear wrote in an e-mail. ``The system is safe, secure and accurate.'' He attributed the malfunction to a computer-server error and the large number of candidates on the recall ballot.

Server error? Large number of candidates on the recall ballot? Holy shit, were they using something ridiculous like a 6-bit integer to represent the candidate ID somewhere in their client/server protocol? That's even more frightening than my previous hypotheses.

BTW, don't buy this spokesperson's crap about the system being safe, secure, and accurate. Software is not like a car engine; it doesn't stall occasionally due to normal wear and tear, or anything of the sort. There are no truly random errors in software. Software is like a math formula: if there's a bug, there's a bug. Period. That bug definitely exists, and will stay there until someone fixes it.