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