EAC vol2 - testing - Page 55 - section 3.3.1

From: David Webber \(XML\) <"David>
Date: Wed Jun 29 2005 - 11:09:17 CDT

The overall sense I have is that the testing is a barn-door
and any number of trucks can be driven through this.

Page 55 however does attempt to provide some tighter

There just is no systematic approach here to detect
common attacks and detect ballot score manipulations.

Again - without insisting on stanadrd information formats
its very hard to know if the deveice should be doing
what it is doing or not.

This makes these EAC test procedures completely at
risk, all the time, IMHO.

The error rates of 1 in 10,000,000 appear to be for the
hardware - and not the software! page 71 - but
again - they offer no clue as to how this should be actually
tested in practice. Clearly you cannot sit at a DRE and
manually key in 10,000,000 votes - so how do you test
this?!? Section C page 125 offers some insights as to
where these numbers come from.

Page 72 offers even stranger notes:-
    a.. If the system makes one error before counting 26,997 consecutive
ballot positions correctly, it will be rejected. The vendor is then required
to improve the system.

    b.. ? If the system reads at least 1,549,703 consecutive ballot
positions correctly, it will be accepted.

    c.. ? If the system correctly reads more than 26,997 ballot positions
but less than 1,549,703 when the first error occurs, the testing will have
to be continued until another 1,576,701 consecutive ballot positions are
counted without error (a total of 3,126,404 with one error).
And then they are taking the vendors word that COTS packages are
un-modified. Super!! How nice.

Section 5.4.2 is best described as quaint.

Overall - I think this shows that really robust testing designed
to detect voting manipulation - let alone simple accurate
operation is devilishly difficult to specify.

Yet more evidence why you need a trusted logic process in
the first place - so you can mandate and test for specific
behaviours - and break the whole down into descreet parts
and test the separations and interfaces between the parts
and not necessarily the parts themselves. It's the outcomes
that are vital. Obviously you also need to ensure that
proprer presentation is made to the voter too - but overly
focusing on the mechanics can blind you to the real outcomes.


OVC discuss mailing lists
Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Thu Jun 30 23:17:10 2005

This archive was generated by hypermail 2.1.8 : Thu Jun 30 2005 - 23:17:11 CDT