Re: Security markings on the ballot

From: Alan Dechert <adechert_at_earthlink_dot_net>
Date: Fri Oct 24 2003 - 02:52:43 CDT

Arthur,

> What do you think about printing the ballots on special paper
> pre-printed with color ink that says County of XXX Ballot etc., like
> a real ballot, with a serial number printed on a perforated tear-off
> stub the voter can keep. That allows for some control over ballot
> stock, and makes it harder to substitute ballot forms.
>
I think this is totally unnecessary. However, the real full-blown study
should include a comprehensive threat analysis that would look at pros and
cons of using special ballot stock versus ordinary paper (serial numbers are
another issue). You think you might get "some control over ballot stock"
but you might be adding complexity, expense, and opening all sorts of other
issues. I see absolutely no benefits, but lots of problems.

The relationship of a pre-printed serial number to the electronic record
would be very tricky. The tear-off stub performs a completely different
function. We have these on ballots now to make the ballot anonymous. When
you are handed the unvoted ballot, the serial number is evident and may even
be recorded -- tearing it off breaks the link between serial number (and
you) and ballot. Ballot anonymity is achieved by a completely different
method in our system: The PC doesn't know who you are and no one has any
way of knowing your ballot id number (unless you choose to reveal it).
Depending on exactly how you plan to use the special ballot stock with the
pre-printed serial numbers, you may create a situation that would compromise
the secret ballot by also having a serial number on the finished ballot. If
the finished ballot has no serial number on it, then you may lose some of
the auditing features of our system (and make it easier to substitute phony
ballots later).

What you are suggesting is a different system and we'd have to re-think the
whole process. What problem are you solving? You have not thought this
through. I see no reason to think people could substitute ballots without
detection with the design I've been working with. Any attempt to stuff
illegitimate ballots at the precinct level would be instantly detected once
the reconciliation process is run (immediately after the polls close) to
check the paper ballots against the electronic record. The number of paper
ballots must match the number of people that voted. Each paper ballot must
have a matching electronic record in the database. If the record is not
there, then it must have come from some other source and it becomes a
suspect ballot. The nature of the forgery would be revealed on closer
inspection.

With our system, the ballots should not be moved from the precinct until
several steps are taken.

1) The count of the paper ballots must match the number of people that
voted.
2) A data table is created by scanning the barcode on each paper ballot.
3) The data is collected from each PC and merged into one file on the admin
PC.
4) The data (ballot images) in 2 and 3 above are compared. There will
always be some ballot images in 3 that are not in 2. This is due to ballots
printed to test the PCs on startup, ballots printed by mistake by voters,
and possibly due other errors (printer jams). The extra ballot images
should be accounted for as best as possible. The id numbers of the test
ballots should be recorded and the test ballots (at least one for each
voting station) themselves should be retained. ID numnbers from destroyed
ballots (either voter mistakes or printer mistakes) should recorded -- a
corner from the ballot should be clipped off and retained before the ballot
is shredded. If there are ballot images not accounted for (maybe someone
walked off with a ballot) then a list of AWOL ballot IDs should be made.

The data file representing the vote from the precinct is extracted from 3
above (the table in 2 may not have the write-in data -- this depends on the
barcode scheme used in the production system). This file is then
transmitted to county offices. The file is posted on the county server and
then checked from the precinct.

Finally, the pollworkers take the roster (has the pre-printed list of
eligible voters plus the signatures of the actual voters), the ballots, the
test ballots (one for each voting station), corners from destroyed ballots,
CDs collected from the PCs (these are the boot CDs with all the software and
data but also has the file of ballot images written to it at the close of
the polls), a floppy disk (or CD or other media) that has all the
administration stuff (configuration files, resultant files from
reconciliation procedure, etc) -- put all this in a box marked with the
precinct number and seal the box.

At this point the box can be moved to the county offices.

Once the precinct level tabulation is performed, the central count of
ballots must match the aggregate of the precinct counts. Any manipulation
of the electronic record would result in a mismatch between the two. Any
substitution of paper ballots after the ballots are moved from the precinct
level will cause a mismatch between the electronic record and the paper
record.

Whether you have special stock or ordinary paper, overwhelmingly, the
integrity of the vote rests with the physical security of the ballots. If
you are committed to the idea of having a physical token -- like a piece of
paper -- represent your authentic vote (as opposed to a purely electronic
record), then it is essential that we pay close attention to the way the
paper is handled. Having pre-printed stock (with serial numbers) does
nothing to improve ballot handling procedures. In fact, it only adds to
ballot handling issues since the ballots now have to be tracked from the
manufacturer.

Alan D.
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Fri Oct 31 23:17:04 2003

This archive was generated by hypermail 2.1.8 : Fri Oct 31 2003 - 23:17:07 CST