OpenVote (was Re: [TriLUG] OT: www.hexblog.com - a fix for the WMF vulernability.)
Tanner Lovelace
clubjuggler at gmail.com
Wed Jan 4 14:45:25 EST 2006
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.
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).
Finally, all the code should be open. Perferably open source/free software,
but I think at a minimum it should be easily independently auditable.
Does anyone else have any other suggestions for the design of a good voting
machine?
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.
More information about the TriLUG
mailing list