Lessons from the e-voting mess

April 30 was not a good day for vendors of electronic voting systems. Nor was May 3.

There might be quite a few such bad days ahead for 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 30, 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 not to use the electronic voting systems it had paid about $60 million for because it could not ensure they would work. There might be lessons that extend far outside of the electronic voting space in these developments. Many problems have been identified with these systems, and just about as many have been identified with the system vendors and the election officials that select them.

The most basic problems with the electronic voting systems are that they use, as their core, PCs running Windows and treat their own software as proprietary and secret. It is not impossible to create trusted systems using Windows as a base, but it takes extraordinary care, something that can be taken care of in public reviews of the processes that vendors and election officials use. Processes of the type that led the California secretary of state to refer one vendor to the California attorney general for possible criminal or civil prosecution.

It also is possible to create secure proprietary software, but to do so requires vendors employ and listen to security experts and get external experts to review the code. An external review of one of the electronic voting systems – not at the vendor’s request or desire – revealed the code was appallingly poorly programmed. 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 that the security clue-challenged company was selling this software, or that at least some of the software was certified for use by government agencies.

Many systems have reliability and security requirements similar to voting machines, including ATMs. The report that Shelley published can be used as a good list of prerequisites to deploy any system of this type. The report stresses the importance of software review, system and process documentation, system isolation and training.

Quite a few observers have said the basic lesson from the voting system debacle is that all software for this type of critical system should be open source. I don’t think that is an unwarranted conclusion, but maybe the lesson is deeper. 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.