Re: After looking at code

From: Arthur Keller <arthur_at_kellers_dot_org>
Date: Fri Apr 30 2004 - 11:23:37 CDT

Karl, you are absolutely right. The current bar code is good enough
only for a demo. We need a fully functional barcode encoding that
scales as required. Probably a two-dimensional barcode is needed for
the amount of information needed.

Steve Chessin has some suggestions on such issues, as well as others,
and I invite him to share them with the group.

Best regards,
Arthur

At 1:02 AM -0700 4/30/04, Karl Auerbach wrote:
>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--

-- 
-------------------------------------------------------------------------------
Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA  94303-4507
tel +1(650)424-0202, fax +1(650)424-0424
==================================================================
= 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