By Jack Ganssle

Voting Software

Published 5/18/2006

It's an election year here in the United States, and the partisan bickering in Congress is now approaching unparalleled levels of hysteria. Somehow we citizens will have to bear with the accusations and silliness through November.

Then, of course, we exercise our Constitutional right to impose practical term limits (i.e., vote `em out) or to preserve the status quo. In many districts those precious signals of democracy will be recorded and hastened to a (hopefully hardened) database by a variety of electronic voting machines. There's one thing we know will happen: the bickering will only increase as losers contend their constituents' desires were distorted by poor firmware in the machines, or by the lousy procedures used by election workers.

It's not just the machines themselves. Any part of the process controlled by software may be suspect. The ACM recently released a report (http://www.acm.org/usacm/PDF/VRD_report.pdf) about the software used to register voters. Here's a quote:

"In light of recent events and legislation that have underscored the core importance of voting and of public confidence in our electoral system, one might conclude that all VRDs should be built and operated to the highest possible standards. While the highest standards of reliability, privacy, accountability, usability, and security are desirable, they may at times be impractical because of resulting expense or system response."

What - we're expected to <i>intentionally</i> build substandard code?

The assertion that correct code is slow ("system response") is a red herring designed to lull non-techies into accepting buggy code.

Two decades ago the MGM Grand Hotel in Las Vegas burned with great loss of life, in part since there was no sprinkler system. The owners refused to shell out $200,000 for sprinklers, as the city fire codes of the time didn't require them. The fire and resulting lawsuits eventually cost them $200 million. Substandard construction, of hotels and of software, leads to expensive chaos.

The (long) ACM report goes on to focus on using tests to prove the systems are correct. Yet we know testing does not work. Most tests exercise only half the code. While tests are indeed critically important, it's prudent to focus on the internals. How is the code built? Is it inspected. or a spaghetti mess?

Using test alone is like accepting an airplane engine because it runs. The FAA requires all aircraft engines to be totally disassembled every so often to look for latent internal problems.

There's an enormous amount of press now about defects in the voting machines. Reports cite vulnerabilities that leave gaping security holes easily exploited. Others worry about as-yet-unidentified defects that could throw an election. perhaps without anyone ever knowing it. Vendors claim sainthood for their units while keeping the code under wraps.

I know this much is true: voting machine vendors are in the business of selling trust. If we don't trust these machines the electoral process fails. Yet the message the public hears is one of "software is inherently buggy and insecure; deal with it."

I think e-voting is the right idea. It'll make the process faster and more accurate, while opening more opportunities for absentee votes, an important feature in these mobile times.

But a machine built on top of a very complex OS, one that has not been certified correct is a Bad Idea. A machine designed for easy in-the-field patches is a Bad Idea. A machine built of proprietary software is inherently not democratic.

We know how to make fabulously-reliable code. Ironically, some voting machine vendors already do so in their other product lines, like automated tellers. Banks are completely intolerant of any process, teller or software that throws the balance off by even a penny. The gaming industry, too, builds machines of unprecedented reliability. For an interesting look at the difference between the gaming and voting industry, see http://www.washingtonpost.com/wp-dyn/content/graphic/2006/03/16/GR2006031600213.html .

What do you think? Will your vote count?

Free Embedded Muse newsletter - twice/monthly, hard-hitting technical info that goes to 48,000+ engineers. Click here to sign up or enter your email here: