OpenVote (was Re: [TriLUG] OT: www.hexblog.com - a fix for the WMF vulernability.)

[Rick DeNatale]

On 1/4/06, Tanner Lovelace <clubjuggler at gmail.com> wrote:
> On 1/4/06, Greg Brown <gwbrown1 at gmail.com> wrote:
> > Must have been about a year go that I blogged about getting a group of
> > luggers together to from "OpenVote" (or was it eVote?), a
> > not-for-profit venture to create a multi-language touch-screen
> > open-source voting system that would write votes to a central database
> > but also print out encrypted bar code paper ballot that could would be
> > scanned in as a double-entry right after the ballot was printed that
> > could also be tabulated later in case of a re-count.
>
> I believe the law about recounts says it has to be a "manual recount".
> A bar code reader is just another form of "optical scan" and is therefore
> not eligible for a recount.

The recount laws are state laws.
http://moritzlaw.osu.edu/electionlaw/ebook/part5/procedures_recount07.html

Florida treats manual recounts as a last resort, remember that the
main debacle in 2000 was the sight of officials manually recounting
punch card ballots. That was the impetus towards "better" electronic
voting machines, not so much to make the count more accurate, but to
make it appear so.

North Carolina law on recounts says

(d)       Rules for Conducting Recounts. – The State Board of
Elections shall promulgate rules for conducting recounts. Those rules
shall be subject to
the following guidelines:

(1)       The rules shall specify, with respect to each type of voting
system, when and to what extent the recount shall consist of machine
recounts and hand‑to‑eye recounts.

(2)       The rules shall provide guidance in interpretation of the
voter's choice.

(3)       The rules shall specify how the goals of multipartisan
participation, opportunity for public observation, and good order
shall be balanced. (2001‑398, s. 3; 2003‑278, ss. 10(b), 10(c).)

> I've actually been wondering just what it would take to create a working,
> verifiable, good "direct record entry" (DRE) voting system.  All the current
> ones, which are the touchscreen machines, have problems.  It seems to me,
> however, that, this isn't a surmountable problem.  Here's a short list of
> requirements:



>
> 1. Accuracy (Duh!)
> 2. Repeatibility
> 2. Repeatibility  :-)
> 3. Robustness
> 4. Verifiable
> 5. Easy to use (for poll workers on election day)
> 6. Tamper resistant
>
> My thoughts have been along the line of having a program write votes to
> both mysql and postgresql databases at the same time and use off the
> shelf deskjet printers that use regular 8.5x11 paper to create a paper trail.
> Current DREs suffer from bad security on the database (Diebold uses
> Access databases which can be manipulated directly in access!!!) and
> extremely bad design in the verifiable receipt (generally paper rolls which
> are behind glass so the voter can't disturb them, but since the vote must
> be secret it means half the roll doesn't get used and that limits the number
> of voters each machine can serve before needing to have the paper replaced,
> which is apparently so onerous a thing to do that the state of Nevada decided
> to just retire machines for the day that had their paper roll filled up!).
>
> I would also suggest not using a touchscreen since registration on touchscreens
> is notoriously fickle (I have to reset my palm's touchscreen multiple
> times per day!).
> Instead, I would have buttons on either side of the screen that would
> let you press
> an actual button to vote for someone (like an ATM generally has).

Just for laughs do a google define:DRE

I think that the idea of a DRE voting system is basically flawed. 
It's better to start with a physical expression of the voter's intent
which can, if necessary be manually recounted.

The goal shouldn't be to provide a spiffy user interface, or to sell
fancy hardware, it should be to make the simplest voting system,
easily usable by all voters, which can be counted with a high degree
of confidence.

The ideal system, to my mind, would be paper ballots, manually counted
with enough time given to count them.  Many parts of the world do just
this.

Of course we want instant gratification, so we need to find a system
which can speed up the counting, but not at the loss of having the
ORIGINAL votes in a form that can be manually counted when mechanical
means fail.

And even then, the recount rules should be biased towards running the
original vote records through a different counting method than that
used originally.  What do they say about someone who does the same
thing over and over again expecting a different result.

And fraud prevention should include random sample manual recounting in
such a way as to gain confidence in the 'fast counting' system, as a
normal part of the process, even in the absence of a close vote, or a
challenge.

DRE machines by their very nature require more in the way of software
to provide the user interface to the voter, for touchscreen machines
this involves the software to present the GUI, and to map user actions
to a record of the voter's "intent." Even DREs with physical buttons
and/or dials require a mapping between the buttons and dials to
counters. And this mapping needs to be done for each election.

The more software involved the bigger the job in verifying it. The
parts of the system which need to be customized for particular
elections can't be centrally verified, even for an otherwise
completely locked-down black-box system.

Verifying software requires more skills than proof-reading a paper
ballot. And software here means not only executable code, but also
configuration files. I've seen enough times when a "simple" config
file just doesn't seem to do what I thought it would.

> Finally, all the code should be open.  Perferably open source/free software,
> but I think at a minimum it should be easily independently auditable.

I'm not sure that I'd put it this way.  The primarly consideration is
that the system needs to be easily independently auditable.  I'm
really not sure that open source, much as I love it, helps.  This is
more an accounting/auditing problem, than a system design problem.

Auditing means that you need a means to come to the same result in
different ways, and to be able to reconcile things when you can't.


> Does anyone else have any other suggestions for the design of a good voting
> machine?

What's needed is a transparent vote counting system, not just a better
voting machine.  We should want the citizens votes to count not the
machines.
--
Rick DeNatale

Visit the Project Mercury Wiki Site
http://www.mercuryspacecraft.com/