[TriLUG] OT: OpenVote
sholton at mindspring.com
sholton at mindspring.com
Wed Jan 4 17:19:41 EST 2006
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."
More information about the TriLUG
mailing list