It’s a curious problem: how do you compare two completely unrelated voting systems and say that one is more or less secure than the other?  How can you meaningfully compare the security of paper ballots tabulated by optical scan systems with DRE systems (with or without VVPAT attachments)?

There’s a clear disconnect on this issue.  It shows up, among other places, in a recent blog post by political scientist Thad Hall:

The point here is that, when we think about paper ballots and absentee voting, we do not typically think about or evaluate them “naked” but within an implementation context yet we think nothing of evaluating e-voting “naked” and some almost think it “cheating” to think about e-voting security within the context of implementation.  However, if we held both systems to the same standard, the people in California probably would not be voting using any voting system; given its long history, it is inconceivable that paper ballots would fail to meet the standards to which e-voting is held, absent evaluating its implementation context.

Hall then goes on to point to his recent book with Mike Alvarez, Electronic Elections, that beats on this particular issue at some length.  What that book never offers, however, is a decent comparison between electronic voting and anything else.

I’ve been thinking about this issue for a while: there must be a decent, quantitative way to compare these things.  Turns out, we can leverage a foundational technique from computer science theory: complexity analysis.  CS theory is all about analyzing the “big-O” complexity of various algorithms.  Can we analyze this same complexity for voting systems’ security flaws?

I took a crack at the problem for a forthcoming journal paper.  I classified a wide variety of voting systems according to how much effort you need to do to influence all the votes: effort proportional to the total number of voters, effort proportional to the number of precincts, or constant effort; less effort implies less security.  I also broke this down by different kinds of attacks: integrity attacks that try to change votes in a stealthy fashion, confidentiality attacks that try to learn how specific voters cast their votes, and denial of service attacks that don’t care about stealth but want to smash parts of the election.  This was a fun paper to write, and it nicely responds to Hall and Alvarez’s criticisms.  Have a look.

(Joe Hall also responded to Thad Hall’s post.)

Barbara Simons, an accomplished computer scientist and e-voting expert, was recently appointed to the Election Assistance Commission (EAC) Board of Advisors. (The EAC is the U.S. Federal body responsible for voting technology standards, among other things.) This is good news.

The board has thirty-seven members, of which four positions are allocated for “members representing professionals in the field of science and technology”. These four positions are to be appointed by Majority and Minority leaders in the House and the Senate. (See page 2 of the Board’s charter.) Given the importance of voting technology issues to the EAC, it does seem like a good idea to reserve 10% of the advisory board positions for technologists. If anything, the number of technologist seats should be larger.

Barbara was appointed to the board position by the Senate Majority Leader, Harry Reid. Kudos to Senator Reid for appointing a genuine voting technology expert.

What about the other three seats for “professionals in the field of science and technology?” Sadly, the board’s membership list shows that these seats are not actually held by technical people. Barbara Arnwine holds the House Speaker’s seat, Tom Fuentes holds the House Minority Leader’s seat, and Wesley R. Kliner, Jr. holds the Senate Minority Leader’s seat. All three appear to be accomplished people who have something to offer on the board. But as far as I can tell they are not “professionals in the field of science and technology”, so their appropriate positions on the board would be somewhere in the other thirty-three seats.

What can be done? I wouldn’t go so far as to kick any current members off the board, even if that were possible. But when vacancies do become available, they should be filled by scientists or technologists, as dictated by the charter’s requirement of having four such people on the board.

The EAC is struggling with voting technology issues. They could surely use the advice of three more expert technologists.

Back when we were putting together the grant proposal for ACCURATE, one of the questions that we asked ourselves, and which the NSF people asked us as well, was whether we would produce a “bright shiny object,” which is to say whether or not we would produce a functional voting machine that could ostensibly be put to use in a real election.  Our decision at the time, and it was certainly the correct decision, is that we would focus on innovating in the technology under the covers of a voting system, and we might produce, at most “research prototypes”.  The difference between a research prototype and a genuine, commercial system are typically quite substantial, in general, and it would be no different here with voting system prototypes.

At Rice we built a fairly substantial prototype that we call “VoteBox”; you can read more about it in a paper that will appear on Friday at Usenix Security.  To grossly summarize, our prototype feels a lot like a normal DRE voting system, but uses some nice cryptographic machinery to ensure that you don’t have to trust that the code is correct.  You can verify the correctness of a machine, on the fly, while the election is ongoing.  Our prototype is missing a couple features that you’d want from a commercial system, like write-in voting, but it’s far enough along that it’s been used in several human-factors experiments (CHI’08, Everett’07).

This summer, our mission is to get this thing shipped as some sort of “open source” project.  Now we have several goals in this:

• Allow other researchers to benefit from our infrastructure as a platform to do their own research.
• Inspire commercial voting system vendors to build better products (i.e., solving the hard design problems for them, to reduce their cost for adopting innovative techniques).
• Allow commercial voting system vendors to build on our source code, itself.

All well and good.  Now the question is how we should actually license the thing.  There are many, many different models under which we could proceed:

• Closed source + patents + licenses.  This may or may not yield revenues for our university, and may or may not be attractive to vendors.  It’s clearly unattractive to other researchers, and would limit uptake of our system in places where we might not even think to look, such as outside the U.S.
• Open source + a “not for commercial use” license.  This makes it a little easier for other researchers to pick up and modify the software although ownership issues could get tricky.
• Open source with a “BSD”-style license. A BSD-style license effectively says “do whatever you want, just give us credit for our work and you’re on your own if it doesn’t work.”   This sort of license tends to maximize the ease with which companies can adopt your work.
• Open source with a “GPL”-style license.  The GPL has an interesting property for the voting system world: it makes any derivatives of the source code as open as the original code (unless a vendor reimplements it from scratch).  This sort of openness is something we want to encourage in voting system vendors, but it might reduce vendor willingness to use the codebase.
• Open source with a “publication required” license.  Joe Hall suggested this as another option.  Like a BSD license, anybody can use it in a product, but the company would be compelled to publish the source code, like a book.  Unlike GPL, they would not be required to give up copyright or allow any downstream use of their code.

I did a quick survey of several open source voting systems.  Most are distributed under the GPL:

• Adder
  
• eVACS (old version is GPL; new version is proprietary)
• Helios (code not yet released; most likely GPL according to Ben Adida)
• OVC (GPL with extensions to require change histories be maintained)
• Pvote

Civitas is distributed under a non-commercial-use only license.  VoteHere, at one point, opened its code for independent evaluation (but not reuse), but I can’t find it any more.  It was probably a variant on the non-commercial-use only theme.  Punchscan is distributed under a BSD-style license.

My question to the peanut gallery: what sort of license would you select for a bright, shiny new voting system project and why?

[Extra food for thought: The GPLv3 would have some interesting interactions with voting systems.  For starters, there’s a question of who, exactly, a “user” might be.  Is that the county clerk whose office bought it, or the person who ultimately votes on it?  Also, you have section 3, which forbids any attempt to limit reverse-engineering or “circumvention” of the product.  I suppose that means that garden-variety tampering with a voting machine would still violate various laws, but the vendor couldn’t sue you for it.  Perhaps more interesting is section 6, which talks about how source code must be made available when you ship compiled software.  A vendor could perhaps give the source code only to its “customers” without giving it to everybody (again, depending on who a “user” is).  Of course, any such customer is free under the GPL to redistribute the code to anybody else.  Voting vendors may be most scared away by section 11, which talks about compulsory patent licensing (depending, of course, on the particulars of their patent portfolios).]