Centerfield

E-Vote Reform Proposals So Far Too Weak

I wanted to say something about e-voting, because I think that most proposals and media articles on how e-voting should be reformed are too wimpy. Why is this important? Well, is Kerry winning because he's a strong candidate or because some hacker or a software bug chose him? The former seems more likely, but the e-vote parts of his lead aren't something that can possibly be checked the way things are done now. It was possible to tell that Enron went bad, even if it took a long time. After 2000 in Florida, every vote cast could be rechecked by first manual recounters, then a second time by a newspaper coalition. You can't do that with e-voting right now; admittedly, you couldn't pin down results beyond the 5% punch card error bar, but you can't even verify e-votes to 100% error.

There is no way of having faith in an elections system without this minimal level of checking, because for all you know, a random hacker in search of a challenge could have chosen the results. The motive could be anything from pranking to straightforward political motives to money for hacking to hatred of the United States to boredom and disaffection to demonstration of hacking skills. Or, more likely still, it could also be done by a bug in e-vote software.

(note, if you're with an e-vote vendor and reading this, page on to the last section first)

There are reform suggestions, and although they are a good start, I see them as missing a couple of important protections. Most often suggested by the media is giving individual voters a receipt saying how they voted. The second common suggestion is requiring voting software to be Open Source. Both of these suggestions fail to deal with some not-too- hard-to-think-of kinds of system perversions. Just giving individual voters copies of only helps somewhat; first, the computer could have lied about the votes it registered, and second, it still gives the state no way of manually checking the results if fraud is believed. Open Source alone only helps somewhat because an election company could deliver a binary different from what's online.

Even if we had those kinds of guidelines for suspecting questions for e-vote machines, it wouldn't help because no alternate record of votes is kept. If the computer lies, there is no backup. We need to have both backup records and checking of some kind.

It would also be very helpful if we took some measures to make fraud hard. Beyond that, still better would be to take measures to get rid of many of the bugs by requiring as much code as possible to be proven correct.

Absolutely Necessary: Minimal Auditing Checking Requirements

The minimal requirements are that there must be an auditing trail that governments can use to manually check results, and random checking in addition to individual ballot checks. Voter-Verified Ballot Systems comes close to this but misses the need for additional random checks. Added random checks are needed because otherwise the computer lying on printed ballots can easily defeat the only checks in the system.

Votes must be recorded on an alternate medium, preferably one checkable by the voter. Voters should be encouraged to verify their own ballots.

It must be possible to recount all votes manually.

Some precincts must be checked manually always, to see whether they results match in those precincts. If the mismatch is significant, all precincts should be manually recounted, and machine behavior carefully investigated. The precincts to be checked should be chosen randomly and manually, after the election.

Any precinct in which any odd behavior was reported should be checked.

Per-precinct vote counts and vote tallies must be done both by hand and electronically.

Much Better Still: Positive Bug- and Fraud-Reducing Mechanisms

Some have suggested that e-vote machine vendors should be required to release their source code as Open Source. That's definitely a good idea, as it'd allow bugs to be found by the population of programmers at large.

One more step would add alot of strength to this measure. We programmers have a deeply nifty thing in our toolbox called a 'hash'. Among other things, we can identify two given hunks of data as being the same or different with a high degree of probability.

We can use hash IDs to make sure that binaries in voting machines are exactly the same as you would get by compiling the publically available code.

In a similar vein, machine's should not accept software upgrades that aren't digitally signed as being from the vendor.

Each major political party should take responsibility for checking that these publically available codes operate as expected, and blowing the whistle otherwise. We can reasonably assume that other organizations would also happily share in this obligation.

There is an important legal detail here. "Open Source" has a specific definition which doesn't really suit the situation here. The actual thing that should be mandated is that election machine source code be completely available online (as in an actual Voter Confidence Act introduced in the House. Open Source also includes guarantees about letting anybody modify and distribute the source code. I see no reason why this should be required.

Best of All: Proven Correctness

It is possible to write provably correct code that stays to certain languages and limitations on functionality. Although it would certainly be impractical to get 100% proven code, doing as much as is practical this way would be better.

Of course, even if you did have 100% coverage, it wouldn't really mean it's completely reliable. All programs rely on correct hardware and input. It's just an important step.

Other Issues

Another possibility that should be discussed is standards and/or open hardware. If a region faces problems with a vendor that it's very slow to fix, right now the region has to buy an entire new system to get around problems. That's a pretty big disincentive to being tough about bugs in e-vote systems. Therefore, it's important to have standards to make it easier to replace systems piecewise.

There should also be standards with respect to e-vote-related software licenses.

Value For E-Vote Vendors

Note that we should expect to pay for this. Each of my suggestions amount to an increase in functionality, and that doesn't come free.

Another way this helps e-vote vendors is that it'd raise the value of their products. The more trustworthy their products are seen as, the more valuable their product will be, and the more sales they will make both domestically and globally. Therefore, all these proposals are very much in their interests as well.

To Upgrade, or to Downgrade?

In my opinion, it's better for a region to "downgrade" to whatever they used pre-e-vote than to live with the current level of uncertainty. I recommend using the old stuff until both manual verifiability and random checking are set up and read to run. We know the error level of punch ballots - it's < 5%. Could be anything with the e-vote systems. We just don't know. We do know that hackers and software bugs are real and inevitable; one has already broken into an e-vote vendor to make this very point. The accessibility advantages of these machines just aren't big enough to risk the core of our democracy like this.

UPDATE: Oh, the random checks are in the bill already. Whew! Oh, the embarrassment. My miserable exuse is that it was the very last paragraph.