The Ohio Secretary of State has announced the results of a study his office commissioned, which examined four e-voting systems. If you have been following this issue, you won’t be surprised to hear that the study found many flaws in the systems. Each system had at least one “high risk” problem.

In addition, a study of the vendors’ quality assurance methods led to a decision to “ask vendors to implement industry standard security and quality practices and procedures.”

Diebold has filed a court document promising not to sue people for posting the now-famous memos, and withdrawing the DMCA takedown notices it had sent previously. It’s a standard-issue lawyer’s non-surrender surrender (“Mr. Bonaparte, having demonstrated his mastery of the Waterloo battlefield, chooses to withdraw at this time”), asserting that “[u]nder well-established copyright law” Diebold could win an infringement suit, but that Diebold has decided anyway not to sue, given that it no longer has any realistic hope of suppressing distribution of the memos.

Diebold’s filing also contains this interesting sentence:

Diebold has informally encouraged the students to refrain from publishing passwords, source codes, information protected by employees’ privacy interests, and trade secret-type information, none of which is essential for purposes of criticism.

Some of these things certainly are essential for criticism. Diebold’s source code, for instance, is the most precise description of how their technology works, so it has obvious relevance to criticism of the technology’s security or reliability. Trade secret information includes facts about the failure history of the product, which are also highly relevant.

I’m not saying that it is always legal or ethical to publish companies’ source code or trade secrets, no matter what the circumstances. But in this case, some code and some trade secrets are essential for criticism, and Diebold’s assertion to the contrary doesn’t pass the laugh test.

[Link via Larry Lessig.]

Donna Wentworth at Copyfight points to the fine print in the recent e-voting edict from California Secretary of State Kevin Shelley, which says this:

Any electronic verification method must have open source code in order to be certified for use in a voting system in California.

Many computer scientists have argued that e-voting systems should be required to have open source code, because of the special circumstances surrounding voting. Is that what Mr. Shelley is requiring?

I’m not sure. His requirement applies to “electronic verification method[s]” and not explicitly to all e-voting systems. What exactly is an “electronic verification method”? Mr. Shelley’s directive uses this term in reference to the report of a previous task force on e-voting.

So what does the task force’s report say? Surprisingly, the report refers to “electronic verification” methods at several points, but I couldn’t find any specific mention of what those methods might be. This is particularly odd considering that the task force members included computer scientists (including David Dill and David Jefferson) who are more than qualified to understand and write about any “electronic verification” methods, even if only to summarize them or give examples.

It looks as if there might be a hidden layer to this story, but I can’t figure out what it could be. Can anybody help out?

[Correction (1:50 PM): corrected the spelling of Kevin Shelley’s last name.]

California Secretary of State Kevin Shelley will announce today that as of 2006, all e-voting machines in the state must provide a voter-verifiable paper trail, according to an L.A. Times story by Allison Hoffman and Tim Reiterman.

This is yet another sign that the push for sensible e-voting safeguards is gaining momentum.

[Link credit: Siva Vaidhyanathan at Sivacracy.net.]

Opponents of unauditable e-voting technology often talk about the threat of fraud. They worry that somebody will compromise a voting machine or will corrupt the machines’ software, to steal an election. We should worry about fraud. But just as important, and more likely, is the possibility that software bugs will cause a miscount that gives an election to the wrong candidate.

This may be what happened two weeks ago in a school board race in Fairfax County, Virginia. David Cho at the Washington Post reports :

School Board member Rita S. Thompson (R), who lost a close race to retain her at-large seat, said yesterday that the new computers might have taken votes from her. Voters in three precincts reported that when they attempted to vote for her, the machines initially displayed an “x” next to her name but then, after a few seconds, the “x” disappeared.

In response to Thompson’s complaints, county officials tested one of the machines in question yesterday and discovered that it seemed to subtract a vote for Thompson in about “one out of a hundred tries,” said Margaret K. Luca, secretary of the county Board of Elections.

“It’s hard not to think that I have been robbed,” said Thompson, whose 77,796 recorded votes left her 1,662 shy of reelection. She is considering her next step, and said she was wary of challenging the election results: “I’m not sure the county as a whole is up for that. I’m not sure I’m up for that.”

And how do we know the cause was a bug, rather than fraud? Because the error was visible to voters. If this had been fraud, the “X” on the screen would never have disappeared – but the vote would have been given, silently, to the wrong candidate.

You could hardly construct a better textbook illustration of the importance of having a voter-verifiable paper trail. The paper trail would have helped voters notice the disappearance of their votes, and it would have provided a reliable record to consult in a later recount. As it is, we’ll never know who really won the election.