Re: "dumb scanners"

From: charlie strauss <cems_at_earthlink_dot_net>
Date: Thu Dec 07 2006 - 12:28:27 CST

Al large part of our discussion comes down to just this:
Should we be dismissive of the secret ballot?
You would argue yes while other's like me hold it sacrosanct.

But if we are going to allow the veil to be pierced why not entirely elmininate ballot secrecy? Then it's comparatively trivial to produce a system that is secure.

Turning to the more important issue of "fixing" your system to keep the good idea of a "dumb" scanner and elminating it's destruction of ballot secrecy here's a thought.

 The basic notion is we want a scanner that is dumb in the sense that it's actions are invariable while just sufficient to count ballots. We might not be able to achieve this with existing COTs systems but we could possibly acheive the desire of an invariable machine.

To do this we have the machine not produce full ballot image reports in a single record (XML file in your schema), but rather we have it produce separate records for each oval. Each of these records would record three things: 1) the ballot style ID number. 2) the X-Y poistion of the oval 3) the state of the oval (filled or not filled).

Thus the scanner would operate as follows.
When a ballot is inserted the first few rows of marks are read to get a ballot ID number (care would need to be taken to make the patterns unforgable). Then the machine would read the remainder of the ovals and store on a hard disk a record for each oval contianing those three elements. When the machine is read out at the end of the day, the order of those stored records is randomized (in much the same way OVC does a ballot shuffle). Once can argue if the dumb machine should do the intermeidate storage of the records or if the dumbscanner should output them immediately and the record recording and order scrambling be delegated to another machine (for example a CD burner that puts the records in random locations).

In any case this would nominally preserve the secret ballot while allowing a publication of a record that can reconstruct the aggregate vote totals that was generated prior to the processing getting to a machine that was programable. The system is versatile and should thus be able to handle a wide variety of possible ballots without reprogramming. In particular no ballot description information is given to the machine.

There are three problems that still remain
1) No overvote protection. You proposed using an ancillrary machine to do this.

2) One is of course still trusting that the recorded votes are not being misreported. But if we can keep this as all unprogrammable hardware from ballot scanner to CD writer. And the CD is immuatable (and not a harddrive). Then we foreclose a lot of ways one could cheat.

3) This decompostion to ovals-as-records won't work for ranked preference voting, which would require knowing the state of sets of ovals simultaneously.

paranoid extension of the concept: If one were really concerned the CD burner might cheat and misrecord things then here's a suggestion to aid with that.
1. The scanner generates four random numbers for every oval. These are called UID, XOR1,XOR2 and XOR3
2. The output of the scanner is two separate channels.
3. the first channel's record is the UID of the oval, XOR1, XOR2, and the state of the of oval (1 or 0) that has been xored with XOR3
4. The second channels' record is the UID of the oval, XOR2, the X-Y position xored with XOR1, and the ballot style xored with XOR2.
5. Channel 2, only has entries for filled ovals. Channel 1 has an entry for every oval.

the two channels are burned by two different CD recorders.
Offhand I can't think of a way that either CD burner could either shift votes, or drop votes in a way that would not be evident in their records. maybe you can. But as I said this was just a paranoid complex extension. One still has to trust that the reported CD's are the actual vote record.

OVC-discuss mailing list
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Sun Dec 31 23:17:08 2006

This archive was generated by hypermail 2.1.8 : Sun Dec 31 2006 - 23:17:16 CST