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 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 intentionally 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 "How To Steal an Election," in the Washington Post.

What do you think? Will your vote count?

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at jack@ganssle.com. His website is www.ganssle.com.

---

I live in Canada where e-voting has only been attempted once (with technical disaster) but this issue strikes me as vastly understated by governments, news media, IT companies and the mainstream web. In such a politically volatile time- both domestically and globally- made complex by dense networks of economic relations democracy needs to be as clear and hard as a diamond. If e-voting is going to be a realistic fixture of our democracies in the future, there needs to be a universal firmware that can be adapted to work anywhere, at any level of government. And in order for it to be universal, it needs to be transparent.

E-voting will never be truly democratic until the code is public, and the code will never be optimal or secure enough without the force of millions of volunteer programmers. Democratic governments need to work together to support such an effort to prevent the basic functions of democracy being forced to suffer the inefficiencies of a VHS/BetaMAX battle, or the frustration of a buggy and exploitable OS. Moreover, this is the first time in the history of democracy that the task of vote-counting has been contracted out to a private firm, not to mention for software that remains their intellectual property, never to be openly scrutinized by any third party accountable to the public.

For both our countries sake, and the sake of future democracies, I hope we leave this ridiculous notion behind in favour of an open-source approach.

- eben holmes

---

I have been following the e-voting for many years. As a test engineer, I have found e-voting development comical. Private companies develop e-voting systems, without any publicly scrutinized standards, or requirements. Granted, these companies spent millions to develop these systems. But, any person wanting to validate or verify, or test this system, is out of luck.

One private company in Arkansas was blessed to evaluate/test e-voting systems. After some public uproar, NIST is now being slated to grant certification to companies, wanting to provide e-voting validation services. I found NIST certification to be laborious, and very expensive, and not entirely clear on if certification would be granted to individuals. How can anyone trust- what is kept secret?

Trust means that there is verifiable objective evidence that a vote was cast. Bits are not verifiable objective evidence. Bits do not provide me with any certainty that my vote got counted. Having physical evidence is a must, and should be an e-voting system requirement. Today, there are many options to provide cheap, objective, secure, and private methods that one individual cast a vote. The hard part is technology consensus, funding, and rollout.

- Ed Marsh