[EM] Electronic Voting Bill of Rights?

Dave Ketchum davek at clarityconnect.com
Sun Nov 16 14:59:01 PST 2003

On Sun, 16 Nov 2003 18:40:54 +0000 Gervase Lam wrote:

>>Date: Sun, 16 Nov 2003 00:24:57 -0500
>>From: Dave Ketchum <davek at clarityconnect.com>
>>To: David GLAUDE <dglaude at gmx.net>
>>Subject: Re: [EM] Electronic Voting Bill of Rights?
>>     Recording ONLY at the end was my assumption.
>>     Each record of votes is required to contain votes in random order -
>>enough to make it impossible to be sure which belongs to a particular
>>voter. This requires temporary storage, in random order, on a hard disk
>>or floppy or magnetic card ...
> I think David means that recording at the end is not good enough.  It has 
> to be recorded straight on to a write-once removeable medium.  Putting the 
> data on to hard disk, for example, and then on to the removeable medium 
> means introducing the "weak" link between the hard disk and removeable 
> medium.

TOO MANY DAVIDs - apparently does not mean me.

Perhaps involving a hard disk can be called weaker than desired, but I 
cannot picture anything that is both usable, secrecy wise, and usable 
space wise, on what I understand of CDs and DVDs:

REQUIREMENT:  When polls close it SHALL NOT be possible, knowing Joe was 
voter 1 or 987, etc., to know exactly where his vote was recorded on the 
CD.  Even if you know that Joe followed Tom, and can find Tom's vote 
because he voted a unique pattern used by no one else that day, this SHALL 
NOT be enough to identify how Joe voted.  Random number generators 
suitable for this use are possible, though many random number usages would 
find what I demand above to be unacceptable (repeatability is often demanded).

Assuming a 99 track CD, recording one vote on each track, and write-once 
working independently for each track, the whole CD could be a 99 position 
random storage area and satisfy the above requirement.

BUT, there are less than 99 available tracks, for I specify other content 
for part of the CD.  Also, the CD almost certainly must serve more than 99 
voters - perhaps 1000; perhaps even more.

So I finish by demanding a random storage area big enough to keep its 
content reasonably random, but not caring what kind of storage.

BTW, the storage used for the program had to be dependable - why would 
that not be sufficient for this data?  Also, the record for each vote can 
be compact - just sufficient for a computer to understand the content.

> In addition to this, a hard disk is a re-writable medium.  Therefore, 
> there could be problems.  Mind you, computer memory is a re-writeable 
> medium too!

But I am not keeping any permanent records on the hard disk or in computer 
memory - it works fine as the temporary storage needed.

> You've also got things called re-writable CDs.  There could be some 
> confusion here.

Need to see to it that proper CDs are used, and that the burners installed 
are incapable of doing the erase that goes with rewriting.

> But I think this is a relatively easy one to sort out.  The CD-Writer 
> should be able to detect this type of thing, as long as the "markings" on 
> blank Write-once CD that the CD-Writer reads is correct.
> I am sure my understanding of what David is saying is wrong here.  So I'll 
> let David speak for himself.
>>It is too early in this game to be sure whether a CD has enough
> On the contrary.  If anything, this is the more practical side.
> A CD can contain about 650,000,000 bytes.  Assuming that 1 ballot takes 
> 100 bytes (characters, letters), what you get is the ability to put in 6.5 
> million ballots on the CD.  Even assuming the worst of having 1000 bytes 
> per ballot, 1/2 million ballots on a CD isn't shabby.
> You mentioned gaps between the records earlier.  I forgot about this.
> It depends on whether you do Disk-At-Once or Track-At-Once recording.  If 
> you do Disk-At-Once (i.e. write all the ballots in one go), then what I 
> said above would work.

Remember that the disk has other content - I want the single disk to start 
with program, etc., to read when polls open, and for everything to get 
recorded that might be of interest later.

As covered above, I expect multiple ballots must go in each ballot record 

> Writing a ballot per track (Track-At-Once) is nowhere near practical.  The 
> minimum length of a CD track is 600,000 bytes.  Also there is a maximum 
> number of tracks, which is 99.  That translates to 99 ballots.  For the 
> gory details, see <http://www.cdrfaq.org/faq02.html#S2-9>.
> I don't know about DVD, but CD would obviously be cheaper.

I expect CD to be cheaper, and likely more dependable - I am simply 
avoiding possibly tangling with CD capacity this early in design.

>>I do not know available reliability - even installing double
>>sets of drives is among the design possibilities.
> Good point.  Audio CDs have data redundancy.  This redundant data contains 
> hashing data to "re-create" the sound so that you can't hear the 
> difference.  I think I am right in saying this.  Anyway, this isn't good 
> enough for ballots.

The possibilities include recording multiple copies of each ballot record, 
and various ways to strengthen "parity" protection.

> Nevertheless, I think there are equivalent algorithms that can fully 
> re-create the data.  Though it may be easiest just to install the double 
> drives.

Double drives look ugly to me - among the problems are twice as many disks 
to keep track of.

We are getting over our heads in two ways here:
      We do not need methods for reliability this early in design.
      Others HAVE to have worked on reliability and likely all that is 
needed is to copy what exists.

>>> 2) Now you also have to fight Cosmic ray
> Speaking of outer space...

Early, but I think we do not have their problems - they have MANY times 
the complexity and, actually, failure is a bigger catastrophe for them 
than for us.

> One of the things mentioned as a part of this discussion was the use of 
> Open Source to allow the checking of the inner workings of the computer 
> software that counted the votes.  I was told that NASA uses two 
> independent teams of computer programmers in order to program the software 
> that controls rockets, for example.
> The two teams do not communicate with each other.  There is also a "head" 
> team.  They draw up the specification of the software required.  For 
> example, they may want software that interprets the data from the 
> temperature sensors on the nose cone.  They may go even further than this 
> and specify what the specifications of the functions/subroutines are.  (I 
> can't remember whether the head team does the high or low level 
> specification or both.)
> If one team asks a question in order to clarify the specification etc... 
> the other team are formally told what the question is.  Obviously, both 
> teams get an answer from the head team.
> The writing of the software is left to the two independent team of 
> programmers.  The end products are two independent pieces of software that 
> do the same thing.
> The rockets are then "wired" so that it uses the data/output from both 
> bits of software.  If the data/output from both are the same, then the 
> rocket deems it is OK to use the data.  I don't remember what happens if 
> the data/output are different from each other...
>>     Has all the speed voting needs (but I do not know about a Z80
>>controlling CD or DVD drives).
> I remember a craze during the mid-1980s of the Domesday Project to mark 
> 900 years of the Domesday Book.  One half of the idea was to get all of 
> the schools in the country to take photographs of their local area and 
> write anything about it.  The data for the whole country was then stored 
> on a 7 inch (I think) Video disc, which was accessed using a popular 1MHz 
> 8 bit computer via a SCSI cable.
> If that could be done then, I think it could be done now.  However, 
> because the hardware would be proprietary, it would cost money.

Does not really answer our problem, but it could simply be whether anyone 
has written CD burner code to run on a Z80.

>>> 3) Some screen technology might be better than other...
>>> Otherwise you need to go for Tempest proof equipment that cost a lot.
> Good grief...  Never thought of this.  I have basically agreed with David 
> that paper ballots are the way to, if I have read the posts correctly.  
> But now....

Whatever is used for voting, defending secrecy is a proper concern.

> Thanks,
> Gervase.

  davek at clarityconnect.com    people.clarityconnect.com/webpages3/davek
  Dave Ketchum   108 Halstead Ave, Owego, NY  13827-1708   607-687-5026
            Do to no one what you would not want done to you.
                  If you want peace, work for justice.

More information about the Election-Methods mailing list