Slashdot Mirror
CA Sec. of State Panel on Open Source Elections
goombah99 writes "The Open Voting Consortium has announced that California Secretary of State Bruce McPherson is forming a panel to investigate using open source software in elections. Suggested Panel members include Security expert Bruce Perens and Python guru David Mertz who is associated with the sourceforge EVM2003 voting machine project. This is big since a favorable outcome could help fund prototypes of true open source election equipment and systems."
I don't hold out much hope, especially since this is California - the land of the Guvernator. On the other hand, it is also the hotbed of the open source movement. So, there might be some hope.
What we really need is a tremendous scandal in an election: something like all votes are lost and Ross Perot gets elected to the school board, or something. Only then will people actually wake up and realize that they vote is easily in jeopardy from proprietary and unresponsive (and partisan, I might add) election powerhouses like Diebold.
let the flamebait mod down begin...
No, I'm sorry, but that's not sufficient.
The compiler (which is executed as a binary) itself could be subverted.
The compiler can take the good friendly Open Source, compile like normal (for the most part,) but then inject some nastiness wherever it was programmed to.
Even observing the compilation of the compiler does not help, because someone can subvert the compiler that compiles the compiler.
What I recommend: Humans performing pencil & paper counting under scrutiny of video camera and representatives of competing parties. Distribute the video tapes of the counting process on the Internet, and maintain archives for at least 12 years.
Bruce
Bruce Perens.
Its not clear what point you are making here.
- Is it they do other critical transactions so they must be good at it.
- Or is it that their ATM machines might be bad too.
If its the later, ATM machines are completely different problem from voting machines.
ATM machines have to have printers and provide a receipt at least as an option. Most of Diebold's machines have no printer and no option to get a receipt.
If Diebold's ATM machines start doing wrong transactions it would become immediately apparent to the bank and any customer who has a bookkeeping system.
ATM machines and bank transactions don't have to maintain anonymity of the user, voting systems do. It really complicates validation of the transaction.
A paper receipt, verifiable by the voter, deposited in a lock box and subjet to very random recounts would solve most of the uncertainty in electronic voting.
All in all open source would be better than closed source for electronic voting machines but it would provide zero certainty that the election still isn't being rigged electronically. The only two good ways to insure good elections are:
- paper ballets marked with a pencil, watch and counted like a hawk by multiple adverserial observers which works great in just about every country but America.
- if you have to do evoting, you have to have a printer, and a human verifiable receipt going in to a lockbox and hand recounted by adverserial.
@de_machina
Problem: human-readable is hard for machines to interpret at high speed. With barcode you can scan ballots and tally them basically as fast as you can feed sheets through the scanner. That allows for convenient cross-checking of the electronic total, and makes it feasible to verify a large percentage of the ballots (in theory you could scan 100% of the ballots in a few days, making the electronic totals simply an early prediction and not the official result). That makes it really hard to fudge the electronic totals without it being caught.
And yes, I allowed for the possibility of the terminals programmed to print a different barcode than the voter wanted. That's why there's also a human-readable version printed. To check whether the human-readable and barcode entries are the same, a human can read the name, pick a template of the barcode that should go with that name, put the template against the printed barcode and see if it seamlessly matches (barcode OK) or if the lines don't match (barcode doesn't match name). Humans are good at that kind of visual pattern-matching, so it should be possible to check 20% or so of ballots this way. If the checks are done at random, it should be very very hard for the barcodes to be fudged without it being caught.
As a final check, in case someone has managed to both alter the barcodes the terminals print and the templates used to check the barcode-to-name matching, you can manually count ballots using only the human-readable names. You wouldn't do this for a large percentage of the ballots, say 1 precinct in 20 selected at random. I'd have both the selection and the counting of ballots done not by election officials but by representatives of the various parties and interest groups observing the election. They don't all want the same outcome, so it'll be very hard to get all of them to agree to fudge the results the same way. If the manual count disagrees with the electronic or barcode counts, we go to more extensive manual counts.
Three different layers, all using different technologies and methods to verify the count. If the barcode scanners are made by a different vendor than the voting terminals, the barcode checking templates are prepared by someone unconnected to the terminal and scanner vendors and the name counting is done by people not connected to the rest of the voting system and with competing interests, it should be almost impossible to fudge the count by any method other than wholesale replacement of the printed ballots prior to the first barcode scan. And that, quite frankly, is a problem that can be handled by simpler techniques than those needed to secure a fully-electronic system.