Re: draft of text for new OVC-sponsored bill

From: Arthur Keller <voting_at_kellers_dot_org>
Date: Sat Jan 24 2009 - 19:51:26 CST

Let me make the observation that Ron Crane is making valid points.
However, with the exception of his complaint about allowing the State
certification of a class of computer, none of his complaints relate
to the purpose of the legislation. The legislation allows avoidance
of Federal certification and testing procedures and replacement of
them with a California State process for open source voting systems.
Since Federal testing is weak and missed all those items found in
California Secretary of State Debra Bowen's Top-to-Bottom Review, the
legislations purpose is to say that the benefit of public access to
the software, etc., justifies the reduction in not-so-effective but
expensive testing.

Does current (Federal and State) certification processes require
specific versions of firmware or BIOS, even for the same hardware
mother board. Does current (Federal and State) certification
processes have a mechanism other than faith to ensure that the
software on DREs or other voting equipment matches the version
certified? Have their been a complete absence of cases under the
current certification regimes in which uncertified software was to be
used for elections? If the answer to any of those questions is NO,
then Ron's complaint applies equally well to current systems. So
then the question would be whether the proposed legislation makes
this problem worse without comparable benefit.

Best regards,
Arthur

At 5:11 PM -0800 1/24/09, Ronald Crane wrote:
>David Mertz wrote:
>>>>Also, as Jim March observed, voters' errors on hand-filled paper
>>>>ballots will be random and will lack a partisan bias (unless the
>>>>ballot is very badly designed). In contrast, an attack on ballot
>>>>printers will (by definition) have a partisan bias.
>>
>>The badly designed paper is a REALLY BIG caveat. Doesn't anyone
>>remember Florida in 2000 anymore? Or a thousand other jurisdictions
>>with less publicized design errors in paper ballots.
>The same thing can occur (and has occurred) with e-voting equipment.
>On Florida, in 2006 the CD 13 (Sarasota) race (run on DREs)
>experienced a huge (13%) undervote, which quite possibly flipped the
>result. Officials attributed it to an incorrect race heading, made
>in error (?)
>http://www.heraldtribune.com/apps/pbcs.dll/article?AID=/20061115/NEWS/611150751
>. There is no reason that a presentation attack on race headings
>could not produce a similar effect.
>
>The thing is, hand-filled paper ballots can (and should!) be audited
>before the election to detect errors and attacks, and once checked,
>do not change themselves (though chain of custody is still important
>to prevent later attacks). Ballot printers, DREs, etc., are not
>anywhere near as amenable to effective audits, and their outputs are
>mutable.
>>
>>Also, an error in a ballot printer is not *by definition* partisan.
>>Sure, it could be, even if the error was initially careless rather
>>than malicious. E.g. a calibration error skews votes towards the
>>candidate listed lower on the screen. On the other hand, if this
>>same possible error was on a system with randomized candidate
>>order, the error wouldn't favor any particular candidate or party
>>(since any one of them would be equally likely to occur at the
>>bottom of the list). The real answer is "it depends".
>>
>Good point. But a presentation attack is, by definition, partisan.
>Detection (and recovery) are relatively easy, straightforward, and
>effective for hand-filled paper ballots, and much less so on all
>points for ballot printers.
>>>This essay ignores the effects of DoS attacks, presentation
>>>attacks, selection attacks,
>>
>>We've had plenty of DoS attacks on all-paper ballot precincts! Some
>>of them right here in LA county in 2008! I think Arthur has written
>>well of something similar when he was an election judge, and
>>inadequate numbers of paper ballots were provided to his precinct.
>>
>>A DoS attack need not be planned with sophisticated software that
>>counts voting history per machine. You pretty much know voting
>>patterns by precinct, and causing long lines among "undesirable"
>>voters is an old and nasty trick that isn't particularly dependent
>>on polling-place technology.
>Computerized DoS is not as easily detectable -- nor nearly as easy
>to fix -- as that involving hand-filled paper ballots. Let's say an
>average voting session takes 5 minutes without DoS, and lines are
>acceptable. A crafty attacker might add 30 seconds to per-voter
>reinitialization, 15 seconds to printing, and 30 seconds (total) to
>page flips, lengthening the average voting time by 25%, and
>potentially lengthening lines a great deal (gotta run my queueing
>model to say how much). Or she might do that, and then make one of
>the (say, 4) machines "fail". Recovery is unlikely unless officials
>break out the hand-filled paper ballots, or an astute lawyer gets a
>court order extending closing time, pronto (though the latter isn't
>nearly as useful, since many voters will just leave if the line's
>too long).

-- 
-------------------------------------------------------------------------------
Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA  94303-4507
tel +1(650)424-0202, fax +1(650)424-0424
_______________________________________________
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:51 2010

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