September 14, 2003

Vote ‘no’ on repeating history

By: Joanne McNeil

My mother used to take me to the ballots when I was young enough to enjoy the event. She would let me punch the card and pick the candidates in races she didn’t care about. These machines were antiquated and error-prone even then–in the eighties–as Roy Saltman of the National Bureau of Standards reported. But his warnings never gained attention until the “hanging chad” scandal of the 2000 presidential election.

Carnegie Mellon University computer scientists were asked by the state of Pennsylvania to inspect their machines in 1980. Though Votomatic, the company that distributes most punch ballots, insisted its product was flawless, the examiners thought it was “a joke.” According to Michael Shamos, who worked on the project, Votomatic machines were clearly “vulnerable to tampering in a multitude of ways.” Despite criticism dating back twenty years and Florida’s recent scandal, these punch ballots remain in place today. They will even be used in several California counties for the gubernatorial race, which, by the way, has 134 candidates to choose from.

There are warnings about a new ballot technology set to replace Votomatic, and again state governments fail to take heed. Johns Hopkins University computer scientists have exposed Diebold, the maker of most of the new “Direct Recording Electronic” machines, as grossly insecure. Avi Rubin, one of the nation’s leading security experts, published his Diebold report on the heels of Maryland’s $55.6 million deal with the manufacturer. But like Pennsylvania in 1980, it appears the state will ignore his warnings following a routine audit.

Before Rubin’s report, criticism of electronic voting was only hypothetical. DRE manufacturers had proprietary software source code kept secret from public scrutiny. This summer Diebold carelessly posted its sensitive material to an obscure but unprotected Web site. Finally Rubin’s team at the Information Security Institute had the “smoking gun.”

Two weeks later, Rubin published his paper concluding Diebold’s technology “places our very democracy at risk.” The code was written in C++, a computer language known to be insecure without strong coding. Alas, Diebold’s coding is weak. The cryptography and software used is considered “far below even the most minimal security standards applicable in other contexts.”

The George Washington University computer scientist Lance Hoffman was asked by an unnamed organization to critique Rubin’s research. He told the Baltimore Sun, “I said [to them] no self-respecting computer scientist can go against the Rubin report, and maybe Diebold should rethink how they develop software.” Only Bryn Mawr professor Rebecca Mercuri, herself a critic of DRE, offered a comprehensive critique of Rubin’s report. She says some of the scenarios the report imagines are plausible, but improbable. Mercuri concurs that the source code in the report is insecure, but the Johns Hopkins team could “not truly know whether there is additional hardware or software” to provide safeguards against the flaws they cited. While Mercuri is right to remind the researchers that they are not “mind-readers,” it is telling that Diebold denies the report entirely and has only suggested the source code cited in the report is the same code intended for election use.

Bev Harris, the first to expose Diebold’s leaked source code, is convinced the company is corrupt. She points to another file found unencrypted on the Web. It is dated at 3:31 p.m. at San Luis Obispo County’s March 2002 primary election. It contains the incomplete election data for all 57 precincts. It is illegal to count votes before the polls have closed.

Diebold has denied that there is ever any electronic communication between polling areas and the main office, but as Bev Harris said, if that were true “you [would have to] shut down the polling places in 57 places at once and get in a car and drive this card into the county office. That’s not going to happen.”

Even if Diebold is clean of this seemingly damning evidence, who can trust a company sloppy enough to leave potentially damaging files unencrypted over the Internet? In King County, Washington last month, Diebold accidentally switched the absentee ballots for the cities of Renton and Bothell. Such embarrassments should cost Diebold its state contracts, or at least compel the company to reveal its source code for peer review.

We should learn from the Votomatic example. Whatever voting machinery is put in place next will stay in place long after its technology has become obsolete. That is why electronic voting machine source code must be open to be trusted. In the age of Linux, open source software has established itself as a viable business model. It produces not only the cheapest, but the safest software. Open source software can be peer-reviewed by researchers and computer experts to confirm its reliability. Diebold should have welcomed Rubin’s report, just like you would thank a neighbor for pointing out that your front windows are open.

Electronic voting machines allow page magnifiers for the visually impaired. Blind and illiterate voters are finally permitted a secret ballot using headsets that can be operated in English and Spanish. But as Joseph Stalin once said, “those who cast votes decide nothing. Those who count votes decide everything.” In the wrong hands, DRE machines are not only undemocratic, but dangerous.

Rather than abandoning DRE entirely, we should support open source voting machinery and prohibit communication devices that might magically transport voter counts to the main office at say, 3:31 p.m, and require voting machines to produce a paper-record of votes for use in manual recounts.

Joanne McNeil is a writer living in Washington, D.C. Her Web site is