Voting Project Needs Python People

[Paul Rubin]

"Alan Dechert" <adechert at earthlink.net> writes:
> > 1. Software chooses 1% of votes to change (big enough to have an
> >    effect, small enough to maybe go unnoticed).
> >
> I don't think this is a possible scenario.  However, it brings up an
> interesting test for our full blown study (keep in mind, we're trying to
> focus on getting the demo done even though people want to jump ahead to
> speculate on every possible detail).

But something like that seems to have happened in Escambia County,
Florida, in 2000.  Out of 21,500 absentee ballots cast, 296 (1.5% of
the total) were overvotes with three or more presidential candidates
checked.  ZERO were overvotes with exactly two candidates checked.
Ballot tampering after the ballots were received is the most plausible
explanation.  You said that in your system the paper ballots are
supposed to take priority over the electronic count if there is a
dispute (that's the whole point of having the paper ballots).  So it
doesn't matter if the paper and electronic results don't match, and
the tampering doesn't have to happen while the voter can still see the
ballot.

Reference:

  http://www.failureisimpossible.com/essays/escambia.htm

Note: Paul Lukasiak, the main author of that article, did some of the
most thorough analysis of the Florida debacle that I've seen.  I hope
you will read a lot of his stuff in designing your real system, so
you'll be able to say how your system deals with the problems that he
identified in Florida.