RE: FAQ # 25

From: Popkin, Laird (WMG Corp) <"Popkin,>
Date: Tue Dec 16 2003 - 12:02:52 CST

From: David Mertz
>I don't think scan error rates are higher if we choose OCR-friendly
>fonts off the bat. And especially not if we use trim marks to
>precisely indicate the positions where fields occur. Kinda like what
>the IRS does nowadays with computer-printed tax returns: they are 100%
>human readable, but they just happen to choose particular fonts and
>exact page positions for data fields.
>
>As to space, this is a non-issue. If the ballot data can be encoded
>for humans to read, an OCR can do the same thing. The only question is
>the confidentiality thing. A blind voter doesn't want to expose the
>face of her ballot to someone else, like to a poll worker. But quite
>likely, a BVA booth with a curtain can answer that: The blind privately
>feeds the whole page into a scanner, rather than merely scan the
>exposed edge.

I did a little digging, and it looks like OCR wands, etc., have gotten
better and cheaper than back when I worked with OCR and barcodes (about 5
years ago). While I can't find any documented scan error rates for OCR, I
came across a couple of reports that said that barcodes were the most
reliable/affordable scheme (comparing OCR, bar codes, RFID, etc., for
industrial applications).

>The barcode *IS* "obfuscated" in order not to produce easily visually
>identifiable patterns. The obfuscation algorithm is quite simple, but
>not so simple that people can do it in their heads. Moreover, even the
>way that bits encodes votes, and binary converts to decimal, makes the
>barcode non-evident to a voter... even one with a barcode reader."

Makes sense. Is there a spec somewhere for how the vote is encoded into the
barcode? Not the specific barcoding scheme (they're documented elsewhere)
but how the XML vote is translated into the string used to generate the
barcode? Sorry if this is a stupid question. :-)

If the argument is to print OCR, we'll have to also remove the obfuscation,
and print the data in a human readable format, not packed binary, etc. So of
course, that blows up the logic behind trying to avoid easily identifiable
patterns. So perhaps a middle ground could be to print barcodes, but
generated from plain text rather than packed binary and obfuscated? It'll
make the barcode longer, and make no functional difference to the system,
but it would help people prove to themselves that there's nothing secret
going on.

>> - Scan the ballots using a stand-alone OVC barcode reader and compare
>> its
>> display to the votes printed on the ballot. This wouldn't reveal hidden
>> data, but would verify the votes as recorded in the barcode.
>
>Yep. That's what I suggested before as a "spot check".

Sounds like we're in violent agreement.

>> - If you're really paranoid, download, read, and run your own copy of
>> the
>> OVC software, and re-scan your ballots to prove to yourself that the
>> barcode
>> matches the human readable printed values.
>
>Free Software is a VERY good thing!

I sure think so. This is ultimately what's going to give people trust in the
system anyway -- anyone can run and test it themselves, so all we have to
prove is that the actual units in the field are running the same software.
:-)

>Btw. On the statistical tests: I wasn't really asking for clarification
>of the details (not that providing them has any harm). The point is
>just that working out confidences is *doable*, but not *self-evident*.

Good point. But even if voters don't follow the precise math, I think that
they'd gain confidence in a system that involved randomly selecting and
checking a percentage of ballots for vote tampering. The same way that they
trust existing voting systems, with their complex sets of handoffs to ensure
physical security of the ballot box, etc., that nobody sees but assumes must
take place. :-)

==================================================================
= 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