Open Source Voting Software Concept Released 121
filesiteguy writes "Wired is reporting that the Open Source Digital Voting Foundation has announced the first release of Linux- and Ruby-based election management software. This software should compete in the same realm as Election Systems & Software, as well as Diebold/Premiere for use by County registrars. Mitch Kapor — founder of Lotus 1-2-3 — and Dean Logan, Registrar for Los Angeles County, and Debra Bowen, California Secretary of State, all took part in a formal announcement ceremony. The OSDV is working with multiple jurisdictions, activists, developers and other organizations to bring together 'the best and brightest in technology and policy' to create 'guidelines and specifications for high assurance digital voting services.' The announcement was made as part of the OSDV Trust the Vote project, where open source tools are to be used to create a certifiable and sustainable open source voting system."
Programmer Thinking (Score:5, Insightful)
Once again, programmers thinking software will change the world.
Elections are not based on trust of software, it is based on trust of the PROCESS.
Don't trust the PROCESS, and it doesn't matter how trustworthy your software is.
I want an PROCESS that has ACCOUNTABILITY. A "Bug" in your software means someone goes to jail for negligence, or pays for the cost of a reelection.
Here in the great white North, we have a paper ballot. A simple "X" inside a circle. Human verifiable, countable, no switches, electrons, software, etc. Weeks or months after the election I can see the recounts.
Software can solve a lot of problems, trust is not one of them.
Re:Sweet! (Score:3, Insightful)
No it's not. Slashdot was up in arms against electronic voting when it was closed-source. Open-source doesn't make much of a difference.
And Ruby? Linux? What. Assuming they compile Ruby into java bytecode or something to sidestep the FEC regulation against interpreted code in voting machines, Ruby still isn't a great choice. It should run absolutely as close as possible to bare metal to make sure a JVM bug or a Ruby bug doesn't affect the results. Anyway, why Ruby? Not that I have anything against it but really why did they pick Ruby?
Linux wouldn't be my choice for a kernel either. It's too experimental and rapidly changing for me to feel great about asking 300 million people to trust it, at least while we have OpenBSD lying around.
Re:Programmer Thinking (Score:3, Insightful)
That isn't even going into the fact that I don't even trust our election system because it doesn't give equal representation to people with different political views....
Re:Programmer Thinking (Score:3, Insightful)
Computers should count votes (Score:4, Insightful)
Once they've been granted suffrage. Not before.
I post this same post every time we have a computerized vote counting thread. My objection to this has nothing to do with whether it's a secret proprietary process or a totally open FOSS solution. With each generation of computer technology we gain the opportunity to go wrong with greater speed than ever before. Yes, proprietary solutions are horrid and there's some evidence that they've been used to steal votes and they're truly evil. Unfortunately, FOSS tools can be abused too.
I guess my point is that the process of counting votes using humans is an important part of representative democracy because it doesn't just achieve the goal of "counting the vote". It also impresses on the participants the importance of sanity and trust and impartiality in the process, without which constant reinforcement we can expect democracy to rapidly go off the rails. Compared to that social good, the importance of getting same-day results fades in importance.
Re:Programmer Thinking (Score:3, Insightful)
That's why votes are counted by groups of people who make sure they are valid and, in some cases, will have counters making sure the counting remains politically balanced. Not by a single person.
Re:Sweet! (Score:4, Insightful)
No it's not. Slashdot was up in arms against electronic voting when it was closed-source. Open-source doesn't make much of a difference.
While I still think we should use paper ballots (what exactly does e-voting gain us?) it makes a world of difference if the code is open or closed source. Voting is all about trust, if I can see the source and verify that it doesn't have any major bugs in it that is a step in the right direction compared to closed source. Secondly open source is cheaper, I don't want my tax dollars wasted on proprietary software, especially if there is an open source alternative. If we are going to have e-voting, it had better be open source, closed source is unacceptable.
Ruby still isn't a great choice. It should run absolutely as close as possible to bare metal to make sure a JVM bug or a Ruby bug doesn't affect the results.
Sure, but it does provide more readable and testable code while reducing the risk of hardware dependent errors. I think most people can say with certainty that the Ruby interpreter is reasonably stable as is the JVM.
Linux wouldn't be my choice for a kernel either. It's too experimental and rapidly changing for me to feel great about asking 300 million people to trust it
Does Linux change? Yes. Does that affect the stability of a certain kernel version? No. If they stick with 2.6.31.5, it doesn't matter if 2 months from now if 2.6.32 comes out because 2.6.31.5 will still run with no problem (outside of some serious bug), everything in voting machines should be static, no new hardware, no new software, just configuration changes. Linux has been running in embedded systems just like what I described for years now with no problems.
Re:Programmer Thinking (Score:3, Insightful)
Re:I don't get... (Score:3, Insightful)
I really don't understand what problem electronic voting using computers is supposed to solve.
Handicap accessibility, ballot complexity, but mostly hanging chads.
The ability to almost instantly compile election results is just a bonus.
Scantron ballots are a good idea, but people are stupid &/or prone to mistakes and will screw it up.
Re:Solving the problem wrong (Score:4, Insightful)
Wait a sec...step back. Take a deep breath and think this through.
All those rules you described are there for what purpose exactly? Because as far as I can see, those rules have not made existing voting software (which presumably meets these guidelines) any more reliable or trustworthy. If the only reason these rules exist is to make the software secure and trustworthy, and if they create what appears to be a huge burden for developers of voting systems, then perhaps we need to throw out this particular set of guidelines *along with* the existing crappy voting software.
Am I the only one to whom this is obvious? These rules don't exist for their own sake - they exist to achieve a goal. If they're not achieving that goal, the rules need to be rewritten before you even touch a single line of this code.
In Ruby?! Shirley you jest (Score:3, Insightful)
Oh for fucks sake, you have to be kidding me!
You want the Federal Election Commission to trust a voting machine written in a language used by script-kiddies?! That is utterly laughable in light of the DIEBOLD VB/Access debacle
This needs to be a completely stripped down Linux core, NOTHING in it except what is EXACTLY need to do this. It needs to be written in C, not C++, and I mean COMPLETELY documented ( to the point of inanity), PLAINLY written, VERBOSE code and if you want a better chance write it in ADA, that is what the government is used to dealing with and the code MUST be open source
You need to go as far as stripping down the standard C libraries to ONLY the functions called by the SINGLE program that makes it work
EVERY buffer, EVERY array must be bounds checked. There can be NO POSSIBILITY of ANY kind of a buffer overflow attack.
If you are going to use an off the shelf MB any open slot and or connector not used by a component SPECIFICALLY required to make it work must by PHYSICALLY disabled ( cut the traces/wires or whatever ). The BIOS must be custom,designed and coded to do ONLY those functions require to boot the machine, further that BIOS must be OPEN SOURCE.
As others have pointed out the PROCESS must be VERIFIABLE, it must be RELIABLE, it must be PREDICTABLE 100% of the time. There can be NO race conditions, there can be NO un-handled exceptions, and EVERY exception must have a reliable, repeatable, reproduceable result, in other words "Kernel Panic" is NOT an option.
In short it must be a totally custom machine, and created by people 100% NOT interested in getting rich.
Re:Sweet! (Score:3, Insightful)
You do know though, that the source is not the code that is running on the machine iself, right?
How do you propose to verify that the source code has not been altered before or during the compilation process? I guess, since the source is available you could compile it yourself and write down the checksum to compare with the voting machine binary checksum. Wait, how do you get that, some program running on the voting machine? Also, you know that the voting machine counts a certain number of votes but that count must pass through an indeterminate number of machines upstream, any one of which could be tweaking the figures. Who do you trust?
No, you were right the first time, paper ballots and manual counting is best. Yes, it is labour intensive and slow but IMO the real benefit of that is secondary in that lots of people must participate in the voting process and they may come to realise that the political process is not about what politicians want but is run by and for the people. I don't want to see a streamlined political process, extended discussion and well thought out arguments are vital! Moreover, I think election day should be a national holiday and it should be illegal to operate any non essential business. All citizens should be required to attend voting stations for a certain minimum time, not just to vote but to participate in the process.
Re:OK, why Linux, why Ruby? (Score:4, Insightful)
Known by whom? Python fanbois?
I'm honestly not trolling and I'm honestly not trying to start a Python/Ruby flame war, but let's not try to hide opinions behind worthless statements like "Python is known to be," particularly when the metric is as subjective as "readb[ility]."
Aside from the enforced nature of Python whitespace, I don't find there to be much of a difference between the two in terms of readability. I prefer specified ending blocks, whereas Python seems to merely use a blank line and the indentation. What jumps out at me (as a Ruby fan) more than anything is how stupid and unintuitive '"""' is as a commenting option. Eesh. But all of that is personal preferences, as it should be. There's no substantive differences and certainly nothing measurable enough that we should bandy about statements like Python being known to be more readable.
Chances are, by the way, that's your answer. Why Ruby instead of Python? The authors likely preferred it and were more familiar with it. It needn't be any more complex than that.
They're missing the point... (Score:3, Insightful)
Voting machines are inherently untrustworthy. Publish all the code you like. Have it inspected by Donald Knuth. The voters have no way of knowing that that code is what's actually running on the machines in the polling stations, or that the hardware will execute it in the way that the language spec says it should. Attempts to give them a way to know are a sticking plaster over a gaping wound - there are too many things about the machine that are invisible to the naked eye, and too many ways in which the machine can be made to lie.
Paper-based elections need a lot of people to run them. This is a good thing, because someone who wants to rig an election has to bribe or threaten a lot of people. The more people are in that position, the more likely one of them is to blow the whistle. Someone who wants to rig an election that's run by voting machines has to influence far fewer people. That's the whole point of computers - they do work that would otherwise have to be done by people. If you want to bring in lots more people who are hard to bribe or threaten, you might as well have them run the election and leave the computers out of it.
The argument that voting machines will give us the result of the election faster than paper ballots is true but irrelevant. Do you want the wrong answer in half an hour, or the right answer in two days? A politician, once elected, will serve for three to five years, and unless he drops dead or gets a blowjob from the wrong person, it's very hard to remove him before the next election. You'd better be damn sure that the guy you put there was the one the people actually wanted.
Solves paper ballot management problems (Score:3, Insightful)
These problems are, of course, completely manageable, but at a cost. Election officials would welcome a cheaper alternative balloting system, provided it worked just as well as the best ones in use now. That the the crux of the issue.
Re:Sweet! (Score:2, Insightful)
While I still think we should use paper ballots (what exactly does e-voting gain us?)
e-voting gains the ability to know the results instantaneously the moment voting ends, and saves lots of man-hours counting them. The former is pointless, as any hand-over of power never happens until days/weeks/months later, and neither are worth eliminating the possibility of a recount.
Machine-readable paper-ballots seems to be a decent compromise. Instant results with recount possibilities. A smallish number of humans can double-check some samples to ensure the machine results are correct, and trigger larger manual recounts if there is reason to believe the machines malfunctioned or were tampered with.