OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

election-services message

[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]