[TriLUG] OT: OpenVote

[Cristobal Palmer]

Fantastic points, but I disagree in that I think what you've described
could be implemented in an open source fashion. That is, _we_ could
design the entire system.

The weak point of the system you describe is the tabulator, which,
incidentally, is exactly what was flawed in the Diebold system. It was
an optical scan system. I think there's no question but that an open
source implementation there is not only feasable but very desirable.

"Given enough eyeballs, all bugs are shallow." --ES. Raymond

I think we can restate that here, since what's important is that we
get eyeballs of all political stripes, leanings, persuasions, etc.
You're right that _most_ people aren't going to know what to look for
in the source code, but that's hardly necessary if what you're talking
about is the software that runs the tabulator. Also, there has to be a
way to provide assurance of the version of the software used in the
tabulator. How are you going to trust _any_ kind of automated
tabulator if you don't know what it's running?

Besides, Security through Obscurity is a _joke_, and definitely not
one we should be telling around election day. Instead we should take
the spectacular failures on the part of Diebold and its underlying
proprietary core as a challenge to come up with an alternative. Why
couldn't we, an open source community, come up with a viable design?
An open-source 2006 election wouldn't happen, but 2007 would be
doable, and since it's the counties that do the buying, it wouldn't
have to be everywhere. If we got a system working and demonstrably
secure, other counties would likely switch down the road.

What about cost? Tanner, were you picturing an off-the-shelf USB
inkjet hooked up to some kind of tablet at each voting station? Is
there an existing device that would work as the tablet? What about a
modified thin client box? How much does each Diebold voting station
cost? What about optical-scan voting tabulators from companies like
Diebold?

-CMP

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


--

Cristobal M. Palmer
UNC-CH SILS Student
cristobalpalmer at gmail.com
cmpalmer at ils.unc.edu
ils.unc.edu/~cmpalmer
"Television-free since 2003"