[Fwd: Re: [EM] Re: touch screen voting machines]

[Ken Johnson]

-------- Original Message --------
Subject: 	Re: [EM] Re: touch screen voting machines
Date: 	Mon, 17 Nov 2003 13:34:45 -0800
From: 	Ken Johnson <kjinnovation at earthlink.net>
To: 	Dave Ketchum <davek at clarityconnect.com>
References: 	<20031115104502.29455.28605.Mailman at geronimo.dreamhost.com> 
<3FB7C5F2.5050808 at earthlink.net> <3FB7DCAB.9040600 at gmx.net> 
<3FB81547.4070309 at clarityconnect.com> <3FB861C4.3060507 at earthlink.net> 
<3FB8798F.7000708 at clarityconnect.com>



Dave Ketchum wrote:

>
> Either:
>      There is information in attaching this serial number to a ballot, 
> in which case I object, or
>      There is no such information, in which case I cannot imagine why 
> you would care. 

There is no information connecting the ballot with the voter. The ballot 
serialization is analogous to storing the ballot storage location with 
each database record, and it serves no purpose other than enabling 
election officials to confirm that individual ballots are correctly 
recorded in the database.

>
>
> No one talks seriously of shuffling 10,000,000 paper ballots, but New 
> York law does demand that the few hundred that accumulate in a day at 
> a polling station SHALL be shuffled BEFORE looking at content. 

If only 10 people voted at the station, and they all voted Green Party, 
the shuffling won't do much good :) On the other hand, ballot 
serialization would be fully randomized so you can't tell from the 
database where the votes came from.

>
> On this reflector I have been specifying that electronic ballots SHALL 
> be stored randomly, such that you cannot tell by storage position 
> where the first or last ballot of the election got stored.  The only 
> detail I am willing to concede is that, if there are too many ballots 
> at a polling station to all be stored in a "reasonable" sized area, 
> make the area big enough for reasonable randomizing, and write an 
> area's worth each time it fills up.
>
> I have also specified that if a paper backup ballot gets printed, 
> those SHALL go in a ballot box, and the content SHALL get shuffled 
> just as would have been done with paper ballots without computers.
>
> I do know, from having voted this month, that there is a record made 
> as to  my being the nth voter (and there was ZERO secrecy as to my 
> being the nth voter).  If my ballot automatically ended up in the nth 
> position in an electronic file there would be ZERO secrecy. 

I see no reason why "n" needs to be stored anywhere. Why should anyone 
care that you were the n-th voter? All that matters is that there is a 
certified record that (1) you are legally registered to vote, (2) you 
voted, and (3) you did not vote more than once.

>
> Helps nothing if the information is distributed such that the computer 
> storing the voted ballots knows nothing of voter IDs, and the people 
> and/or computers recording which voter was nth in line are different. 
> Troublemakers would have no trouble correlating these two databases. 

n should not be stored and the two databases should be entirely separate 
with no way of cross-correlating them. Moreover, I don't think the 
second database (the one recording the fact that you voted) need be nor 
should be machine-readable. All they need to do is mark off (e.g. 
initial, stamp, or red-line) your name on a printed list of registered 
voters.

The ballot ID is is only used to correlate database ballot records with 
paper ballots. This is necessary because the paper ballots - not the 
database - constitute the official, legal record of the votes. Any 
challenge to the election validity is resolved by inspecting the paper 
ballots, not the database, so the computer-generated election result 
should not be certified unless and until it is confirmed that the 
database correlates to the paper ballots.

I agree that voter secrecy is a concern, but I think ballot 
serialization can be implemented without compromising secrecy. My 
greater concern is the possibility that a clever hacker might find a way 
to alter the election results. Security concerns can be partially 
alleviated my mandating the use of open-source election software, but I 
think it's even more important that the raw data on which the software 
operates be freely available and subject to independent verification. 
The verification means should be simple, transparent, and should not 
require an high level of computer expertise or training to understand 
and implement. The verification process should confirm the following:
   (1) Every printed ballot corresponds to a database ballot record 
containing the same vote selections.
   (2) No two database records correspond to the same printed ballot.
   (3) The number of printed ballots equals the number of database records.
   (4) The voting tallies generated from the database agree with the 
reported results.
Without unique ballot ID's there is no way to confirm #1 and #2 without 
essentially doing a full manual recount and re-creating the full 
database. With ballot ID's #2 is a simple uniqueness test. #1 still 
requires inspection of the paper ballots, but a small random sample can 
be inspected to confirm #1 with very high statistical confidence. (Even 
if you counted all the ballots, statistical confidence would not improve 
because people make counting errors.) To fully validate the election, it 
also needs to be confirmed that
   (5) Only legally registered voters voted.
   (6) No one voted more than once.
   (7) The number of voters matches the number of ballots.
These confirmations are made using records (preferably written) having 
no relation to the ballot database, except for the total ballot count.

Ken Johnson




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20031119/11a72824/attachment-0002.htm>