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.
That's pretty cool.
"The ability to delude yourself may be an important survival tool" - Jane Wagner -
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.
If so it could let a lot of counties currently stuck with that PoC switch to the open source code without buying extra hardware. Just load the free software in the existing hardware (and maybe add a printer).
The Diebold machines are essentially PCs with touchscreens so they shouldn't be a tough port for Linux and the apps.
Using the existing hardware could save a bundle.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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.
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.'
So... ahh... good luck with that. Sounds a lot like swimming through sewerage to me, but I guess somebody has to do it.
... and then they built the supercollider.
Curious about the choice of OS, given that Linux security, especially the kernel, is known to be inferior to BSD, OpenBSD in particular. Also curious about the choice of programming language, Ruby, when Python is known to be more readable, and more easily audited. Shouldn't the most important feature of a voting system, aside from useability and accesibility, be its auditability? Why would anyone choose a system that is known to be less auditable and less secure?
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.
Electronic voting machine allows people to vote, prints off a small receipt.
Receipt has:
1) name/choice of every vote made, human readable
2) a barcode that encodes all this information
Verifiable:
each and every receipt can be shown to have words matching what the barcode says
Countable:
Just scan each receipt, or if you aren't sure after that, have humans count the names read on the ballat
Voter intent:
No more problems of 'did they really mean to vote for that guy?' there aren't 'levels of inking' just black and white, this is the name on the slip.
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
I want an PROCESS that has ACCOUNTABILITY.
You apparently want a pony. Whatever the process and accountability may be with FOSS voting systems, they are almost certainly better than anything Diebold has been offering.
A "Bug" in your software means someone goes to jail for negligence, or pays for the cost of a reelection.
If that's your standard, only crooks will provide voting software.
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.
And yet subject to widespread abuses--historical and contemporary--as well.
"Trust the vote"? Only if the people voting are regular readers of dailypaul.com
systematically verified, by requiring percentages of votes to be verified anonymously and privately, over a commensurate period of time.
perhaps by having the voter be contacted and asked for a token that was provided when the voting occured
Better hope no more than 25 vote then ...
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.
Hey KID! Yeah you, get the fuck off my lawn!
Why not go further? There's no reason why a voting machine should even be Turing complete. For plain old Plurality voting, simply have a machine that reads input (buttons or touchscreen, whatever), then blows an antifuse for the selected candidate and fuses for all the other candidates, on a PROM. Connect the PROMs to a central counter which tabulates the ballots, and there you are. (If you want Condorcet, each "ballot" needs log n bits per candidate, not just one).
What I'm saying is: design the computer out of least privilege in terms of hardware. If the computer doesn't need to modify its own code (and why would a voting machine need to do that?) then just make that impossible. They can't hack what isn't there.
And you plan to run your well stripped, lean, mean linux on....
Specially crafted hardware at the doping level.
And when you figure all this bullshit out, be sure to install it on MY HARDWARE YOU DIPSHITS!
And furthermore why isn't corporate media talking about this huh? Too fucking scared to get shredded?
adn after your all done, you stupidly installed it on my specially crafted hardware!!!!!!!!!
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.
Just another wannabe fantasy novelist...
All this focus on securing an inherently insecure channel..I suggest we instead make sure that if the votes are not OK then it will be discovered after the election? I mean, if anonymity weren't an issue it would be as easy as having a list at the library after the election with names of people in one column and whatever they voted for in another. If everyone is happy with their own entry and the list doesn't have bogus entries, the election went well. Since anonymity is an issue, let the voters draw their receit number from a hat and use that number in the library list instead.
So good it was worth saying three times, huh?
To err is human, to really screw things up takes a computer.
Hey KID! Yeah you, get the fuck off my lawn!
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.
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
No, but I'm not opposed to them giving it a try either. If you look at the projects on sourceforge, the overwhelming majority of them are either dead or dormant, but that doesn't make the open source process that lead to them a complete dud.
Some great open source projects have come out of sourceforge (and many other places as well of course). I don't know if the success rate is 1%, or 0.5%, or even lower than that, but whatever it is, I'd still consider the process a good one.
Also, the desire to create open source software is so high and the barrier to entry is so low, many programming newbies end up cutting their teeth on those types of projects. This encourages participation and programming literacy. And a newbie may not be able to code a perfect voting solution for instance, but at least even if his solution is not selected for any election, or doesn't even come close to being selected for one, it only means that there is at least one more person that's at least semi-computer literate and invested enough to weigh in for the process of selecting a voting solution.
That's it really.
The paper is better because it's verifiable, and does not require trusting enabling technology to run an election. No electronic system meets this criteria, unless it's voting record is written to physical media in a human readable, enduring way. So then, why bother?
Doing it with paper gets people involved in their civics too.
I'll give them top marks for open source, but a FAIL for it just not being a necessary thing.
Blogging because I can...
I completely and whole heartedly agree with you, the ground swell has to start someplace and this could very well be it and if nothing else they will more then likely come up with a great prototype.
Languages like python, ruby, php et. all. would be a great place to start prototyping these sorts of systems since they can provide critical proof of concept.
Once they get the process flow figured out and rock solid then you take that and prot it over to a proofable language and hardware. MANY such systems are created on vanilla PC hardware with scripting languages snd then when the whole thing is figured out, it is then ported to the hardware in a language that can be paired down to the bare essentials to get the job done.
Hey KID! Yeah you, get the fuck off my lawn!
It's not done at quite that low a level, but that is effectively how India does it. Dedicated devices that do a limited number of one-way writes.
It's a nation of a billion people with a huge land area, a hojillion languages, and far from universal literacy, and they still have electronic voting. And it's one system. And it works.
seriously.
All we get for electronic voting is some speed. There isn't much else.
My core problem with the e-vote happens to be that the vote record is not verifiable without a human having to trust enabling technology. When elections end up in the court room, those human readable records happen to matter. If we e-vote, it's going to be impossible to discuss voter intent, because no direct record of the voter intent will exist.
Those of us, who do take the civics seriously, happen to be concerned about that.
There is a chain of trust between voter and the record of the vote used for the tally. With physical media, this chain of trust is unbroken. Voter can see the record and verify it against their intent. We then have an enduring record of the voter intent.
With an electronic proxy, this chain of trust is broken. Voter cannot directly see the record of the vote used for the tally, and therefore is forced to trust the electronic proxy, because the use of enabling technology is a required element of the process. The record we have then is what the machine though the voter intent was, not an actual record of the voter intent. Secondly, the voter then must trust the feed back given to them as being one and the same as the vote record itself.
Where there is a proxy, there can and will be abuses.
Sorry. I see absolutely no value add coming from e-voting. The speed is nice, but arguably it's not something preferable.
There are paper systems, such as the Oregon and Washington Vote By Mail system that act as a hybrid. Counting is done electronically in one central location, where all the physical vote records are aggregated. Challenges, audits and all the other classic election doubt remedies, up to and including a physical hand count, under the public eye, remain possible, meaning disputes can be settled in a court of law in a verifiable and trustworthy way.
The core problem we have with e-voting is the requirement that votes not be personally identifiable after being collected for the tally. Financial systems are trusted because they are personally verifiable, meaning we can go back and query the participants in the transaction to verify the record. With e-voting this is not going to be possible, without either being forced to trust a proxy technology, or by making the votes personally identifiable.
Neither of these two is an acceptable trade-off for the speed, which is the only significant advantage e-voting has.
Well designed physical media based voting systems are capable of convenience, enough speed to be useful, and are verifiable and auditable to the highest degree.
Don't get me wrong, I'm all for open source, etc... but this is one area where we simply don't need computers and code. The core civic process is a people based one, and should consist of those classic, time tested and verifiable things so that a court of law can render a decision, without the parties being forced to trust enabling technology.
Trustworthy elections embody these four ideas to the maximum possible:
Transparency -- humans need to be able to follow a vote from it being cast to tally. It's not important that they actually do so, only that it is completely possible to do so. E-voting systems do not allow this, and depend on a layer of secrecy to bring security. This is in contradiction to what makes elections trustworthy.
Oversight -- The law and record of the vote and the process must be visible and known to all. Open Source voting systems do bring more oversight to the e-vote process, but it's still not enough for the actual record of the vote to be tallied under the public eye.
Ideally, nothing but the personally identifiable nature of a vote should be secret or done by proxy, unless no other means exist. Handicapped people, may require a proxy, for example.
Freedom -- Any citizen may choose to vote or not as they see fit.
Anonyminity -- no enduring record of the vote may be personally identifiable back to the pers
Blogging because I can...
In fact, a hybrid would be appealing to me.
Major league issues should be full on democracy. Those things take time, debate, and need to be executed with the higher levels of trust. A Presidential election as opposed to some city measure would be examples of the extremes.
I've no problem with electronic counting and such. My primary issue is the trusted record of voter intent. Electronics really can't do that, and they cannot be audited with a level of discussion suitable for a court of law. It is possible, through a chain of testimony and direct examination of the record of the vote on paper, to establish a trustworthy, just and true decision regarding the voter intent, or of criminal manpulation.
These things are not possible electronically, without having to first trust an enabling, proxy technology. That proxy is at issue.
If we use machines to help with the counting, the actual vote record exists to sort issues, failures, etc... out.
Some elements of what you describe are desirable. I don't think we are suffering for lack of them, and I'm also not sold on all matters being improved with them.
If we can settle on the record of the vote issues, I'm inclined to go a ways down this road to see what it brings.
However, we do not have good consensus on what makes an election trustworthy, and without that being well established in law, enforced and taking seriously, e-voting is a distraction that is highly likely to do more harm than good.
Blogging because I can...