The following text is copyright 2004 by Network World, permission is hearby given for reproduction, as long as attribution is given and this notice is included.

Lessons from the e-voting mess

By Scott Bradner

April 30th was not a good day for vendors of electronic voting systems, nor was May 3rd. There may be quite a few such bad days ahead for the companies that sell gussied up PCs intended to replace older voting systems such as the punched card systems we had so much fun with during the 2000 presidential election. On April 30th California Secretary of State Kevin Shelley decertified all electronic voting systems for use in California elections unless a long list of specific conditions were met. Three days later the government of Ireland decided to not use the electronic voting systems it had already paid about $60 million for because it could not be sure that they would work. There may be lessons that extend far outside of the electronic voting space in these developments.

These developments are just the latest in the long and contested history of electronic voting systems. May problems have been identified with these systems and just about as many problems have been identified with the vendors of the systems and the election officials that select them for use. (See "'Go away', he explained" (http://www.nwfusion.com/columnists/2003/0804bradner.html))

The most basic problems with the existing electronic voting systems is that they use, as their core, PCs running Windows operating systems and they treat their own software as propriety and secret. It is not impossible to create trusted systems using Windows as a base but it does take extraordinary care, something that the public reviews of the processes used by the vendors and by election officials. Processes of the type that led the California Secretary of State to refer one of the vendors to the California Attorney General for possible criminal or civil prosecution. It is also possible to create secure propriety software but to do so requires that the vendors employ and listen to security experts and, to be sure, get a group of external experts to review the code. An external review was done on the code of one of the electronic voting systems, not at the vendor's request or desire, and the code was found to be appallingly poorly programmed and to quote one reviewer "It's not as though they did security poorly. It's as though they didn't think about it at all." I'm not sure if I'm more troubled by the security clue-challenged company selling this software or by the fact that at least some of the software was certified by government agencies for use.

There are many systems that have reliability and security requirements similar to voting machines including ATM machines, building access control systems, and fire or environmental monitoring systems. The report that Secretary of State Kevin Shelley published can be used as a quite good list of the prerequisites to deploying any system of this type. (http://www.ss.ca.gov/elections/ks_dre_papers/decert1.pdf) The report stresses the importance of software review, system and process documentation, system isolation and training.

Quite a few observers have said that the basic lesson from the voting system debacle to date is that all software for this type of critical system should be open source. I do not think that is an unwarranted conclusion but maybe the lesson is deeper than that. Just maybe general-purpose operating systems are not the best solution to all problems. Maybe stripped down specialized code is better in some cases

disclaimer: "Stripped down" is not a concept often associated with Harvard even if "specialized" might be. In any case the university was not involved in writing the above column.