Re: After looking at code

From: Alan Dechert <alan_at_openvotingconsortium_dot_org>
Date: Fri Apr 30 2004 - 12:05:50 CDT

Karl,

> 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.
>
And it took you how long to arrive at this conclusion?

Clue: this is demo code. The idea was to throw it out, and then start anew
with the production code.

The evolutionary path from demo to production is not obvious.

> 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.)
>
There has been some discussion about whether or not we will use a 1-d or 2-d
barcode for the production system. I don't think we can answer that yet.
Some even want to get rid of the barcode altogether. There is a lot of
testing to do before deciding these things.

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 Apr 30 23:17:26 2004

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