Re: draft of text for new OVC-sponsored bill

From: Ronald Crane <voting_at_lastland_dot_net>
Date: Sat Jan 24 2009 - 00:30:06 CST

cls wrote:
> ...We should take the *belief in* HCPB
> seriously and have a more convincing way of satisfying the
> real or imagined needs that HCPB are supposed to satisfy.
> Software independence does that. "Trust my software, it's better"
> doesn't.
>
"Software independence", as commonly-defined, does not do this. As
defined in the 11/2006 NIST report at
http://vote.nist.gov/DraftWhitePaperOnSIinVVSG2007-20061120.pdf , the
core of "software independence" is the production of some record of her
selections that the voter can examine and validate "independently" of
the software contained in the machine. The report goes on to note that
DREs with VVPAT ("paper trails") are "software independent" (top of p.3).

This definition of "software independence" concentrates on the
opportunity for the voter to verify a cast ballot. This focus misses a
variety of important shortcomings and attack vectors. First, as
exemplified by the Selker experiment cited in the Brennan Center voting
system security report, voters tend to "verify" quite poorly. Second,
and more importantly, the software is responsible for many interactions
with the voter before the ballot is ever cast. As I have discussed
recently on this list, this opens the possibility of (at least):

1. DoS attacks (which can be selective; e.g., lockup if too many people
are voting for the "wrong" candidate; lockup if the voting rate is high,
so as to maximize line lengths and attendant vote loss);
2. Presentation attacks (e.g., dropping candidates from the ballot,
rearranging it, mucking with the headings...) and selection attacks
(modulating the ease of selecting candidates); and
3. Social engineering attacks (e.g., getting voters to use an incorrect
procedure; this a choice attack against "E2E" machines, whose security
guarantees hold only if voters execute unfamiliar and unintuitive
protocols perfectly).

HCPB can take a long time, even an impractically long time for long
ballots. I think it's reasonable to use computational tabulators to
count hand-filled paper ballots. With statistically-supported hand
audits, such a system can be truly "software independent", in that we
can determine whether the software (in the tabulators) is doing the
right thing using a method (sampling hand audits) that does not rely
upon the software.

I also think it's reasonable to use OVC-style ballot printers to assist
voters who cannot otherwise vote independently -- assuming that they're
really useful for that task. Such voters get a significant benefit to go
along with the risk that, e.g., the firmware in the machine is
programmed to cheat. Not so, I contend, for the general voting population.

I expect that many HCPB advocates can be convinced to accept the use of
properly-audited computational tabulators to count hand-filled paper
ballots, and that they'd be even happier if those tabulators used as
much open-source software/firmware as possible. But I don't think you're
going to win many such people over to the ballot-printers-for-all
position, since, at base, it's still a trust-the-software and
trust-the-experts paradigm.

-R

_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
By sending email to the OVC-discuss list, you thereby agree to release the content of your posts to the Public Domain--with the exception of copyrighted material quoted according to fair use, including publicly archiving at http://gnosis.python-hosting.com/voting-project/
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Thu Jan 7 00:09:50 2010

This archive was generated by hypermail 2.1.8 : Thu Jan 07 2010 - 00:09:57 CST