Re: More on barcodes, etc

From: Edmund R. Kennedy <ekennedyx_at_yahoo_dot_com>
Date: Mon Apr 18 2005 - 17:29:43 CDT

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