Dagstuhl Seminar "Frontiers of e-Voting"

A few weeks ago I participated in the Dagstuhl Seminar "Frontiers of e-Voting," organized by David Chaum, Miroslaw Kutylowski, Ron Rivest, and Peter Ryan.

I always enjoy my Dagstuhl visits, and this particular seminar was no exception. In fact, I found that the mix of people and personalities at this event quite refreshing, as it wasn't just a "castle" full of the same-old people who all know each other and agree. We witnessed cryptographers arguing with activist/computer scientists, political scientists drinking with theoreticians, and hacker/activists playing pool with PhD students of all ilks.

I have subscribed to several participant blogs as a result of these interactions, including those (co-)run by Michael Alvarez and Ian Brown. Already a couple of posts have caught my eye, and I'll comment upon them here in later posts.

I was asked to have a highly active role on the first day. In the morning I chaired the first session of the whole event. It focused on a summary of existing voting systems that have been constructed by attendees. The following systems were discussed: CIVS, Adder, Digishuff, Scantegrity/PunchScan, Pret a Voter, CyberVote, the Belgian Voting System, Hack-a-Vote, U.E. (used in Brazil), and KOA. Each person summarizing a system had to explain the principles of the system (i.e., why it was built), when it was created, if the project is still running, if/how the source/system are available, what license it is available under, what size and kind of team created the system and at what cost, how has the system been used in real elections, what balloting systems/style are supported (FPTP = first past the post, STV = single-transferable vote, etc.), what programming language(s) and operating system(s) were used, how scalable the system is thought to be, and what lessons were learned. I was struck by how many systems were "open source", but how few speakers actually knew if the source was really available, what license was used, and how the system was designed and built. Such does not bode well as hints of software system quality. I, of course, asked every person also how the system was specified and checked for "correctness". Where requirements gathered and analyzed? Was the system and architecture designed? Were assertions used in some way? How was the system tested? In general, the answer was always either "we make no claims that this system implements anything" or "the correctness of the software system is completely unimportant". The first of these claims is the honest one. The design and implementation of these experimental systems, without fail, have been haphazard, at best. Even one of my favorite systems, CIVS, which is implemented in a research programming language called JIF (Java + Information Flow), and uses very advanced distributed systems and cryptography constructs, contains little docs and no assertions according to one of its authors. The latter claim comes from the e-voting sub-community that focuses on end-to-end schemes. End-to-end voting systems are meant to provide very strong guarantees about a given elections integrity and voter privacy, typically by virtue of very smart algorithm design (and that's not just computational algorithms, but these systems involve people, organizations, physical artifacts like ballots, etc.) coupled with interesting cryptography. The mantra of this group is "verify the election, not the software". Unfortunately, nearly universally these system do use hardware and software to print and scan ballots, sometimes collect a voter's choices, transmit ballots, perform vote tallies, and report results. When something goes wrong, in essence, the crypto catches it, but where is the fault? At the moment, no one really knows how this auditability and culpability-management work. Furthermore, if the software and hardware is of poor quality, then the fault is likely to be found there in these relatively complex systems. So, while the mantra is "verify the election, not the software", what is actually meant is "verify the election and make sure the software is of high quality, don't just verify the software then trust the election"...a sentiment with which I completely agree.