Re: More on barcodes, etc

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

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