Re: More on barcodes, etc

From: Ron Crane <voting_at_lastland_dot_net>
Date: Mon Apr 18 2005 - 18:15:31 CDT

Thanks. That's useful information, if rather disconcerting. After I
formalize the Shamos rebuttal I'll see what else I can do to push
things forward.

-Ron

On Apr 18, 2005, at 3:29 PM, Edmund R. Kennedy wrote:

> The software is open source and freely available.
> However, someone will have to customize it for each
> election authority. The understanding was that unless
> there were talented staff in a County Registrar's
> office that local officials would turn to a private
> sector consultant to get the equipment and software
> mated, design the ballots and provide support. The
> idea of 'OVC' certified consultants was also
> discussed. Finally there was a great deal of
> discussion regarding MD5 and similar things as a tool
> to keep a consultant from fiddling the election.
>
> As for the schedule, I look forward to the results of
> the May meeting in Silicon Valley. Personally, not
> seeing any obvious program since the demo has been a
> source of frustration to me. I'm especially
> frustrated since I'm reasonably sure that the Diebold
> TSx is going to get recertified in California as soon
> as this summer. The large election machine vendors
> have been quietly sowing up the market while we write
> email to each other which makes it more and more
> difficult for anyone to sell the EVM to some county
> officil who has just bought a quarter million dollars
> worth of private sector polling equipment with mostly
> federal money.
>
> I've not done programming since PERL was the coming
> hot thing and was never very good at that. In the
> meantime I am trying to develope a relationship with
> local election officials in San Diego County and work
> on Meet-Ups. Perhaps you could try something like
> that in your home town?
>
> Thanks, Ed Kennedy
>
> --- Ron Crane <voting@lastland.net> wrote:
>
>> On Apr 18, 2005, at 2:53 PM, Edmund R. Kennedy
>> wrote:
>>
>>> Hello David:
>>>
>>> Is the Archive working well enough for me to
>> direct
>>> Ron to it?
>>
>> And the upshot was? I am ecstatically over-blissed
>> at being referred to
>> the archive when a few sentence summary of the
>> current state by someone
>> knowledgeable would serve. Perhaps instead of
>> spending my time
>> formulating a rebuttal to Shamos's article, I simply
>> should have
>> referred everyone to the archive?
>>
>>> Ron, we have explicitly discussed the first item
>> in
>>> the last 12-18 months. As for the second, were
>> you
>>> volunteering?
>>
>> No. Are you? Is anyone? I have seen the "strategic
>> plan", but it
>> contains no solid information on development. Is
>> there none?
>>
>>> Thanks, Ed Kennedy
>>>
>>> --- Ron Crane <voting@lastland.net> wrote:
>>>
>>>> This nicely segues into the question of who
>> actually
>>>> will produce
>>>> systems based upon our software, and what degree
>> of
>>>> trust attaches to
>>>> that relationship. It also raises the question of
>>>> when our software is
>>>> going to be available, which leads to a
>> discussion
>>>> of milestones and so
>>>> forth.
>>>>
>>>> -Ron
>>>>
>>>> On Apr 18, 2005, at 1:22 PM, Edmund R. Kennedy
>>>> wrote:
>>>>
>>>>> Hello Arthur:
>>>>>
>>>>> Hello OVC:
>>>>>
>>>>> This brings us nicely to the issue of who our
>>>>> customers are. Ideally, the voter is our
>>>> customer.
>>>>> However, the decision makers will likely be in
>> the
>>>>> County Registrar of Voters office (or =). Also,
>>>> the
>>>>> County officials cannot consider the EVM unless
>> it
>>>> is
>>>>> certified on the Federal and State levels. I
>>>> think
>>>>> this sequenced identification of customers is
>> the
>>>>> lesson that the DRE vendors know and we may yet
>>>> have
>>>>> to learn.
>>>>>
>>>>> Thanks, Ed Kennedy
>>>>>
>>>>>
>>>>> --- Arthur Keller <voting@kellers.org> wrote:
>>>>>
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>
>>>
>>>
>>> --
>>> 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
>>
>
>
> --
> 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:10 2005

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