Slashdot Mirror
Electronic Voting's Fundamental Flaws
phil reed writes "Given the latest fiasco in Florida's continuing attempts to implement a decent voting system, I thought it would be appropriate to alert Slashdot readers to the work of Dr. Rebecca Mercuri. She's been studying voting systems for many years, and has developed well-considered positions on what makes a good electronic voting system (and what makes a bad one). Her comments on the Florida 2002 election can be found in the current Risks Digest. And, if you think that creating a computer-based voting system is easy, she provides a suggested list of questions that should be answered by any developer." Mercuri's statement in Risks is well worth reading. With all due respect, she is wrong in some respects: it is possible to create a fully-verified electronic system. Start with completely open code and thoroughly examined hardware, create an audited system for installing the code on the hardware, and make it tamper-evident so that you know the same code is still there when the machine reaches the voting booths. Bootable, hologrammed, serial-numbered CD-ROMs with individual private keys would do the trick. Mercuri is thinking in terms of vendors selling proprietary "solutions", where she's absolutely right: there's no way to verify that what people punch in is what is actually recorded.
Unfortunately, as long as their are humans involved, corruption will always be there. From the guys paid to write the software, to the DB admins, to our friends at M$ who will undoubtably provide a security-lacking OS to run the system on, voting will always be called into question when it gets as close as it did between Gore and Bush.
I've dirtied my hands writing poetry, for the sake of seduction; that is, for the sake of a useful cause. --Dostoevsky
Michael I think you don't quite know what you're talking about. First you say a recognized expert is kinda right, but lo and behold, if only we had open source, that would be the end of our woes.
You have to remember that most open source software doesn't provide any degrees of assurance other than "it's been used by alot of people". This really isn't an option for vertically integrated solutions such as digital voting. Just how many hobbests are going to "hack on" the GNU Vote system ?
The track record on contribution by the general public to OSS projects is pretty poor. Look at Mozilla, emacs, linux kernel, etc. Most of the significant contribution has been done by a relatively small number of persons. While lots of useful bug reports and patches have been submitted, I think for electronic voting we need a bit more than "lots of people have submitted bug patches."
What she is talking about here is engineered assurance. OSS is a source code policy, not an engineering style.
With that in mind, I think the best system is still a card system (specifically the "complete the arrow" system). It won't crash, it's recountible as many times as you need (no chads shaking loose in the counting machine) and it's so easy that even the retarded old people living in certain Florida counties can figure it out.
The best part is that it uses no complex parts (which, according to Murphy's Law, are prone to failure on election day). Just a paper and pen -- beat that. Add a reasonable amount of physical security (deputies at each location, plus maybe a representative from each major party to observe) and you're good to go.
This is one of those situations where overthinking and overengineering comes back to bite you.
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
I think her suggested list applies to a lot more than voting. She deserves a lot of credit, because work like hers is the dirty work no one ever wants to do... real nuts-and-bolts stuff that takes lots of thought.
;)
I love it -- Take that all you kiddies who say "duh, how hard could it be? I could do it in perl in an afternoon, i'm so huge!" huge you are!
https://www.accountkiller.com/removal-requested
We only really know how bad the Florida system was because the election was a statistical tie, leading to the recounts and a very close look at the process. I'd suspect that many states have very similar problems, for example Maryland in the current primary, and we simply aren't as aware of them.
Consider a computer supplier that is co-opted by an unscrupulous political party. They create some sort of hardware mod that allows the contents of memory to be arbitrarily modified. Perhaps it can be controlled wirelessly. Suddenly bootable serial numbered CD-ROMS aren't a solution.
The advantage to the pencil-and-paper system is that to my knowledge, nobody has developed paper that can cause a mark on its surface to be erased and another mark drawn while the paper is in the ballot box. People can watch the ballot go into the box, they can watch it come out, and be sure that nothing has occurred to change the vote thereupon. When the vote is nothing but electrons inside a machine, this is much more difficult.
This sig is umop apisdn.
As an improvement to that, in this year elections in Brazil a new system will be tried where the ballot prints the vote on a paper which will be shown to the voter through a transparent window, but will not be otherwise accessible before it's cut loose and drops into a sealed canvas bag. Votes will be counted electronically as before, but the canvas bag will provide a way of auditing the whole ballot, if needed.
Bootable, hologrammed, serial-numbered CD-ROMs with individual private keys would do the trick.
Um, how exactly? (the most obvious question is why you need a hologram, or a CD rom for that matter)
Of course, since you didn't even provide a process to knock down, just some techno babble it would be impossible to tell you exactly why you're wrong.
autopr0n is like, down and stuff.
As it turns out, open code and "thoroughly examined hardware" do not a secure system make. The problem is that the code has to get compiled, and it has to run on an operating system, and that has to run on a computer. Even if the code and hardware (if one can examine the microcode) appears to be entirely pristine, Ken Thompson explained in his classic 1984 essay "Reflections on Trusting Trust" (available online, do a Google search) that the compiler that compiled all of that code can be rigged such that malicious code can be concealed. For example: Since the dates of US National Elections are fixed to infinity (they are always the 1st Tuesday in November) and since many voting systems (as well as computer systems) rely on real-time clocks, it is certainly plausible to create a hardware trap that only goes off on election day. And that trap doesn't have to be in the voting system either, there's tallying devices, reporting software, and so on. It's a nightmare. The only sane solution is to rely on a voter-verified physical audit trail that can be READ BY HUMANS in case of the necessity for a recount. There's a lot of ways this can be performed (including one by David Chaum that allows the voter to verify that their ballot actually was entered into the final tallies), and true improvements in voting systems will only occur when this is recognized and the "trust us" mentality (including one that says we should trust the people who will supposedly verify all the open code) is abandoned. Please read the extensive writings on Rebecca's website www.notablesoftware.com/evote.html as well as Peter Neumann's for more information on the subject. And for those of you who are convinced, PLEASE encourage all communities who happened to purchase fully-electronic voting systems to have them retrofitted with printers BEFORE the November general election. Brazil is doing just that, right now, with 3% of the 400,000 voting machines they purchased back in 2000 (more may follow).