Re: EAC vol2 - testing - Page 55 - section 3.3.1

From: Edmund R. Kennedy <ekennedyx_at_yahoo_dot_com>
Date: Wed Jun 29 2005 - 11:26:29 CDT

Hello David:

Yes, very odd numbers indeed. Do you think this might
be related to 'free memory', hard drive size or some
other sort of hardware driven specification inserted
by the vendors?

It sounds like they need four basic classes of
testing:

1. Hardware (which they are sort of addressing per
your comments). Also, they should use the standards
for that Robert Moog specified for his synthesizers--
A. Leave on overnight and see if it's still working
in the morning. Then do the same thing over the
weekend.
B. Drop on floor from normal table hieght. See if it
is still working.
2. Software (line by line, "What's this for?") and OS
interaction and tricks.
3. The ol' standby, input data and check the output.
4. Human factors testing especially for the disabled.
 
5. TBD but could include interaction with other
hardware in the system and/or hack attack with
publicity--say by students from UC Berkeley or MIT.

Thanks, Ed Kennedy

--- "David Webber (XML)" <david@drrw.info> wrote:

> 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
> metrics.
>
> 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! 4.7.1.1 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.
>
> DW
>
>
> _______________________________________________
> OVC discuss mailing lists
> Send requests to subscribe or unsubscribe to
> arthur@openvotingconsortium.org
>

-- 
10777 Bendigo Cove
San Diego, CA 92126-2510
858-578-8842
Work for the common good.
My profile:  <http://geocities.com/ekennedyx/>
I blog now and then at:  <http://ekennedyx.blogspot.com/>
_______________________________________________
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