Re: Of re-counts, and stolen elections

From: Ron Crane <voting_at_lastland_dot_net>
Date: Tue May 17 2005 - 23:02:39 CDT

On May 17, 2005, at 8:13 PM, David Webber ((XML)) wrote:

> Folks- I've studied this closely and I must say the
> objective of the TLV approach is to deliver fair,
> unequivical, rapid and clear results. Of course
> HAVA says that's what it wants too - but so
> far has failed to show any sign of really
> intending to.....From the objective stance - random audits
> do not work. If the election is known to be
> really, really close from pre-vote polls - then
> the incentive to cheat is overwhelming.
> So - we know (see ACM Journal articles) that
> adding one vote to one machine per polling
> station can be enough to carry an election.
> No random audit is going to work here.
> Therefore the TLV approach is to have 100%
> reconciliation of all three trusted counting
> sources - electoral roll vote records, electronic
> vote records (voting computer) and verified paper ballot
> (printed and cast by voter) and then scanned for
> crosschecking.
> This allows you to do 100% crosschecking on
> election night - to ensure every paper vote has
> a corresponding electronic vote, and that the
> total of votes cast per station matches the
> electoral roll count of voters attending.
> By automating this - you can get answers
> within hours. This is also crucial - since
> legal challenges that take weeks - will fail
> to the force majeur effect of the "winner"
> having already moved in - picked out
> wallpaper and curtains and appointed
> their staff.
> Anything less than 100% automated audit
> checking is a waste of time....The only time I could see doing a small
> sample additional hand audit is if you simply
> wanted to crosscheck a precinct or so,
> just to do a post election sanity check,
> and tediously manually check the
> computer records and such to make
> sure there are no glitches.

Having briefly examined the TLV approach, I have some observations.

First, it seems to treat open source as an afterthought, and does not
discuss how to guarantee that the publicly-reviewed software makes it
into the voting machines on election day [1]. This makes the system
vulnerable to presentation frauds during vote casting, and frauds
during the comparison process. I don't see anything about random manual
spot checks on the comparison process in the official docs, either,
though you seem to think they're acceptable (though not required).

Second, it relies upon independent teams implementing various portions
of the system, and, further, those teams staying truly independent for
as long as the system is deployed. This doesn't account for the forces
of consolidation (e.g., Diebold's acquisition of Global Election
Systems), nor for the regrettable fact that vigilance wanes over time.

Third, voter verification. While this is great for transparency, I
don't think that, over the long term, it'll do much for security. Most
voters will not understand that verification is a critical element of
the entire system's security. Rather, after a brief burst of
enthusiastic verifying, they'll come to view the system itself as
"secure", and verification as optional. [2] Of course this problem
affects OVC's system to a degree as well, but less than OASIS's,
because OVC's security rests more firmly on properly-implemented open
source principles.

Fourth, I didn't see anything about hardware inspections, which makes
OASIS vulnerable to malware loaders in the casting and comparison
machines. (See the Shamos rebuttal OVC just published).


[1] E.g., David Mertz's process described in our recent Shamos paper.

[2] Further, without a useful legal process to handle actual mismatches
during verification, its effect is limited to correcting the votes of
those who happen to find such mismatches, rather than correcting the
systemic fraud that may underlie those mismatches.

OVC discuss mailing lists
Send requests to subscribe or unsubscribe to
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Tue May 31 23:17:40 2005

This archive was generated by hypermail 2.1.8 : Tue May 31 2005 - 23:17:52 CDT