Slashdot Mirror
Open Source Voting Software Concept Released
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."
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.
Early reports are now in on the software. Though it runs faster than proprietary rivals, the power management doesn't work, its not yet configured to work with touch screens, and it can only be administered by grumpy self righteous technicians who insist that voters read the man pages before voicing questions.
I really don't understand what problem electronic voting using computers is supposed to solve. Why not just make scantron ballots (some places already use them) they are paper so they are verifiable, easy to understand (who didn't have to do a multitude of these in high school?), and a machine can calculate them. About the only glitch is you can't change your mind without getting a new ballot, but its honestly not that hard.
Taxation is legalized theft, no more, no less.
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.
Help stamp out iliturcy.
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.
Taxation is legalized theft, no more, no less.
Come back when it is not written in an interpreted language, in a language capable of driving hardware, and it has "real" functionality. I looked quickly, and the tabulation code is virtually empty. Both the Python and the Javascript will be non-starters and the code rejected out of hand the first time reviewed (and none of the VSTL's will have anyone capable of reviewing Python). Java passes because of the bytecode. Python might pass because of the .pyc files. The Javascript will be a problem. The lack of type declarations will likely also be a problem in Python. It will be hard to follow the documentation rules that require all of the types to be documented.
None of this code stands a chance of VVSG compliance (the Federal Election standards which code must pass to be certified if any Federal funds are used to purchase the hardware or software). The list of blatantly obvious things wrong with the code base in the one file I looked in:
Or at least those are the obvious things I found in one example file in the 2 minutes it took me to scan it quickly. Remember, the coding guidelines are written by people who have never written a line of code, and are designed to protect against common mistakes from the mid-80s. So the fact that the entire system is in version control is irrelevant. Even if you give them all of the version control, you must document the changes to the code at the top of the file. You must document the changes per function. Even though no one would ever do it in this day and age, your code must be printable on a standard 8.5" wide paper.
All of the rules required to follow are obscene. You can't have function or variable names that differ by a single letter. It took 3-4 years to get an exception to that rule to allow the usage of "getFoo", "setFoo", because they differ by a single letter. You can't use 0x80 to represent the MSB of a byte, if you call that PIN_8, and had PIN_1 those differ by a single character, so we had to do PIN_EIGHT, PIN_ONE. It's just archaic. Oh, and you get to document every function a function calls. Because they couldn't possible use a compiler that would build a call list automatically.
The rules don't explicitly mention exceptions, so it depends on who is reading the code if they treat an exception as having multiple entry/exit points. So it is generally easier to get the code past compliance without exceptions, even if it does lead to buggier code. The other rule they invoke is that you are only allowed to use the control flow structures documented in the VVSG (they have flow charts for the allowable forms of if, if/else, for, while, and switch statements. They specifically state that if the language you are using does not have those, you must simulate those flows of control in the language used.
Oh, and if LA thinks it has the hardest jurisdiction because they have 7 languages, I believe NY has at least 20-30 languages or dialects just in NYC, they have several election districts (they'd be called precincts anywhere else in the country, but in NY, the word precinct is only used for the NYPD and maybe the NYFD) that have more then 7.
I've written code that has been used to count ballots in both state and federal elections. Trust me, this code base will have to be re-written from scratch to meet the 2002 or
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.