Re: Pull the Plug on E-Voting

From: Ron Crane <voting_at_lastland_dot_net>
Date: Thu Oct 26 2006 - 15:10:33 CDT
Richard C. Johnson wrote:
Mischaracterization is rife in some of Mr. O'Dell's articles, you say.  I think it is a bit rife in this article as well.  Mr. O'Dell's biggest problem is his faulty representation of what other people think and say.  He overuses the straw man tactic, constructing a virtual haypile of such imaginative beings.  The Open Source straw man gets lumped willy nilly with the e-voting straw man and neither is accurately portrayed.
Mr. O'Dell's key assertion is:  "there's simply no way to ensure that any program alleged to be written by Programmer Bob on June 24th bears any relationship whatsoever to what actually runs on computer "X" thousands of miles away on November 7th."
Mr. O'Dell simply does not know what he is writing about.  I personally have written programs, similar to those Mr. O'Dell describes, locked down a version of the source code, compiled it on one computer, shared it with some one else as source code, had the other person compile it on another computer, and proved the two compiled programs to be identical.  Time and distance don't alter this procedure.
You omitted Mr. O'Dell's modifier: "in the real world, there's simply no way...." I think he's writing from the viewpoint of how elections actually are conducted, instead of from a computer science-theoretical viewpoint. Elections generally are conducted with loose security procedures by people who understand very little about computer security. While properly-calculated hash codes and recompilation can be used to determine, to a high degree of certainty, that a given set of source was used to generate a given executable, this isn't a procedure that most people -- including most involved in election procedures -- understand. Also, of course, guaranteeing the identity of source and executable doesn't protect against "Trusting Trust" attacks, malware loaders, and the like.
Do most computer scientists and software engineers do this sort of thing, exercise care in configuration management?  Yes.  Do all?  No, assuredly not.  There are bad practitioners in every trade.  Read Ari Rubin's book, Brave New Ballot, if you are interested in how one finds bad stuff in source code.
Mr. O'Dell's neoLuddite screed ...
To distrust computational intermediaries in the voting process is not to be neo-Luddite. It is to be appropriately skeptical.
also ignors the audit provisions built into, for example, the Open Source voting systems at Open Voting Solutions (see  I too have a background in financial software and I know what an audit is.  I can assure you that cross-checking between dual paper and electronic ballots is absolutely and provably more secure than paper ballots alone.
Please prove this in light of the fact that ballot printers inject a (potentially malicious) computational intermediary between voters and their ballots, while hand-filled paper systems do not. "Voter verification" is no substitute for hand-filled ballots, especially in light of Ted Selker's study (see the Brennan Center's report, p.66) showing that voters in a simulated election identified fewer than 3% of simulated errors on VVPATs. It's true that an audit between electronic and paper records improves security when you know that both original records represent the voter's intent. But VVPAT and VVPB systems don't guarantee that premise, even when they're built on "open source" software. [1]
Paper rules, but paper alone is not enough.
True. You need audits, as in random and directed hand recounts of hand-filled, machine-counted paper ballots. And in the form of parallel testing, open source, and otherwise.


[1] That said, open source is an improvement on secret source. It's just not enough.
-- Dick

Kathy Dopp <> wrote:
Despite Bruce O'Dell and I having had a parting of the ways a long time ago (because he still posts articles mischaracterizing what Ron Baiman and I say in our papers and then attacks the statements he incorrectly puts in our mouths (to make Ron and I sound like idiots and himself sound smart I presume - but we tend to agree, if fact were told, on the things O'Dell mischaracterizes us in), and O'Dell sides with Liddle and Lindeman who still devote themselves to endless seductive but incorrect attacks (sophistry) against anyone using exit polls to guage election outcome integrity (See for a short list - of Liddle/Lindeman's incorrect use of mathematics),... Anyway, despite all that, this op-ed article (below) that O'Dell wrote on e-voting is one of the best, if not the best, articles I have ever seen explaining the fundamental difficulties of securing e-voting, in a way that laymen could grasp.  Although some computer scientists won't like O'Dell's article, IMO it is flawless and hits the core truth about e-voting.  There are ways to independently verify open source programming code by comparing the executables byte for byte using a duplicate system with exactly the same hardware and drivers. However, it is too complex, time-consuming, and expensive to apply effectively in the elections industry.  (Although open source is still preferable because it is more secure and efficient.)  I highly recommend this article by O'Dell, and hope its Part 2 will be as good:

October 25, 2006 at 14:55:46
by Bruce O'Dell

Pull the plug on e-Voting

Part 1 of 2

The FBI is investigating the "possible theft" of the Diebold touch screen voting software in Maryland. Excuse me... but I fail to see what all the fuss is about. I certainly don't condone theft; it's just that I don't understand why anyone would bother with stealing the Diebold source code - or why anyone would take the time to read it.

Don't get me wrong: I've spent twenty five years in the financial services industry helping to protect billions of dollars of other people's money. I designed internet security services as an employee of American Express to protect the online financial identities of hundreds of thousands of people, and recently spent a year at one of the twenty largest companies in America as chief architect of a project to replace the foundation of all their internal and external security systems. I understand risks from thieves and embezzlers - I've designed financial audit and control systems. In the world I work in, there's no room for excuses.

Source code is irrelevant

I'll let you in on a dirty little secret of the computing profession: in the real world, there's simply no way to ensure that any program alleged to be written by Programmer Bob on June 24th bears any relationship whatsoever to what actually runs on computer "X" thousands of miles away on November 7th. Even if Programmer Bob's corporate public relations and sales reps swear up and down that it must be so.

When it comes to security, source code is irrelevant. The actual behavior of a computer at point of use is the only thing that matters. Yet many of my IT colleagues continue to believe that it is somehow possible to look at a vendor's source code and determine what a particular voting computer will actually do in a precinct or county election office during an election. This seems to be the rationale behind "open source voting": if I can see the program is benevolent, then must be safe to use. Sounds plausible. But in reality any computer academic or professional practitioner who tells you that anyone on earth can determine whether a vote tabulation system is secure and accurate simply by looking at a source code document... is either ill-informed or lying.

Consider Microsoft's Windows XP operating system. As a critically-important widely-used program nevertheless riddled with bugs and security holes, this is a particularly apt comparison to voting software. Even if I could obtain a copy of the current Windows XP source code and read its millions of lines of text in its entirety with perfect comprehension, the act of reading the program text tells me precisely nothing at all about the integrity and security of any of the hundreds of millions of computers running Windows XP all around the world.

Think about it. Some surveys indicate 70% or more of Windows PCs are infested with viruses, spyware or, worst of all, rootkits. Rootkits hijack precisely those portions of the operating system that are used to detect the presence of malicious software and in so doing so become effectively undetectable. Can looking at the source code version of Windows XP tell me whether your particular PC is echoing all your keystrokes to a server owner by the Russian mob while you're innocently doing your online banking?

Software is inherently untrustworthy...

How do so many of my colleagues get such a fundamental issue so wrong? Although computer technology can seem endlessly complex, the fundamental issues are simple enough.

Computer program "source code" is just a text document. It's written using a word processor in a highly specialized dialect that is a shorthand mishmash of English words and math symbols. In order to get a computer to do my bidding, I first edit and save a text file, then run other programs (called "compilers" or "interpreters") to convert my human-readable text into the binary electrical impulses that a computer can understand and execute.

Here's where it becomes one twisty hall of mirrors. All means of verifying the version and features of any program as it is running in a computer require use of other software, the version and features of which in turn are verified by use of other software, the version and features of which in turn is verified by other software... and so on. Software alone can't vouch for software. It is a very well-known maxim in my profession that the only way to truly know what is running in a computer at any given time is to present all the inputs, record all the outputs, and verify that the two match up as expected.

All computer systems which process high-value transactions include audit mechanisms that monitor the advertised features of the system to enable an independent means of detecting flawed or fraudulent program logic... uh, everywhere that is except for voting systems, which arguably process the most important transactions of all. Go figure.

I'm so tired of hearing e-voting compared to using an Automated Teller Machine. Voting could not be more different than using an ATM. ATMs ask for not one but two forms of identification - a bank card and a PIN. Whereas the act of voting is private and anonymous. "Private, anonymous banking" is just another way to say "robbery in progress" - as in sawing open the ATM and taking its cash. ATMs exchange transaction and audit records with multiple counterparties and offer the user a receipt. Some but not all e-Voting systems may create or scan a paper vote record, but the voter surely can't keep it, or votes could be coerced or sold. e-Voting machines and ATMs are truly "apples and bicycles".

When it comes to electronic voting, we can't use any of the techniques we apply to securing electronic financial transactions all of which are predicated on the strong proofs of identity and exchange of transaction data with multiple counterparties that are rightfully banned in voting systems. Voting systems are national security systems demanding a much higher standard of protection than mere financial systems.

...yet the behavior of voting software is allowed to go unaudited

Many voting systems provide only an internal electronic audit trail of electronic vote tallies. What foolishness to allow programs to vouch for programs in such a way; as if it is somehow impossible to make two programs lie consistently!

Rep. Rush Holt's HR 550 legislation and its supporters in the academic computer science community are trying to salvage computerized voting by requiring that e-Voting touch-screen equipment always produce a "voter-verified paper audit trail" (VVPAT). This is a kind of receipt which in theory could be audited sometime after an election if the official results were contested. Setting aside the chain of custody problem - as soon as paper leaves the room, it is potentially compromised - when it comes to observing voters actually verifying their paper audit trail, the results are startling.

A 2005 study by the Caltech-MIT Voting Project concluded the following: " no errors were reported in our post-survey data ... ... and over 60 percent of participants indicated that they were not sure if the paper trail contained errors." That's right: in test elections full of deliberately engineered VVPAT errors - including swapped votes and even missing races - no one reported a VVPAT error while voting, a majority were unsure wtether there were any errors or not, and almost a third of the participants continued to insist that there no errors at all even after they were told otherwise by those who switched the votes!

But even that subset of touch screen voting systems with some kind of voter-verified paper trail, and optical scan systems that could in theory be audited ... in practice, are not. Certainly not by the standards of the financial services industry.

HR 550 was regarded as something of a revolutionary breakthrough in voting accountability simply by requiring a random audit of 2% of precincts after the fact. Under the Sarbanes-Oxley financial accountability law passed in the wake of the Enron scandal in 2002, the board of directors of any public company foolish enough to apply the same standard of auditability to their own books now have personal criminal liability for their decisions and so would face prison time for approving such a threadbare scheme.

But apparently when it comes to elections, no standard of protection is too lax.

Voting by computer considered harmful

There was a remarkable article published by the Computer Professionals for Social Responsibility in 2001, citing work by the Caltech-MIT Voting Project ( ) :

"...our best efforts applying computer technology have decreased the accuracy of elections, to the point where the true outcomes of many races are unknowable. Many technologists and technology enthusiasts will read the above words and refuse to believe them. 'There must be some other explanation,' they will say. 'Nothing has been proven,' they will say. 'Future technology will be better,' they will say. But there is no other plausible explanation: new technology may have reduced the cost of elections, and certainly has increased counting speed, but the above results show no statistically significant progress in elections accuracy over people counting paper ballots, one at a time, by hand."

Let me recap: voting by computer may be inherently untrustworthy and in practice poorly crafted, overpriced, prone to breakdowns and wide open to subversion - but at least it's less accurate than counting by hand.

Here's an indictment of the IT profession, and a fine irony: the degree of independent hand-auditing of paper ballot records sufficient to verify the corresponding computerized vote tallies is comparable to the effort required to more accurately count all the ballots by hand in the first place, dispensing with the machines. But until that day arrives, the programs that the voting vendors actually distribute - as opposed to the software they may say they distribute - will continue to determine who takes power after the votes are tallied.

(Continued in Part 2)
Bruce O'Dell is a self-employed information technology consultant with more than twenty five years experience who applies his broad technical expertise to his work as an election integrity activist. He lives just outside Minneapolis, Minnesota, and shares a love of good books with his wife - and her beautiful garden, with their talkative cat.

Kathy Dopp
National Election Data Archive
Dedicated to Accurately Counting Elections
Subscribe to announcements by emailing
Please donate or volunteer.

"Enlighten the people generally, and tyranny and oppressions of body and mind will vanish like evil spirits at the dawn of day," wrote Thomas Jefferson in 1816 _______________________________________________
OVC-discuss mailing list

_______________________________________________ OVC-discuss mailing list

OVC-discuss mailing list

= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Tue Oct 31 23:17:08 2006

This archive was generated by hypermail 2.1.8 : Tue Oct 31 2006 - 23:17:10 CST