Primaries: the high-order bits

There's just a ridiculous amount of frustratingly baseless analysis of this primary going on all over the place. I am spurred to weigh in.

• A month ago, Democratic voters liked all three of their front-runners, and Republican voters were not too excited about any of theirs. The turnout numbers from Iowa and New Hampshire still indicate this.
• A month ago, Obama and Clinton were the Democratic front-runners, and Edwards was trailing. The combined results from Iowa and New Hampshire still indicate this.

Basically, as much as everyone's reading significance into primary results, I am inclined to say that the strongest signals point to no significant change from a month ago. We are exactly where we were; or at least, any signals indicating change are so weak that interpreting them is about as empirically sound as astrology.

The simplest explanation for the seemingly dramatic swing from Iowa to New Hampshire is just temporal and spatial noise: random week-to-week and population-to-population variation. Call me back when there's a more robust indication of a trend and maybe I'll get excited.

The chattering classes will chatter, as is their wont. But I find their diagnoses about as credible as the "financial analysts" who appear on business-oriented cable TV channels to state with a bogus air of authority that "tech stocks carried the markets higher today" or some such nonsense. It's random variation, that's all; or, at least, you have no evidence that it's not.

24 hours to certify Diebold source code?

Via IP today, I learn that the North Carolina State Board of Elections claims to have reviewed and certified the reliability and security of Diebold election machines' source code in less than 24 hours after it was placed in escrow.

All I can say is, North Carolina's State Board of Elections must have software quality assurance engineers the likes of which the world has never seen, engineers who can conjure comprehensive test suites out of thin air faster than mere mortals can even type them up, and who can construct proofs of program correctness in Hoare logic on-the-fly while reading source code, and who don't need symbolic model checkers because they can simulate thousands of Büchi automata in parallel in their heads while filing their fingernails.

Or, hey, here's a thought: maybe the board conducted some kind of sham certification process and rubber-stamped the software without really examining it. Nah...

My previous posts on election machines: Voting Machine Abuse Link-O-Rama; Close your eyes and hum pretty songs and maybe the code will fix itself; Further links on voting machine manufacturers' arrogance; Krugman on voting shenanigans [etc.]; Electronic election idiocy from Tom Zeller.

Bruce Schneier, David Dill on e-voting

It's the 15th again, and November Crypto-Gram contains several good short essays on voting technology. Worth reading.

After you've done that, go to UW-CSE's Information Technology & Public Policy course Fall 2004 lectures archive and check out the David Dill lecture on electronic voting from Oct. 14. If you're using Windows and have a fast connection, you'll probably want to install WebViewer so you can get synchronized slides and video.

Actually, if you're at all interested in IT and public policy, you'll probably want to watch all the course lectures. Ed Lazowska, one of our profs and our former dept. chair, has teamed up with UC Berkeley's Steve Maurer to plan a really terrific syllabus (course home page). By the time the course is over, there'll be about 30 hours' worth of lectures.

Michael Shamos voting testimony

Michael Shamos's July 2004 testimony before the House of Representatives regarding electronic voting machines. He is obviously a longtime electronic voting proponent. I link the testimony here in the interest of fairness, but I don't have time to rebut all his claims now, beyond saying that most of the arguments he attributes to DRE voting machine opponents are straw men (albeit subtly constructed straw men).

Most thoughtful DRE voting machine opponents acknowledge that electronic voting machines, in some form, can be superior to other forms of voting. We object to the bad design and lack of verifiability in the current generation of DRE voting machines, as well as the lack of transparency on the part of the voting machine manufacturers.

Unfortunately, Michael Shamos's testimony reads as a full-throated defense of electronic voting, with calls for verifiability and trustworthiness only coming at the very end. It therefore gives a misleading impression to lay readers.

p.s. Michael Shamos is a professor at CMU's School of Computer Science (though not, it is worth noting, in the Computer Science Department itself); but the list of computer scientists who have endorsed the contrary Resolution on Electronic Voting is rather more impressive. The older, hand-maintained version sorts by rough seniority and, well, if you recognize any of the names on that list, you'll see what I mean. Yes, OK, the appeal to authority is a fallacy, but Shamos seems to like putting "Ph.D., J.D." after his name, and his testimony is full of logical problems itself, so it's worth pointing out that we should not accord Shamos any special credibility because of his own credentials.

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.