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

Chad Thomsen chad.thomsen at gmail.com
Wed Jan 4 15:48:05 EST 2006


>>5. Easy to use (for poll workers on election day)

Are you sure its not designed easy to use for all the folks in Florida?
BHaahaahaahaahaha!!!


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



More information about the TriLUG mailing list