Re: draft of text for new OVC-sponsored bill

From: Ronald Crane <voting_at_lastland_dot_net>
Date: Sat Jan 24 2009 - 20:16:45 CST

If no one checks the hardware, then hardware "certification" is
meaningless. If someone does check the hardware -- which is necessary,
but not sufficient, for computational presentation/selection/recording
systems, and highly-recommended for computational tabulators -- then
it's much easier, much cheaper, and much more effective to do the
checking for a few kinds of hardware than for an entire class.

-R

Arthur Keller wrote:
> 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).
>

_______________________________________________
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