[TriLUG] OT: OpenVote

[Tanner Lovelace]

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.

If all you used was the databases you would be correct.  However, if
the databases disagreed, you shouldn't even try to guess which one is
correct.  Instead, you fallback to using the printed version of the ballot.
>
> >...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...

This would actually be much easier in the Diebold system than
the one I was envisioning, but there are several methods to guard
against this too.  The first is that you keep a count of the number
of voters that actually vote and compare the totals to that.  If the
totals are over the count, you've got a problem.  You could even
keep a count at the little desk where they check off your name
when you come in.  This wouldn't involve a computer at all and
so wouldn't be hackable that way. (And if you have multiple people
keep count, etc... it would guard against one person skewing the
numbers too).

Secondly, you could have the voter take the printed ballot and
physically place it in a different box, just like you do now with
current optical scan machines.  Heck, even if you do place it
in an optical scan machine, that would be fine.  Have the machine
doing the votes print out the ballot in a machine readable font
and have the scan machine read it from there.  That would
save the cost of printing up ballots beforehand.

> Come to think of it, keeping counts in a database violates that
> principle, too.

True, somewhat, but as Bruce Schneier says, security is all about
tradeoffs.

[...]

> >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.

Even if most people won't be able to verify the source code, some will
and that's what counts.   The point is that anyone should have the ability
to either examine the code themselves or, if they want to, get someone
they trust to examine it for them.  Closing the source code brings no benefit
at all to the voters and to the process itself.  Instead, I maintain
that it actually
does the process harm because we are all asked to "pay no attention to
what's behind the curtain."

[...]

> >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.

Sure, I can by that.  But I don't agree that technology cannot be used at
all.

Cheers,
Tanner
--
Tanner Lovelace
clubjuggler at gmail dot com
http://wtl.wayfarer.org/
(fieldless) In fess two roundels in pale, a billet fesswise and an
increscent, all sable.