Re: More on barcodes, etc

From: Arthur Keller <voting_at_kellers_dot_org>
Date: Mon Apr 18 2005 - 14:51:20 CDT

I agree with this idea, but think that threat analyses and voter concerns
are also important.

Best regards,
Arthur

> Hello Alan:
>
> 1. Bar code or OCR? Have them both as a switchable
> option. Let the election official make the call. You
> can promote the use of bar codes in the documentation
> or instructions but let the people on the spot take
> the heat for their own decisions.
>
> 2. Election cycle initiation: Token or otherwise?
> Again, make this an option that is picked by the
> County Registrar or equal.
>
> 3. Summary paper ballot versus full mark sense
> ballot? Make both styles of output available.
>
> Down with either/or. Do them both. If we can argue
> competing virtues and admit that each choice has
> strengths and weaknesses then all the choices should
> be available.
>
> If both testing and experience show that one method is
> vastly superior to the other and election officials
> are generally in agreement, then options can be
> removed in later versions. Otherwise, this is not a
> battle worth fighting.
>
> Thanks, Ed Kennedy
>
> --- Alan Dechert <dechert@gmail.com> wrote:
>
>> Arthur wrote,
>>
>> > How many blind people say they prefer the current
>> approach?
>> > How many sighted people say they are concerned
>> about the
>> > barcode? When OVC's CTO speaks about technology
>> along with
>> > an acclaimed and accomplished technologist, I
>> think that
>> > retreating behind "go and demo it" is unfortunate.
>>
>> > Certainly a demo with a barcode is easier to
>> produce.
>> > It's not at all clear that the production version
>> should use
>> > a barcode. The paper talks about OCR'ing the
>> text, by the way.
>> >
>> Barcode issues surfaced in some off-list discussions
>> we were having
>> recently. We've had extensive discussions about
>> barcodes in the past,
>> and some of the issues remain unresolved. Arthur's
>> email warrants a
>> detailed response, so here goes.
>>
>> First I want to talk a little about official OVC
>> policy -- where it
>> comes from. The OVC president/CEO (currently me,
>> Alan Dechert)
>> represents official OVC policy. This is by
>> necessity. Someone has to
>> articulate these policies publicly. Sometimes these
>> policies appear
>> in print; sometimes these policies are conveyed in
>> email to other
>> interested parties; sometimes these are conveyed
>> personally at events
>> at which OVC is involved. It's my job to know what
>> those policies
>> are. When issues arise in various fora, I can't
>> say, "I don't know, I
>> have to ask the board." I have to know the issues
>> and know where OVC
>> stands on these issues.
>>
>> Generally speaking, OVC policy is set by consensus.
>> Theoretically,
>> the OVC board of directors has the power to set
>> policy. Some policies
>> are set that way but most policy decisions have been
>> made outside of
>> board meetings. This informal consensus rule
>> generally holds for the
>> board too since we've never decided anything with
>> some close vote like
>> 4-3, or 3-2, etc. Almost everything we decide at
>> board meetings is
>> unanimous with some abstentions here and there. We
>> tend to vote on
>> things only after we've had enough discussion to
>> agree on what we want
>> to say.
>>
>> A great deal of OVC policy was grandfathered-in --
>> the product of
>> discussions that took place before OVC was founded.
>> Mostly, these
>> policy decisions were made in conjunction with our
>> various academic
>> partners over the years. In April of 2001 Henry
>> Brady asked, "so how
>> will people make money with this system?" We
>> started to describe
>> (conjuring, modeling) how the organization might
>> work.
>>
>> A lot of things were decided APR 2003 - July 2003.
>> Someone recently
>> asked if OVC endorses IRV. OVC is neutral on
>> scoring methods because
>> one of the main discussants back then, Arnie Urken,
>> insisted that we
>> remain neutral on scoring methods. Everyone else
>> involved then agreed
>> and no one has ever made a case for changing that
>> policy. That's how
>> the policy was made. During this period, Doug Jones
>> played a major
>> role shaping the OVC model. My wife Lori and Jay
>> Tefertiller (ISIS
>> Technology) worked out a lot of legal and
>> organizational issues (we
>> decided to be a "consortium"). Arthur Keller played
>> a major role too
>> beginning in July of 2003. Doug and I cobbled
>> together the bylaws in
>> NOV - DEC 2003. Ed Cherlin, David Mertz and quite a
>> few other
>> engineers contributed ideas
>>
>> In 2003 (and earlier), we consistently heard DRE
>> makers and their
>> "supporters" (dare I say paid shills?) insist that
>> paper printouts
>> were unfair to reading impaired voters since these
>> voters cannot
>> verify the vote on paper. This position was
>> expressed in a videotaped
>> presentation by Marion Taylor of the League of Women
>> Voters at the UC
>> Santa Cruz forum on electronic voting we organized
>> (mainly Bob Kibrick
>> and Arthur Keller) in OCT 2003.
>>
>> Long before the debates in 2003, I had come up with
>> the idea of
>> putting a barcode on the long edges of the printout
>> so a blind person
>> could utilize the barcode while keeping the text
>> hidden from view
>> (Actually, Ryan Ronco, assistant ROV in Placer
>> County CA suggested the
>> barcode to me in APR 2001. Ryan was mainly
>> suggesting it as a way to
>> facilitate tabulation. I moved it to the edge as an
>> accessibility
>> feature).
>>
>> As I designed the ballot for our demo, I figured out
>> what barcode
>> system I wanted to use. I decided on Code 128
>> because it could encode
>> all the information we needed to encode and scanners
>> could be had dirt
>> cheap (I bought a bunch of scanners for about a
>> dollar each). I
>> looked for GPL'd Code 128 software and found Jan
>> Karrman. Jan joined
>> the project. Most of the technical issues with the
>> barcode were
>> worked out between Jan and I. Sidebar: An example
>> of some OVC policy
>> making .... David Mertz insisted that it might be
>> possible for someone
>> to discern some information about the ballots by
>> eyeballing the
>> barcodes. I never believed that. We came up with
>> an obfuscation
>> routine that was easy to implement and cost nothing,
>> so I went along
>> with it. If it was all up to me, I wouldn't have
>> bothered with it.
>> The gain was small but the cost was negligible. In
>> other words, OVC
>> policy is sometimes contrary to what I believe. If
>> the consensus
>> opinion is contrary to what I believe, I'm glad to
>> go along with it so
>> long as it doesn't conflict with some concepts I
>> hold and consider
>> basic and important.
>>
>> The scheme we demonstrated for reading-impaired
>> ballot verification
>> was very important. We publicly shattered a very
>> persistent myth.
>> Shawn Casey O'Brien, a disabled rights activist,
>> showed up at our OCT
>> 2003 UC Santa Cruz forum and gave a speech
>> denouncing the paper trail
>> because it was useless to blind people. I
>> demonstrated why he was
>> wrong about that, and ended the debate. You don't
>> hear anyone making
>> that claim anymore (blind can't verify paper
>> ballot). All opinion
>> leaders know it's false. No disabled rights
>> activists have shown up
>> at any of our events since OCT of 2003 to make that
>> claim. OVC can't
>> take all the credit for that since others have made
>> the point too. I
>> do think it's fair to say we played a major role in
>> dispelling this
>> myth. Since accessibility has been a major theme in
>> voting
>> modernization, it was absolutely necessary to break
>> this myth in order
>> to get the idea of a computer generated "paper
>> trail" accepted for
>> voting.
>>
>> Some credible technologists (and others less
>> technical) have said that
>> we should do away with the barcode since it seems to
>> be contrary to
>> the goal of transparency in election administration.
>> I don't happen
>> to believe that, but I'm happy to go along with it
>> since switching to
>> OCR does not impact the overall veracity of the OVC
>> approach. I am
>> perfectly willing to say, now, that while our demo
>> utilizes the
>> barcode, our production system may not. I see pros
>> and cons. I see
>> tradeoffs. I see perceptual issues.
>>
>> Before getting into some of the pros and cons, let's
>> lay out some main
>> principles as a backdrop for the discussion.
>>
>> First Principle: the voter is paramount.
>> --------------------------------------------
>> The voting system should be designed and built with
>> this principle in
>> mind. Security, trustworthiness, cost, clarity,
>> simplicity,
>> ease-of-use, accuracy, accessibility, auditability,
>> inclusiveness,
>> convenience are all important issues in election
>> administration. But
>> what's secure, trustworthy, inexpensive, clear,
>> simple, easy-to-use,
>> accurate, accessible, auditable, inclusive, and
>> convenient for
>> election administrators must be secondary to what's
>> secure,
>> trustworthy, inexpensive, clear, simple,
>> easy-to-use, accurate,
>> accessible, auditable, inclusive, and convenient for
>> voters.
>>
>> The voting system is for voters, and paid for by
>> voters.
>>
>> Second Principle: costs must be minimized
>> ---------------------------------------------------
>> The four billion dollars being spent on voting
>> modernization is a
>> fluke of history. Before 2002, states and counties
>> have never had
>> much money for voting equipment, and should not
>> expect a lot of money
>> to be available in the future for new voting
>> equipment. Budgets are
>> constrained everywhere. Expensive voting systems
>> means long lines and
>> voter disenfranchisement. Ultimately, open voting
>> will take hold
>> through market forces -- open voting systems must be
>> very inexpensive.
>>
>> Also, if America is to maintain a leadership role in
>> promoting
>> democracy through out the world, we have to show how
>> a great voting
>> system can be built and maintained inexpensively.
>> How many
>> jurisdictions in developing countries could
>> contemplate deploying the
>> $5,000 AutoMark system? It's a ridiculous waste of
>> resources.
>>
>> Third Principle: election process must be fully
>> auditable
>>
> ----------------------------------------------------------------
>> Institutional protocols must be in place to enable
>> full public audit
>> of all aspects of election administration. If there
>> is anything a
>> voter wants to know about election administration,
>> he or she should be
>> able to get answers in whatever level of detail
>> desired without ever
>> hearing, "trust us" or some other indication that
>> information about
>> the voting system is not available to them.
>>
>> Fourth Principle: Election administration is not --
>> and can never be
>> -- a computerized process
>>
> ---------------------------------------------------------------------------------
>> The process of administering elections mainly
>> involves procedures
>> carried out by people. Computers can assist in the
>> process, but can
>> never be expected to run elections. Computers can
>> enhance the
>> security and accuracy of election administration, as
>> well as keep
>> costs down.
>>
>> There are other important principles, but these are
>> the three main
>> ones I want to keep in mind right now. In light of
>> the foregoing, I
>> have the following observations about the barcode v.
>> OCR debate with
>> respect to the computer generated summary paper
>> ballot;
>>
>> 1) Machine reading should be incorporated into the
>> process of counting
>> votes. Computer reading can act as a check against
>> human error, and
>> vice-versa. Security and accuracy will be best when
>> both computer and
>> human counting are employed.
>>
>> 2) A barcoded ballot may be more tamper resistant
>> than one with no
>> barcode. We expect that rules surrounding the OVC
>> barcoded summary
>> paper ballot would include a rule that says
>> something like, "No
>> pencil, pen, etc. marks of any kind are to be made
>> on the summary
>> paper ballot. If you want to change anything on the
>> ballot, you must
>> re-do the process and print a new ballot. Any hand
>> markings on a cast
>> ballot will be ignored." The rule should be
>> ironclad. Voters will be
>> encouraged to carefully review their ballot
>> on-screen before printing.
>> If there are scribbles on a barcode, it may still
>> be readable or the
>> other duplicate barcode could be read instead. We
>> could also place
>> another copy of the barcode in the text area if
>> necessary, and/or
>> another version of a barcode (not easily
>> recognizable as a barcode)
>> could be included that may be read by a special
>> reader in case a
>> ballot has been defaced. An OCR only summary paper
>> ballot may not
>> work well with such a rule (hand markings ignored).
>> A cross-out may
>> cause the OCR reading to fail. If the mark-out is
>> complete, or the
>> selection torn off, it may be impossible to
>> determine what was printed
>> on the ballot.
>>
>> 3) OCR-only is not any more transparent, and may be
>> even less
>> transparent than a barcoded ballot. For example, the
>> architecture we
>> are employing involves using the machine reading to
>> create a
>> reconstructed electronic ballot image (REBI) and
>> compare that with the
>> electronic ballot image (EBI) from the voting
>> machine for that
>> particular ballot. If the contents of the REBI and
>> EBI match, the
>> machine reading was accurate. However, this proof
>> alone is not
>> adequate. If malware is installed, it's conceivable
>> that while the
>> REBI and EBI match, they don't match the printed
>> text. The lie would
>> work differently for OCR as opposed to barcode, but
>> could still give a
>> phony result in either case.
>>
>> You vote for Smith, but Jones is recorded in the
>> EBI. Smith is
>> printed on the ballot.
>>
>> Let's say a tiny number "3" is placed in a strategic
>> location on the
>> printout For the OCR system, it can read the
>> ballot and report
>> "Smith" but also sees the tiny 3 and knows that it
>> should record this
>> as a vote for Jones, the third candidate in the
>> contest. The REBI and
>> EBI both say Jones. Jones gets the vote despite
>> what is printed on
>> the ballot.
>>
>> The barcode could be similarly encoded to lie to the
>> voter saying,
>> correctly, that "Smith" is printed on the ballot
>> while Jones is
>> getting the vote.
>>
>> Given that OCR software is quite complex, it would
>> be difficult to
>> spot malware that could cause printed ballots to
>> reflect the voter's
>> choices but record the electronic vote otherwise.
>>
>> So, regardless of whether we employ OCR or barcode,
>> a manual check of
>> the electronic record against the printed text must
>> be standard
>> procedure. A computerized voting system with a
>> paper ballot is no
>> more secure than a computerized system without a
>> paper ballot if all
>> the checking is done by computer. So long as audit
>> procedures are in
>> place to check the printout against the electronic
>> record, malware has
>> a very low chance of success on a system with the
>> summary paper
>> ballot. The OCR/barcode debate doesn't matter in
>> this regard.
>>
>> 4) OCR may be no more transparent or secure than
>> using a barcode, but
>> it may appear more secure. Appearance is important
>> so this should
>> count for something. Most likely, the average
>> person understands no
>> more about how OCR software works than s/he
>> understands about how
>> barcode software works. On the other hand, barcodes
>> are ubiquitous --
>> trusted tools of commerce. It's not clear which the
>> public would
>> prefer. Trials and surveys are needed.
>>
>> 5) Our experience has been that people that raise
>> objections about the
>> barcode are usually objecting to machine counting
>> altogether -- these
>> people are often nontechnical. They want hand
>> counting instead. They
>> may be no happier with OCR. We also find that these
>> objections are
>> not necessarily unmoveable. Most people get over
>> the objection
>> without too much difficulty when it's explained how
>> the system works
>> and that manual checks will be in place to verify
>> that the readout
>> from the barcode matches the printed text.
>>
>> 6) OCR may be less accurate than barcodes. The
>> barcode with good
>> error detection should be 100% accurate. That is,
>> if you get a read,
>> the odds are astronomically high that it's right.
>>
>> 7) An OCR scanning station might be more difficult
>> for blind voters.
>> If the blind voter has to remove the ballot from the
>> folder to insert
>> it into some device, there is a risk that the voter
>> will drop the
>> ballot or have some other difficulty -- especially
>> considering that
>> blind voters sometimes have other disabilities. The
>> only way to
>> really find out would be to build both OCR and
>> barcode stations and
>> see which work better for reading impaired voters.
>>
>> 8) An interesting test I'd like to see: two
>> different mock elections,
>> one utilizing OCR and one with barcode. Set up the
>> verification
>> station for each. Will normal reading/sighted users
>> use the
>> verification station? Some small percentage would
>> use the
>> verification station for barcoded ballots. My guess
>> is that for the
>> OCR system, they will use it much less if at all.
>> In both cases, if
>> the mock election was repeated with the same
>> subjects, I predict that
>> usage of the verification stations would be less the
>> next time. It
>> may be that our verification station was for the
>> demo only.
>> Especially if we go to OCR, I don't think it would
>> be used enough to
>> justify setting up. This may be a good thing. If
>> we have one system
>> set up for voters that need the accessible system,
>> the verification
>> station may be integrated with that.
>>
>> 9) OCR print may compromise human readability of the
>> ballot. If
>> you're not worried about OCR, you can optimize the
>> text for
>> readability for humans. A fixed width font may work
>> best for OCR but
>> will be less efficiently read by humans. It may not
>> fit as easily on
>> the printout as a proportional font. If we adopt
>> User Centered Design
>> principles and place the voter as the primary user,
>> this may rule out
>> OCR.
>>
>> 10) Precinct level tabulation may be slower or more
>> expensive with
>> OCR. I suspect that a station to count, say, 500
>> ballots, will be
>> more expensive and/or take longer than a station
>> that reads the
>> barcodes with a hand-held scanner. Again, this is
>> speculation and
>> real data would only come with trials and
>> experiments.
>>
>> Summary
>> --------------
>> In summary, I still think the barcoded ballot with
>> manual verification
>> that the text matches the electronic ballot image,
>> is the most
>> efficient way to go. OCR does not eliminate the need
>> for the manual
>> check. Open source helps too but is not a cure-all
>> either.
>> OCR may be more saleable, on the other hand. Some
>> of the questions
>> may be approachable even without major funding. But
>> real answers to
>> some of the questions above would require some real
>> tests.
>>
>> I have no problem with the assertion that an OVC
>> production system may
>> not include a barcode. I would like to see some
>> trials though.
>>
>> Alan D.
>>
>> _______________________________________________
>> OVC discuss mailing lists
>> Send requests to subscribe or unsubscribe to
>> arthur@openvotingconsortium.org
>>
>
>
> --
> 10777 Bendigo Cove
> San Diego, CA 92126-2510
>
> 858-578-8842
>
> Work for the common good.
> My profile: <http://geocities.com/ekennedyx/>
> I blog now and then at: <http://ekennedyx.blogspot.com/>
> _______________________________________________
> OVC discuss mailing lists
> Send requests to subscribe or unsubscribe to
> arthur@openvotingconsortium.org
>
>

_______________________________________________
OVC discuss mailing lists
Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Sat Apr 30 23:17:09 2005

This archive was generated by hypermail 2.1.8 : Sat Apr 30 2005 - 23:17:22 CDT