August 12th, 2004 to the Utah Voting Equipment Selection Committee
Thank you for the opportunity to comment today.
I have been a software engineer for 17 years, creating and supporting software for a variety of different industries. It is with this experience in mind, that I would like to raise a few caution flags regarding the acquisition of computerized voting equipment.
Computerized voting has the potential to eliminate the failings of the punch card system experienced in recent elections. It also has the potential to provide or facilitate access for voters with physical challenges. However, the issues in the 2000 elections, and the scramble to address the goals of the Help America Vote Act have revealed serious issues in voting technology.
There have been stories recently in the media about internal email between software developers regarding software flaws, and the partisan comments of manufacturers of electronic voting equipment, Diebold in particular. While these allegations are troubling, there are other, much simpler reasons for concern: the day-to-day realities of software creation and distribution particularly Vendor Code Review, Vendor Testing, Application of Business Rules
While it is the goal of every software organization to conduct code review, the reality is that it is rarely performed. This opens the door for several problems: unscrupulous programmers may insert code that performs hidden tasks, such as the famous incident of a programmer who collected fractions of a cent in a payroll program, and transferred them into a private bank account. Temporary code that performs specific actions to test specific scenarios may be inadvertently left in. For example, in testing maximum values for a counter, code may be written to multiply the result of a keystroke by a value to reduce testing time.
It is an economic reality of software production that code must be delivered to customers on time, whether it has been rigorously tested or not. It is in fact a recognized trend among commercial producers, that it is more cost effective to "just ship it" when deadlines loom, and allow users to test the critical scenarios live and report problems.
A software provider may have undocumented business rules, such as configuration values that are set by an installer, but never discussed in the course of user training. An example might be setting maximum values for vote counts to the number of registered voters in the precinct. Exceeding this value for any candidate might indicate vote fraud. However, some database systems automatically cycle these counters back to 0, potentially throwing out legitimate votes. If a configuration value was set incorrectly, it could potentially mask fraud, or allow it. There may be other business rules that are deemed important to the software manufacturer, perhaps because they are important in the state where the software is produced, but they may be irrelevant or contrary to the state where the software is used
The issues in the 2000 elections raised serious confidence issues in the electorate. These must be addressed with the maximum level of transparency. Two ways to address this need are insisting that any vote-counting software be open-source, and subjecting it to independent code review and testing by non-partisan county election officials.
Copyright 2004 Eileen McCabe-Olsen