Re: A generic best practice document for NewMexicolegislators

From: Ken Pugh <kpughmisc_at_pughkilleen_dot_com>
Date: Tue Jan 04 2005 - 14:36:57 CST

I agree with you that they all need to be investigated. What I foresee is
that it may be very difficult to ascertain the cause. If the extra ballot
(computer or paper) matched other ballots (in each vote), then determining
which instance was not counted might be impossible. One might use the
implied order of paper ballots, but they could be in disarray.

For b.) and e.) there are "innocent explanations". There probably needs to
be compelling evidence to suggest other reasons for the
discrepancies. For h.) your explanation is less innocent.

I agree that the idea of tying ballots to registration ids is the best way
to insure that every sign-in gets their ballot counted and no stuffed
ballots are counted.


At 12:13 PM 1/4/2005, you wrote:

>On Tue, 04 Jan 2005 11:31:00 -0500, Ken Pugh <>
> >
> > Then we have the following possibilities. Which of the possibilities should
> > be considered innocent and which deserve investigation?
>I don't think any of these cases can be 100% innocent... that is,
>there is some degeneracy as you note. I'm afraid that they should all
>be investigated (save a) of course).
> > Sign-ins Computer Paper Error-rate
> >
> > a.) 1000 1000 1000 0
> > b.) 1000 1000 999 .1
> > c.) 1000 1000 1001 .1
> >
> > d.) 1000 999 1000 .1
> > e.) 1000 999 999 .1
> > f.) 1000 999 1001 .2
> >
> > g.) 1000 1001 1000 .1
> > h.) 1000 1001 1001 .1
> > i.) 1000 1001 999 .2
> >
> > a.) is the goal.
> > Possible reasons for the others:
> >
> > b.) means someone didn't drop their receipt in the box
>b.) may also mean that someone fled (the term for signing in and
>leaving before voting) and one "attacker" was able to monkey with the
>computer totals. It could also mean that their vote, for whatever
>reason, didn't make it into the box (maybe it wasn't completely
>inserted and falls out, maybe someone with access to the ballot box
>removed it) or wasn't counted in the reconciliation of the paper
>ballots (maybe it was stuck inside the ballot box).
> > e.) may mean someone walked in, registered, and didn't vote
> > h.) may mean that some voter didn't get marked as checked in
>h.) may also mean that one voter was successfully voted twice. I know
>that this implicates secret ballot / ballot privacy concerns, but does
>it makes sense to include registration data in the reconciliation
>procedure? That is, as Doug has pointed out is done in Great Britain,
>a unique identifier is issued to the voter upon registration and kept
>as a state secret... then the voter enters this unique identifier as
>the "ballot style" indicator when they approach the EVM. Granted, I
>can't see how this would work on closed-source EVMs... there would
>just be too much secrecy to convince savvy voters that the unique
>identifier wasn't being used in nefarious ways.
>There's another angle on this mentioned by a cryptographer I spoke to
>briefly here at UC Berkeley... he mentioned that voting is premised
>upon being able to go somewhere and deposit something (a record of
>your vote)... why not make voting be about taking something away?
>That is, why not have two very large pools of random numbers (cleverly
>created, of course) and when you go vote, your ballot lists (and only
>lists) the random numbers you've "taken" from each race's pool of
>numbers. Of course, the mapping between the numbers and candidates
>would be the link that needs to be kept secret by some organization
>like the EAC. You could imagine that one could go to an EAC website
>and enter one or more of their random numbers and see if their vote
>was counted (but not for whom).
>I'm babbling.
> > g.) and i.) could be a combination of b.) and h.)
> >
> > c.), d.), f.) need some explanation.
>These seem like classic ballot box stuffing of one kind or another.
> > The b.), e.) and h.) errors are the type of human errors I'm referring to.
>I think they're only human errors assuming that the computer element
>is functioning perfectly.
>Joseph Lorenzo Hall
>UC Berkeley, SIMS PhD Student
>OVC discuss mailing lists
>Send requests to subscribe or unsubscribe to

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 Sat Jan 7 22:28:56 2006

This archive was generated by hypermail 2.1.8 : Sat Jan 07 2006 - 22:28:59 CST