After looking at code

From: Karl Auerbach <karl_at_cavebear_dot_com>
Date: Fri Apr 30 2004 - 03:02:23 CDT

I've been looking at code.

And I believe I see some difficulties looming (actually I think that the
we could include the present tense as well as the future.)

In particular I think that there is not enough information encoded into
the bar code.

In particular, I have observed that the code that exists is built around
one particular election with one particular set of contests.

In a real life election different voters, often different voters within
the same voting place, will be presented with different sets of contents.
It seems like asking for trouble to depend on perfect physical segregation
of different ballots. Yes, such segregation will be in the norm, but I
think we should protect even against accidental (or intentional) mixing of
the voted ballots.

I believe that it is necessary that each particular collection of
contests must have a unique identifier that serves as a key into a
database of descriptions of what choices are being presented to a voter.

And that identifier ought to be incoporated as the leading part of the
data that makes up the bar code - and that identifier (indirectly) defines
the format of the latter part of the bar code that contains the actual
choices.

Not merely for scanning convenience but also to reduce the chance of
attacks based on scanning the identifier off of one ballot and the choices
from another, I believe that this identifier and the choices need to be in
the same bar code sequence.

I tend to believe that the identifier should be something that is in a
space large enough to uniquely define all ballots in all jurisdictions for
at least historical time spans - i.e. a GUID/UUID, 128 bits. That may be
too big for use in a single bar code that also includes the voters choices

In any case, this identifier needs to lead to a data definition that
describes the format of the rest of the bar code.

Even if this identifier is not used, it appears that we need a data
definition language that the ballot processing code can read - it's not a
good idea to build specific ballot definitions directly into the code
itself.

(By-the-way, this data definition will ultimately need to be protected
against modification by a digital signature.)

                --karl--
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Fri Apr 30 23:17:26 2004

This archive was generated by hypermail 2.1.8 : Fri Apr 30 2004 - 23:17:29 CDT