>>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 <[EMAIL PROTECTED]> wrote: > > On 1/4/06, Greg Brown <[EMAIL PROTECTED]> 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/ > -- 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/
