E-Voting News and Analysis, from the Experts

Saturday November 06, 2004

Open Source Software in E-voting

Filed under: — Joseph Lorenzo Hall @ 4:37 pm UTC

(This is a highly abbreviated version of a forthcoming paper)

Approximately one year ago, California Secretary of State Kevin Shelley handed down the first open source software mandate (PDF) of any U.S. government official. This open source mandate came in response to a specific subsystem of electronic voting machines: the system that verifies the selections on an AVVPAT for disabled voters must run on open source software. As well, Rush Holt’s bill (HR 2239, 108th Congress) require that “No voting system shall at any time contain or use undisclosed software.”

There have been attempts in the past at coding open source election software for Internet voting. For example: Lorrie Cranor’s Sensus, MIT’s EVOX and Jason Kitcat’s GNU.FREE. All of these systems are now unmaintained, and voting over IP (a/k/a the other VoIP) has been fundamentally discredited by David Jefferson, Avi Rubin, Barbara Simons and David Wagner in their report examining the Pentagon’s SERVE project.

However, there hasn’t been a serious effort at developing an open platform for polling place voting until recently. In the past few years, the Open Voting Consortium (OVC) has developed software and a design for an open voting platform. The software, EVM2003, is written in python using XML ballot specifications and can run on a standard PC using a CD-bootable GNU/Linux called Knoppix. The OVC is currently in the middle of a fundraising campaign to get “1111 subscribers by 11/11″ to raise money for their efforts from small, grass-roots donations of $10 a pop; if you have a decent salary and less than two kids, consider give them a few bucks. (None of which should be confused with the Open Vote Foundation which intends to fork the open source Australian e-voting software called eVACS that is no longer open source)

Why open source?

Elections have a long history of being open processes. Openness is one of the central aspects that lends legitimacy to the electoral process. Even with lever-based election machines, which have been around since the last few decades of the 19th century, it was still possible for election officials to hire a reasonably confident engineer to open the machine up and verify that, in fact, the right gears were turning the proper amount of times.

Over the past two decades, computerized technology has become a growing element of election administration and many parts of voting technology are now enshrouded in mystery. Computer software is subject to all types of intellectual property protection (copyright, patents, trade secrets and trademark) and electronic voting machine vendors are notoriously protective of their products. They do business in a small and highly competitive market that has just seen a large injection of $3.9 billion from HAVA. While any trade secret that they may hold is in no way rocket science, you can imagine that their implementation of software and hardware would give their competitors an edge if known publicly.

Now that we are seeing serious concerns in the areas of vote tabulation and human factors from Tuesday’s election, there will be a need, as David Wagner suggests below, for comprehensive investigation into the source of these problems. Undoubtedly, this will involve examinations of source code and attempts to reproduce problems on the same machines used in the election. The examination of any vendor’s source code is a particularly sensitive topic filled with NDAs and negotiation; for example, it took the California office of the SoS 6 months to negotiate the terms of an independent source code examination of California’s four EVM vendors (Diebold, ES&S, Hart Intercivic and Sequoia).

Another benefit of open source, open standards, is also highly desirable in election administration. As you can imagine, having different types of raw vote data (encrypted or not) in proprietary formats, makes combining results from different vendors at the state level a major pain in the ass. In fact, I’ve got anecdotal evidence that the “official” canvass here in California involves a few employees of the office of the Secretary of State entering in county totals by hand into a spreadsheet precisely because there is no interoperability between data formats of our 4 vendors. Talk about an environment ripe for human error… This is why it is heartening to see IEEE standards work (IEEE 1622) and the OASIS Elections and Voter Services TC working on voting data interchange.

What are the risks of open source in e-voting?

Jason Kitcat, author and maintainer of GNU.FREE, wrote a piece for the October issue of the Communications of the ACM where he described why he had ceased to specifically advocate for open source software and had come to recognize that it only brings modest improvements at best ("Source Availability and Evoting: An Advocate Recants” Communications of The ACM October 2004/Vol. 47, No. 10, 65-67). He thesis can broadly be stated as arguing that disclosure in software does add some benefits for e-voting in terms of security and transparency, but not enough to outweigh the inherent difficulties in “creating a secure, private, reliable and anonymous system that provably records voters intentions accurately.”

There are a few risks of open-source voting that have been pointed out (some rebuttals are in italics):

  • Disclosure or withholding vulnerabilities: By having the code disclosed, attackers are free to examine the code at their leisure and exploit bugs and vulnerabilities that are not found before election day. This will never be solvable with open source code, but extensive third-party policing - like by coders with Verified Voting or another nonprofit - could go a long way towards ensuring very good code. As well, if a serious flaw is found right before an election, this might have adverse consequences on voter turnout. If the alternative is allowing a compromised election, I personally think this is a good thing.
  • Reduced competitive advantage: If vendors are required to open their source, this would mean new competitors could enter the market and “free-ride” off of the years of work that vendors have put into their software. Of course, this depends on licensing terms mandated by the regulating body. Of course, if the licensing terms, as in the Holt Bill, are merely disclosure-oriented, there’s still something called copyright folks.
  • Reduced market supply: If vendors are not allowed to keep software and interfaces proprietary, there will be reduced incentive to enter the market or create new products. I have a feeling that most of the money in election systems is in service- and maintenance-oriented contract work. Plus, vendor lock-in is always a good thing for the vendor and always a bad thing for the customer.
  • Lack of participation: (This is Kitcat’s “Transparency goes only so far” argument) E-voting isn’t very sexy and as such, will not attract talented (or any) coders to contribute. However, community source consortia-based projects like SAKAI are a better model for e-voting software development, whereby in order to be able to contribute and make changes to the application an institution has to devote a certain amount of coders and resources to the project.
  • End users compromising security: The end-users of open source e-voting software, the counties, could change the code, recompile it and implement it in very insecure ways not knowing the details of its design and the assumptions behind the model. This could be alleviated by having technicians in counties certified to make changes or requiring that no changes are made after a code-freeze date (which was properly scheduled to allow the code to be certified in time for use in the election in question). This would ensure that counties run the code through the ringer on the systems they intend to use and reconcile any bugs our vulnerabilities before the code-freeze date.

Of course, I’m sure I’ve left plenty out… please leave comments or send me an email and I’ll incorporate your arguments/suggestions (and acknowledge you in my paper, of course!).

A Quick Note on Licensing

Unfortunately, CA SoS Shelley never specified what license or what licensing terms would satisfy his “open source” mandate. Open source software licensing terms range from the complex (GPL) to the simple (modified BSD) to the just barely open source (VoteHere’s disclosed source or MS’s shared source). What’s the right license that ensures the public is allowed to vet the source on their own, that experts can debug and build the code and so that vendors still retain a leverage point around their intellectual property? For my thoughts on that, you’ll have to wait to read the full paper.

UPDATE [2004-11-07 07:43:04 PST]: Changed sentence that said Jason Kitcat now advocates for closed source. He is now an advocate for voter-verifiability. Added a note on licensing.


The URI to TrackBack this entry is: http://evoting-experts.com/wp-login.php/wp-trackback.php/wp-trackback.php/68

  1. Firstly thank you for advancing the debate concerning source availability in e-voting systems. It’s much needed.

    However I must make an important correction to your post. My CACM article at NO POINT advocates closed source e-voting software. The article was intended to indicate that open source alone is not enough for dealing with e-voting’s many challenges. I wanted to prevent OSS approaches being seen as a silver bullet.

    Personally I am opposed to e-voting’s introduction but as a realist I support voter verifiability hence I started a European Resolution on Voter Verifiability.

    Comment by Jason Kitcat — Sunday November 07, 2004 @ 7:35 am UTC

  2. VoteHere, as far as I know, has never claimed that their software is Open Source; they merely let the public examine it. If it were Open Source, the public would be free to copy and redistribute it; as far as I know VoteHere’s license does not allow that.

    Comment by Eric Hanchrow — Monday November 08, 2004 @ 5:22 pm UTC

  3. Word. However, many people (including regulators) colloquially equate “disclosed” source with being “open source"… that is, not everyone has the OSI definition (or something similar) in mind when they use the term, “open source". -Joe

    Comment by joe — Tuesday November 09, 2004 @ 6:50 pm UTC

  4. Is the open voting consortium product ready?
    How do we get a proposal for the State of North Carolina?

    Comment by Joyce — Sunday November 21, 2004 @ 5:50 pm UTC

  5. (sorry for the long post but here goes)

    Some ideas about e-voting-

    This seems to be a basic problem of software and data integrity. Established source control, encryption and checksum techniques should be adequate to handle the problems of e-voting, including internet voting.

    The main idea I have is using the combination of a unique ballot number assigned to each electronic ballot as they are completed, and a results website which allows anyone to later see ALL the ballots (by number only), including their own, so it is anonymous AND transparent. The website could show ballots by various groupings including voting precinct, or some minimum regional pool of voters which adequately insures individual anonymity but also provides some feel for how one’s neighbors voted.

    The first and probably most difficult aspect of any election is simply verifying the identity of each voter. Assuming the verification level of a drivers license, I propose (here for comment) a basic internet voting system of sending each voter a passphrase before an election. This could be physical mail or plain text email, and would contain only the voter’s name and the passphrase. The voter uses the passphrase and some other uniquely identifying information known to the state, such as drivers license number or SSN to login to an election website and start a secure session. At the end of the session a unique ballot number is assigned and a summary is presented with an option for printing. Voting is obviously only allowed once. This would not be strictly anonymous. To be strictly anonymous the voter would only provide the passphrase, which would be easier to fraud, but that fraud is detected so long as the voter votes.

    Whether using a passphrase and semi-secret number, or just a passphrase, if the voter is denied voting due to previous use, he/she would have to raise a complaint which is an indicator of fraud.

    I have a similar very simple idea to improve voting machines- each machine could provide the voter with a printed summary of his ballot, again, assigned a unique ballot number. Again the voter can later see all ballots online and identify his own using the number. If there are any differences the voter can present physical proof of an error (possibly without ID or possibly using a third party). Voting machines mean that voting machine location and approximate voting time could also be very useful for verification purposes and may not threaten anonymity. In this way, if you voted with a large group of friends or you knew some people in line with you, you could see that ballots close to yours reflect what you know or suspect. How specific the time and location are could be initially conservative and adjusted after experience.

    It would seem that using physical voting locations has advantages for identity verification and providing the voter with a physical receipt of some kind (which might also be counterfeit resistant). It does not seem that internet voting has any advantages other than convenience, and when supplementing other forms of voting, possibly increasing turnout.

    Disadvantages and weaknesses in these systems include- many voters not verifying their ballots, or no one verifying even regional votes, many deliberate fraud votes using stolen information or false ID to invalidate elections, false fraud claims to impede or invalidate elections. I don’t see how these systems could ever be worse than existing systems, however.


    Comment by John — Thursday November 25, 2004 @ 8:00 am UTC

  6. I feel computers are capable of providing the best voting system and probably the worst too. Computers run all kinds of critical systems. Good software engineering runs airplanes, satellites, and occasionally, computers, secure networks and databases. The latter can apply to e-voting.

    I would disagree that either internet voting or poll site e-voting has been completely discredited. Some very valid issues have been raised. Also, these computer scientists do not represent a consensus or conclusion of computer scientists. Many computer scientists would look forward to solving what would seem to be a straightforward task as computing problems go- e-voting. I would claim that some form of e-voting is the only voting method which could ever be proven to maintain data integrity or offer some form of anonymously verifiable result.

    The issue of anonymous ballot receipts is one that has to be balanced against election fraud. At some point the benefits of some type of verifiable ballot may outweigh the disadvantages of potential vote buying. Vote buying is currently a non-issue that can be used to justify an easily defrauded system. The question is how much of a problem vote buying or intimidation would become if receipts were offered. Vote buying might be addressed in ways such as investigation and enforcement (post-event), as it is very easy to detect and trace if done on a large scale. Also, nowhere did I suggest names be included with receipts, only ballot numbers. Ballot numbers can not be correlated to an identity, which impedes vote buying somewhat. Also, people would obviously have the option of not accepting a receipt or just remembering their ballot number, which might avert intimidation, if not buying. Another observation is that vote buying in our current political situation might involve offers from all sides, which some might cynically claim is not so different than the current system of buying votes through corporately funded campaign advertising. It is also difficult to disprove the possibility of vote buying under the current system if a poll site is corrupt enough. These are all factors which make some form of anonymous ballot receipt seem advantageous or at least equivalent to the current system.

    Ballot receipts could be intentionally made to be easily stolen or faked, which would further impede vote buying, but this would make faking complaints easier too, which can ruin the whole system. So whether to offer receipts at poll sites which are hard to duplicate or easy to duplicate is a difficult question when vote buying is considered. A brute force way to address vote buying while offering counterfeit resistant receipts might be to just give everyone several receipts showing varying selections. Only the voter knows which one is theirs, and they have multiple receipts to sell to any vote buyers, making vote buying ineffective.

    The general idea of poll site voting seems favorable because it is so much easier to verify each voter’s identity and still keep the process anonymous through the use of a pool of machines. Poll site voting offers voters in the flesh which immediately solves many identity problems. Internet identity certificates such as ordinary secure email involve complex redundant trust systems to be very reliable. They rely on a system that prevents identity fraud by making certificates difficult to obtain. A similar government run system used strictly for voting might be of use for internet voting, but it might be more complex than the current system of simply checking a voting and photo ID, whether or not that is adaquit.

    I do feel transparency is a general solution to fraud questions.


    > two things:
    > 1) Internet voting has been completely discredited by computer
    > scientists (see the attached short piece from the October 2004 CACM).
    > 2) One essential part of the puzzle that I think you are forgetting is
    > that, in addition to ballot privacy, voters should not be able to
    > prove to anyone *how* they voted (*if* they voted would be fine).
    > This is essential to ensure that there is no vote buying. Any scheme
    > that links unique ID numbers to individual ballots could be used to
    > sell votes, at least.
    > > Comment:
    > > (sorry for the long post but here goes)
    > >
    > > Some ideas about e-voting-
    > >
    > > This seems to be a basic problem of software and data integrity.
    Established source control,

    Comment by John — Wednesday December 01, 2004 @ 5:00 pm UTC

  7. I would prefer to see Open Source voting software. But it is far more
    crucial to get full disclosure, and I think the latter will be easier
    to achieve. It is already endorsed by the co-signers of the Holt
    bill. I submitted a position paper:

    Disclosure of Software for
    Voting Systems

    to the 1st Symposium on Building Trust and
    Confidence in Voting
    Systems, Dec 10-11, 2003

    which clarifies the differences, and points out how focussing on
    disclosure avoids most of the objections to Open Source that you discuss.

    So I think the law should simply require full public disclosure of
    everything necessary to build a working system. This is more or less
    like the universal practice of requiring blueprints from building
    contractors. HR2239 should be amended to make absolutely clear that
    Non-Disclosure Agreements (NDA) would not be necessary.

    But I’d advise the people that acquire the systems and run the
    elections to recognize that using Free Software has big advantages.
    One is freedom from the risk that the vendor will go out of business.

    Comment by Neal McBurnett — Tuesday February 15, 2005 @ 5:05 pm UTC

RSS feed for comments on this post.

Leave a comment

Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>



Powered by WordPress