Suggested minor enhancement to OVC procedure.

From: Charlie Strauss <cems_at_earthlink_dot_net>
Date: Tue May 22 2007 - 22:48:42 CDT

Background:
The OVC reconciliation procedure is a step where the final scanned
paper ballots are validated as having an identical entry in the logs
of the ballot creation computer.

In the OVC procedure, spoiled or uncast paper ballots are not
assuredly all retained at the polls since voters may escape with
them. Indeed under some circumstances this might be encouraged if
they want to check the barcodes on third party scanners.

If there is to be any ballot "Stuffing" then the ballots in the
ballot box have to have been created on the ballot making computer so
that there is an identical entry. Thus those "unaccounted for"
ballots are the richest source of stuff-able ballots.

Strawman proposal:
Here is a strawman concept for a minor tweak on the Reconciliation
procedure. Forgive me if this is already in place or all ready
discussed and rejected but I don't recall that being the case. This
does not entirely foreclose the problem but it should greatly reduce
that particualr pool of potentially stuffable ballots.

It's likely that most voters, particularly honest ones, who generate
multiple paper ballots will do so in a single session at the voting
terminal. Thus if one could somehow have a session ID that persisted
across a single voters duration at the terminal then one could store
all ballots created with that session ID. Then during the
reconciliation procedure, a red flag is signaled if two paper ballots
turn out to correspond to the same session ID. (it of course does
not tell you how to resolve the issue but that's a different can of
worms).

Discussion of Downside:
The tricky part here is enforcing the session ID. First note that
it's no crisis if a voter has multiple session IDs. Indeed that could
happen for many reasons. e.g. voter votes on one terminal prints out
ballot then decides out of the blue he wants to re-do his vote on a
different terminal. Or likewise if the voter prints the ballot,
changes mind, takes takes a time out befoe voting again later. This
is not a problem in the session that while it undermines the
protection of the session ID it does not cause an invalid situation.

Instead the problem with the session ID is that it rerquires a
terminal activation step of somesort to create a new session ID for
the next voter. That not only adds a complicating step in the
process, but it also creates a big problem if ever there is a lapse
in the activation step and two voters vote under the session ID.

possible bonus benefit.
There was considerable debate (long ago) as to whether there should
be a Unique (Random) ID on each ballot to assure a one-to-one
correspondence. I forget the outcome, but Im pretty sure there are
UIDs now. I note that the session ID is weaker than the UID but
embodies many of its benefits and thus might be a way to get rid of
UID on the ballots.

_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Thu May 31 23:17:04 2007

This archive was generated by hypermail 2.1.8 : Thu May 31 2007 - 23:17:05 CDT