Date: Sun, 14 May 2006 22:44:30 -0500 From: To: Subject: EVT '06 Dear author, I'm pleased to say that your paper has been accepted for publication in the Usenix/Accurate Electronic Voting Workshop. This message contains your reviews. Please address the reviewers' comments and produce your final draft by June 14 (one month from now), then send a PDF to via email. The Electronic Voting Workshop will be held in Vancouver, B.C., Canada, on Tuesday, August 1, 2006, in the same hotel as the Usenix Security Symposium, for which you may (or may not) also choose to attend. All the necessary registration details will be sent to you soon. If you've got any other questions, be sure to let me know. Thanks, Dan P.S. You may also be interested in WOTE (which is also related to electronic voting but is unrelated to EVT). More information here: http://www.win.tue.nl/~berry/wote2006/ Title: Prerendered User Interfaces for Higher-Assurance Electronic Voting Authors: Ka-Ping Yee I really enjoyed this paper. You described and justified a convincing design, and then actually built it. There were a handful of open questions that are probably worth discussing: - Supporting multiple precincts on a single machine. In early voting, this is quite common. There needs to be a clean, simple technique for indicating to the machine which precinct it's being used to display. Section 5.1 gives some hints, but this could stand to be more fully fleshed out. - Voter introduction / other procedures. How do you "introduce" a voter to the machine? Do you want to use a smartcard approach, like Diebold, or a network approach, as with Hart InterCivic, or something else? You obviously need logic like this to make sure a voter cannot cast multiple votes. Likewise, you need logic to open and close the polls as well as to collect and tabulate the votes. Section 6.3 hints at some of this ("administrative functions"), but this needs to be more fully fleshed out as well. - The vote storage file (section 5.2) is going to generate a non-trivial amount of garbage, since you have to potentially rewrite the entire file each time you insert into the list. That means O(N^2) garbage. Since you're planning to write SHA-1 hashes as part of each vote, the cost is going to add up quickly. Assuming your machine receives a reasonable number of votes during the election day, how big a PROM do you need? AVM lever machines could handle 999 votes. What about your machine? - Cutting the votes into "strips" has some nice anonymity properties, but it may not satisfy various state laws that require DRE systems to produce "ballot images" on demand. You have a legitimate argument that such an ability should not be present, but it may require changes to state laws in order to get the machine used. You should mention this issue and, if possible, discuss alternative solutions. Conversely, many of the software engineering particulars in section 4 are less exciting and could be reduced in this paper to make space. A longer technical report would give you the space to go beyond this, including code snippets to better explain your implementation. ======================================================================= This is an interesting idea and a nice piece of technology. I do have some questions, though, for example about the flexibility of the system in handling straight-ticket voting, or more complex issues like approval or rank-order voting. I also wonder about language support for write-ins; supporting input for languages like Chinese may not be quite so simple. Finally, there's the issue of navigation--this appears to support only one model for navigating the ballot and it's not clear whether that method is best. In general, many of these are probably surmountable issues, but they do merit consideration. Still, an interesting piece of technology which should generate good discussion at the workshop. ======================================================================= We need an audio analog for the term "prerendered" as it applies to images. Also, pre-rendering applies to Braille, you don't send lines of text to a Braille display, you send bitmaps, so that the rendering into Braille is an off-line process and therefore removed from the trusted base of the system. (I say this having helped build a Braille printer, that Braille rendering code was nasty because of the option to compress the text by using standard abbreviations for common words, dipthongs and other quirks). The basic idea of prerendering is already in use, in the ES&S iVotronic, where the compact flash card contains prerendered images of every screenful presented by the machine. There was a public discussion of this issue in Miami in 2004. See page 11 of: Recommendations for the Conduct of Elections in Miami-Dade County using the ES&S iVotronic System, Douglas W. Jones, on the web at: http://www.cs.uiowa.edu/~jones/voting/miami.pdf Bitmap ballots on the iVotronic are simpler than the pre-rendered scheme proposed in this paper, though, since they have no sprites. Still, they are an important precident. Also, the report cited above points out, telegraphically, the security advantages of prerendering. There is precedent for "tearing the ballot into strips" as this paper suggests, as a way to protect the right to a secret ballot against voter's who try to sign their ballot with, for example, a write-in vote for a predesignated fictional candidate. I have seen a Swiss ballot (I think from Geneva) that was printed on perforated cardstock so that, before hand counting, it could be separated by race. Manual ballot processing begins by breaking the ballots along the perforations, and then continues by stacking the pieces for each race into piles by who the votes were cast for. It is worth noting that cutting the ballot into strips is a violation of state law in many states, where the ballot is required to be recorded intact. At the same time, however, failing to do so allows voters to disclose their votes, for example, using a write-in vote for a pre-arranged fictitious person as a ballot signature. In states where the right to a secret ballot is consitutional and where the ballot image requirement is just statuatory, therefore, it is fair to argue that the ballot image requirement is unconstitutional. Whether or not this argument goes into the paper, it is the right comeback to propose when someone raises the issue of the illegality of cutting into strips. Overall, however, the key ideas of this paper are extremely valuable -- it's all about reducing the size of the trusted base on which the voting system rests. That phrase is one that might be worth using in the paper. Others commenting on this paper have noted that voting involves an endliss list of mundane practical considerations. Long ago, Shamos noted (I believe it was at the Rutgers workshop) that voting was no more than 1+1+1+1+1+1... except for all of these consideraitons. One of these mundane considerations involves "straight-ticket plus exceptions" voting, a feature required in many states. This can be surmounted (for example, by projecting the straight ticket votes into every race before cutting the ballot into strips). This is just a detail, one of a huge number that may not make it into the paper because of space constraints. ======================================================================= A bold attempt to "cut the complexity knot" in an interesting way, by having a very simple virtual machine drive the user interface, from pre-compiled ballots. This has a good chance of being shot down for one reason or another, or being pushed too far from its purist inspiration by an endless list of mundane practical considerations, but the ideal is very interesting and will certainly cause some interesting discussion. You could compare with the "frog voting" proposal of the July 2001 CalTech/MIT report, where the essential core of the voting system was viewed as being just the vote confirmation step; here you've now also got the vote composition included, which is nice. ======================================================================= simple voting machines will have less bugs, this is a nice demonstration. Wintergreen voting products claim to be voting machines that use the small code approach. Evaluating any ballot sufficiently to make sure it is not coercive as some have been in the past is important. ======================================================================= None =======================================================================