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."

Comments

Solving the problem wrong

[ComputerSlicer23]

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:

• The code files does not have a valid modification history for the file.
• The code does not have per function comments.
• The code uses multiple returns inside of a single function.
• Repeatedly use the same values without having them be assigned to a constant.
• Have single variable letter names that are not used for array indexes.
• Usage of numerical constants other then -1, 0, 1 without a comment explaining the value.
• Not all control flows decision points are documented.
• It has lines longer then 80 characters.

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

Re:Solving the problem wrong

[FlyingGuy]

I was thinking the same thing, then I went and looked at the code and saw this:

import os
import json

from django.template import Context, loader, RequestContext
from django.http import HttpResponse, HttpResponseRedirect, HttpRequest
from django.shortcuts import render_to_response
from django.conf import settings
from django.contrib.auth import authenticate, login, logout
from django.contrib.auth.decorators import login_required

Just as soon as I saw that, it was like, Ahh HELL NO!

I mean lets just throw in the entire kitchen sink! There is not a snowballs chance in hell of this EVER getting certified. JUST the holes/kludges in http & css will get you laughed out of the running!

Re:Solving the problem wrong

[ComputerSlicer23]

I completely and totally agree with the notion that those rules are stupid. However, most states use Federal Funding for the purchase of hardware for elections. Once that is done, you must be certified by the FEC, and you must follow the above guidelines. Unless your state officials want to break Federal laws, or can find all the money for it from non-Federal sources, those rules will have to be followed. It's not like you can use an off-the-shelf computer, and the hardware is only good once maybe twice a year. You'll need one that refuses all external input except for the types of storage you plan on using to transport the votes from a machine. Even if all of the software is secure from this Open Source code, they will still need to get secure hardware. The problem is you send everyone to a place alone with the machine where they have total access. Securing the machine is actually, extremely difficult.

From what I know of the state and counties, they all use Federal money. Everybody who took HAVA money has to follow both those and ROHS rules for the hardware (ROHS, I might have the acronym wrong, but it's the environmental friendly hardware when you go to dispose of it, so no using lead, etc, etc). Even most states defer to the FEC to set testing guidelines, and most states will refuse anything that does not pass the VVSG hardware and software guidelines.

You can't run an election without a scanner of some sort. You'll need a scantron type solution for a state wide vote. You can't run those any other way. If you say "DRE", I'm going to smack you. Even one's with paper trails are stupid. Scantrons to count, and paper ballots are the only way, unless we hand count (which I've got no problem with, but the computers generally do a better job, especially if you want to do accurate stats for funding of parties). Once you start doing scantrons it will require custom hardware, and the state will be incapable of dealing with it.

I think it would be great to require a security review from real security folks. The problem with most of the VSTL employees I've dealt with, is that they aren't capable of getting a paying programmers job. That's why they review someone else's code. We tried fairly hard with the stuff I worked on. We used Linux, and used a "known" Live CD to boot from, and had a completely scripted build from source code. With the exception of the RSA Crypto library and the JDK/JRE (because we couldn't prove OpenSSL's was FIPS-140.2 compliant on our OS and hardware), everything was built in from of an Election official. We built the entire toolchain that would then build the absolutely everything that was installed on the firmware. For a "real" security review, we had almost everything. If OpenJDK had been released at the time, we would have built the JDK/JRE from scratch also.

The stuff I worked on could have been hacked, especially if the source code ever leaked. Not that it was blatantly insecure, but like most code written, it has bugs and flaws that more eyes would catch. We generally did a good job using constructs that avoided buffer overflows (we avoided most C in favor of C++ where possible). The problem was the size of the programming team (I'm guessing that maybe 5-6 full time programmers worked on the system that counted a significant fraction of the votes in the 2000 and 2004 elections). I left because of the dysfunction inside the company due to dealing with Federal crapola. I just hated the code I had to write. I hated how old and antiquated the rules I had to follow were. It was a fun gig, and I liked that I got to contribute to cleaning up some of the problems folks have with electronic voting. I took it very seriously.

I agree with you, the solution is to update the rules to involve actual security. The problem is you most literally can't. There are lots of "rules of thumb", but if there were actual rules to follow, we wouldn't have security professionals we'd just write a compiler that understood the rules. These rules exis

Re:Programmer Thinking

[Walkingshark]

Or, you could just do it the obvious way that no one ever talks about:

1) You fill out your ballot electronically (on a touch screen or whatever)
2) Ballot box prints out a human-readable ballot.
3) You check over to make sure there are no mistakes
4) You carry your ballot over to the ballot box and drop it in, where a scanner scans the ballot in and counts your votes.
5) Later, if there is a problem, humans go back and count the votes by hand (as they do now)
6) There you go, all the benefits of electronic voting AND all the benefits of paper and pen voting all in one easy to understand system

Problem: it doesn't leverage the power of electronic information technology to make it ridiculously easy to steal an election. Thats why it will never happen in this country.