Electronic Voting Incompetence

The long-awaited debut of electronic voting came in our just-completed election. Despite the initial controversy, things seemed to go well; the few fraud rumors floating around seem to be motivated out of partisan fanaticism rather than evidence.

The actual evidence, or lack thereof, is dealt with in this column. It’s a good justification for the legitimacy of the election, but it also sounds an important caution about electronic voting. For example:

Broward’s central vote-counter was not programmed to expect more than 32,000 votes in any single precinct.

With the limit exceeded, the running totals in four races (all constitutional amendments) did, indeed, start declining.

Observers quickly noticed it. It got fixed. The accuracy of the individual voting machines was never in question. Nobody’s vote was a “negative” that subtracted from the vote totals.

An experienced programmer will immediately notice the vote count at which things started going in reverse. The 32,000 figure is almost certainly a rounded or estimated figure; the real number is certainly 32,767 votes. Why? That’s the highest number a 16-bit signed integer (signed: able to store negative as well as positive numbers) can hold.

One of the most common bugs in programming is the mistake of treating a signed integer as unsigned. Most of the time, this works, since signed positive integers are stored in memory the same way as unsigned integers–up to a point. But if you’re making this mistake, and (with 16-bit integers) you add 1 to 32,767, you get -32,768 instead of 32,768. This may seem odd, but it’s an artifact of how negative numbers are stored in signed integers. After that, adding 1 does what you’d expect: makes the result less negative (-32,767, -32,766, and so on). By stripping off the negative sign before displaying it (which isn’t terribly uncommon either), you get counts that appear to be going down.

So what does all this tell us? It tells us that the vote-counting system was not tested nearly well enough, either by the manufacturer or the county. The manufacturer should have been technically competent enough to test for this very common bug, and the county should have made sure the counting system could handle the expected turnout long before Election Day.

Bruce Schneier, one of the leading experts on information security, discusses some of the continuing problems with electronic voting here. It’s important to note that Schneier’s essay assumes basically competent manufacturers and customers (election authorities). If it’s difficult to get proper counts when everyone is competent, imagine the state of affairs when everyone shirks basic quality assurance responsibilities.

It’s easy to see this as a partisan issue, especially after the CEO of one e-voting vendor confessed his involvement in Republican politics. The problems with getting accurate and undoubtable results from elections, though, is only a Democratic issue by accident this election. Republicans should be able to assert the basic soundness of this election while acknowledging how easily things could have been otherwise.

Besides Schneier’s recommendations, I would add that we should require that test results be made public. Had such results been made public in the case above, an outside observer could have noticed the above shortcoming of the tests and drawn attention to them, thus possibly averting the issue entirely.