"Computer Scientists who question the security of electronic voting machines are undermining our democracy." -- Linda H. Lamone, Administrator of Elections, State of Maryland, November 3, 2003

Oh, neat! This is the best evil conspiracy of computer experts I've joined since Dan Rather denounced the "professional rumor mill" that pointed out the phoniness of his Bush memo.
 

Brave New Ballot is a very important book. It makes vital points about the frighteningly bad state of electronic voting machines in America, and for that it deserves to be widely read. But in reading it, I often found myself wishing that Rubin would have focused less on his personal odyssey and more on the technical issues.

Professor Aviel Rubin leaped to national notice in 2003, when he and some students at Johns Hopkins got hold of source code for Diebold's Accuvote machines, which had been inadvertently published on the Web, analyzed it, and found major flaws. Cryptography was misused; long-broken DES encryption was used, and a critical key was hard-coded and therefore the same on every machine. The smartcards which were given to voters to place in the machines weren't verified cryptographically. Many other problems were found.

Since then, a Princeton study has shown that Diebold's systems still have serious problems, and Diebold's response has shown that it can't even understand the security issues, much less fix them. This study was too recent to be mentioned in Rubin's book.

A point which the book stresses is that while electronic voting machines are less vulnerable to single acts of fraud than paper or mechanical systems, it's possible for a single act of fraud to have a much greater effect. Rubin calls this distinction "wholesale fraud" vs. "retail fraud." An undetected compromise in a computerized voting system could in principle change any number of votes in multiple districts.

He offers a number of changes that would make computerized voting more trustworthy. The most important of these is a paper trail; a machine should make a record of each person's vote as it is cast. (Printing out a summary at the close of the polls doesn't count.) The source code of the machines should be open to public examination. The systems should be independently audited, by examiners not hired by the machine's makers.

There are quite a number of Democrats who state, as an obvious fact, that Bush stole both the 2000 and the 2004 elections. This isn't Rubin's position. He writes: "The many activists who definitively claimed, with no evidence, that the [2004] election had been stolen did a great disservice to everyone who had thoughtfully and seriously criticized the e-voting technology." Throughout the book, Rubin avoids partisan involvement, though he notes that in Congress, Republicans have overwhelmingly supported the view that the existing machines are sufficiently secure, and they defeated legislation to require a paper trail.

I just wish that Rubin had focused more on the problems of the machines and less on the personal problems which resulted from his disclosure of them. I can easily sympathize with him; I like to identify problems but hate publicity. If I found myself involved in a tenth of the public controversy which he's had to deal with, I'd have changed my name, dyed my skin, and moved to North Dakota. But the book is presented as a critique of voting technology, not an account of his personal battles. Too much of the book is spent on explaining those battles. The accounts are colorful and shed some light on the issues, but they're still digressions.

There are also, inevitably, technical points on which I disagree with Rubin. Mentioning just one (Warning: Technospeak ahead): He objects to signing binary executables on the grounds that binaries compiled for different environments will be different, as will compilations after code fixes. He's correct when he states that signing won't protect against inside tampering. But that's not excuse enough. Software for something as critical as voting applications should be released and verified at the binary level. If it's changed and recompiled, a new signature can be issued to go with a new release. If it's recompiled with updated supporting libraries, the code needs to be re-verified, and once verified it should be issued with a signature. Open source software commonly follows this practice; secure commercial applications can do so too. Rubin makes this sound like an intolerable burden, but it isn't. Perhaps, being an academic, he's unfamiliar with formal release procedures.

Personally, I would have liked a significantly more technical book, where issues such as this one were discussed at more length, but I realize he had to strike a balance between explaining things properly and reaching a wide audience. If only software engineers understand what's wrong with the existing inadequate designs, it's unlikely they'll ever get tossed in the dump where they belong. As he puts it, the issues need to be put in terms that "the average eighth-grader" will understand. I hope that Brave New Ballot helps to do that.

 
There is a website associated with the book, with links to various reports, including material at a higher technical level.