[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [election-services] Draft position paper for EAC/NIST UOCAVA workshop
On Tue, Jul 13, 2010 at 4:01 PM, David RR Webber (XML) <david@drrw.info> wrote: > Then there is the fact that NIST with their VVSG SI have de facto required > paper as the single foolproof means to ensure that is met currently. So the > conclusion is that paper is the preferred dual path mechanism today - that > is simple and clear for legislators to comprehend and is also easiest for > existing election boards to handle and is the common usage today. I must say here that I'm probably in a bit of agreement and disagreement with both Peter and David. If you know me, you know that I feel that a voting system is not materially auditable without some sort of end-to-end software-independent audit mechanism. (Accountants and auditors distinguish "materiality" audits and "process" audits, respectively, as audits designed to check correctness vs. audits designed to confirm proper procedure was followed.) Process audits are still, of course, possible, but they cannot give you consistent insight into whether or not error introduced by machine interpretation of voter-made marks would have caused a change in the results. The software independence (SI) proposal from NIST was only proposed for VVSG II and hasn't been furthered by EAC (the body in the US that actually adopts the national standards). So, that may never become part of the VVSG (it wasn't included in the recent VVSG v1.1 draft). And while cryptographic solutions can likely be SI, there is still a good deal of work to do for those techniques to be used widely (note that the Scantegrity II team here in the US deployed their system in a recent Maryland election). So, I'm a firm believer that to be able to do real audits -- risk-limiting audits that bound the chances of an incorrect outcome due to errors [1] -- some physical artifact must exist that the voter has an opportunity to verify before they cast their ballot. As a number of recent papers have made clear (see [1], but I can point to more), the single most beneficial step to better auditability for existing systems would be if vendor VTS and EMS systems could output structured vote results, at least for each polling place and hopefully for each unit of technology (DRE, opscan, PEB, BMD, etc.) and, more hopefully, in such a way that permits single-ballot risk-limiting audits [2], perhaps the holy grail of the post-election auditing enterprise. The types of systems that are on the drawing boards now for what is increasingly called "remote voting" have severe requirements for data management and standardization. For example, using a remote-kiosk model (with a courier-returned VVPAT or not), a few hundred voters might vote on it from dozens of separate jurisdictions with distinct ballot styles. The voter will need to identify itself sufficiently for the kiosk to know what ballot style to display (or retrieve from a server), grab that ballot style, mediate interaction with the voter, and then return the equivalent of a Cast Vote Record (CVR) to some middle-party that then coordinates delivery of CVRs and VVPATs (if applicable). So, the need for very robust data plumbing shouldn't be underestimated for UOCAVA applications. This is, of course, before getting to the very serious security issues involved in general with models for remote voting (in security circles, it's hard to estimate how much adding users' PCs and the public internet increases the "attack surface"). I'll shut up now and plan on looking at David's doc... best, Joe [1] http://josephhall.org/papers/rla_evt09.pdf [2] http://www.stat.berkeley.edu/~stark/Preprints/superSimple10.pdf -- Joseph Lorenzo Hall ACCURATE Postdoctoral Research Associate UC Berkeley School of Information Princeton Center for Information Technology Policy http://josephhall.org/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]