RE: FAQ # 25

From: Popkin, Laird (WMG Corp) <"Popkin,>
Date: Mon Dec 15 2003 - 18:13:37 CST

Sorry, here's my post in plain text format. Outlook seems to like sending
HTML formatted mail so much that it overrides its own defaults every time I
reply to a message (at least, when I reply to an HTML message), requiring me
to re-set the email format on every message I send.

Anyway, my apologies for being anti-social, and here's the message in plain

- LP
-----Original Message-----
[]On Behalf Of Popkin,
Laird (WMG Corp)
Sent: Monday, December 15, 2003 7:08 PM
To: ''
Subject: RE: [voting-project] FAQ # 25

I think that if the chance of a barcode error being accepted is lower than
of an MD5 hash or a x.309v3 certificate randomly matching, we're OK. :-)
I found a nice "why barcode" writeup at
"There are two important measures used in evaluating the input methods. The
first is called SER (substitution error rate), which indicates the
probability of a scanned character contains an error. The second parameter
is the FRR ( the first read rate) which indicates the probability of
capturing all the data in the first attempt. In addition to that, the cost
of printing and reading needs to examined."
"The substantial advantages of barcode technology is very low printing cost
and error rates. The density can be very high too with the invention of high
density linear symbologies and 2D symbologies. The SER is usually 1 per 1
million characters and FRR is usually higher than 90%. Due to this reason,
barcode technology is now widely used in most of industries as a means of
automatic input."
>From the little work I've done with barcodes (UPC and ISBN codes), the
various scheme's error correction codes virtually eliminate the chance of a
bad barcode being accepted erroneously. That's not to say that some other
scheme couldn't also work, and the OVC system should be designed so that it
could support alternate schemes in its architecture, but I personally don't
see a problem with barcodes, given that we're checking against digitally
collected ballots and printing on controlled ballot paper stock. (Right?)
- LP
-----Original Message-----
[]On Behalf Of Alan
Sent: Monday, December 15, 2003 6:45 PM
Subject: Re: [voting-project] FAQ # 25

> I agree, the bar code certainly goes in the prototype, but we don't
> need to write the FAQ as if we're ruling out the alternatives. We
> want to claim intellectual ownership, or at least, we want to claim
> the right to use a broad swath of competing technologies that include
> bar codes but are by no means limited to their use.
> Let's not let our FAQ answers box us in, and let's not give answers
> that lead others to dismiss what we're doing because it uses bar
> codes.
Of course, I agree.
At the same time, we should not let any dismissive remarks about barcode
inaccuracy go unchallenged. The scheme we have has several built-in checks
that make it very very unlikely barcode errors could pass undetected.
It might help if we could compute the odds of a barcode error (writing or
reading) could get through the ballot reconciliation procedure without
throwing an error. This must be one chance in a very very long number.
In our prototype system, the barcode error must still return a 40-digit
number. This is one chance in how many thousands (or millions)? Then that
erroneous number must still result in a valid ballot (i.e., no combinations
of ones where they can't be) -- one chance in some quintillions or more. So

you multiply those odds together. Then multiply by the chance that an error

in the voting machine xml file would happen to match the erroneous data in
the xml file from the barcode scan. This would be one chance in a number
that must wrap around the world several times. While "impossible" may not
be the applicable word, it's extremely unlikely to say the least that any
error in the barcode could pass through the ballot reconciliation process
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 Wed Dec 31 23:17:13 2003

This archive was generated by hypermail 2.1.8 : Wed Dec 31 2003 - 23:17:19 CST