[TriLUG] OT: OpenVote

Greg Brown gwbrown1 at gmail.com
Thu Jan 5 08:32:58 EST 2006


This is horribly overcomplicated.

I might not agree with dual databases, but I could be swayed on that
point, but I do agree with double-entry.

Voting machine enters the vote into the database.  The ballot is
printed out and along with the human readable names (and perhaps
corresponding bar codes of the names) as is the coded primary key
matching the entry in the database along with other data that would
allow the ballot to be matched up with the machine and time the ballot
was entered (say the epoch time of the vote and serial number of the
machine).  Perhaps a way around the barcoded names would be a
formatted page where Xs are placed, or an entire area of the ballot
shaded out, to match the location of a name.  That way the ballot is
readable by humans and is not bar-coded by location coded to match a
name.

In this way we have a true double-entry system where both the
electronic data and ballot should correspond and if for some reason
the votes between one machine and the ballots do not correspond that
machine can be taken off-line.

I absolutely disagree with allowing people to download PDFs over the
Internet to fill out.  There is far, far too many things that can go
wrong there.   A hanging chad?  That's nothing compared to people
bringing in votes that are on non-standard paper, etc.  Also allowing
people to print out ballots ahead of time practically allows a union,
church, or "legitimate family business" to pre-print ballots to hand
out ahead a time (and force people to submit through various means).

Greg

On 1/4/06, sholton at mindspring.com <sholton at mindspring.com> wrote:
> Tanner Lovelace <clubjuggler at gmail.com> writes:
> >My thoughts have been along the line of having a program write votes to
> >both mysql and postgresql databases...
>
> There's an old Chineese proverb which goes:
> "A man with two watches never knows what time it is."
>
> If the two databases disagree, you would know (at least) one is wrong
> but wouldn't be any closer to knowing the correct count.
>
> >...extremely bad design in the verifiable receipt (generally paper rolls which
> >are behind glass so the voter can't disturb them...
>
> This violates the principle of the observable ballot box. What if the
> machine correctly records each vote until the curtain is opened,
> then prints up a few for Candidate A while no one is looking...
>
> Come to think of it, keeping counts in a database violates that
> principle, too.
>
> If we seperate the job of /recording voter intent/ from the job
> of /tabulating the results/, things become (IMHO) much simpler.
>
> Have one box to offer the fancy graphics, multi-language, intelligent
> race selection, audio interface, etc, and producing in the end an
> unambiguously marked ballot for one candidate (or one initiative).
>
> A second (cardboard) box holds the results for tabulation. Nothing more.
>
> Coding errors (intentional or otherwise), hardware failures, technology-
> challenged individuals, cosmic ray bit discharge, unexplained gremlins
> or any other phenomenon which cause the first box to fail to produce
> a ballot marked in the way the voter wanted result in a spoiled ballot
> in the shredder. Boxes which repeatedly fail to produce a voter-satisfying
> ballot get pulled from production.
>
> You could, taken to extremes, give people a token as their identity
> is validated and allow them to generate multiple ballots for different
> candidates. Thus a blind person could print both a 'Candidate A'
> ballot and a "Candidate B" ballot, ask several visually unimpaired people
> to confirm that the ballot in their right hand is indeed a ballot for
> Candidate A and the one in their left for Candidate B, and then
> submit their selection to the ballot box (along with their token) and
> the rest to the shredder.
>
> Heck. Make the ballots available as PDF's over the Internet and
> let people print out their own.
>
> Such a protocol works no matter what physical impairments the
> voter may have or how thoroughly the developer thought things
> out.
>
> The tabulator box should read the ballot directly, /not/ an encoded
> version of the ballot, in case the printed ballot says "Candidate A"
> in large print and <candidate b> in the barcode. This only fails if
> the identity of the two candidates is so close that a computer can't
> distinguish a difference between them on a ballot specifically
> designed to allow this. (No jokes here, please.)
>
> >Finally, all the code should be open.  Perferably open source/free software,
> >but I think at a minimum it should be easily independently auditable.
>
> Not helpful. There's no way for most people to verify source code
> does what it says anyway, no way to ensure that the compiler, loader,
> hardware, etc hasn't been compromised, and no way to verify that
> what's running in the system is the same as what was reviewed
> beforehand.
>
> And, it's irrelevant. A system like the above wouldn't require it. You could
> even allow people to write their own software (or use Photoshop) to
> print up their own ballot and as long as you can verify that only one
> ballot goes into the box the integrity of the election is maintained.
>
> (Practically, you wouldn't. If you did that, there would be pressure
> for polling places to have a 3rd box: an interpreter to allow people
> to verify that the ballot they created at home would be /interpreted/
> the way they intend for it to be interpreted, but that introduces
> issues of calibration, another point of failure, etc, etc, etc.....
>
> In short, a second watch.)
>
> >Does anyone else have any other suggestions for the design of a good voting
> >machine?
>
> Protocol is more important than technology. Easier to verify correct
> implementation.
>
>
> --
> Steve Holton
> sholton at mindspring.com
> "Convenience causes blindness. Think about it."
>
> --
> TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ  : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
>



More information about the TriLUG mailing list