RE: Why PIN or smartcard is REQUIRED

From: Popkin, Laird (WMG Corp) <"Popkin,>
Date: Mon May 17 2004 - 13:32:52 CDT

Comments below.

-----Original Message-----
From: owner-voting-project@afterburner.sonic.net
[mailto:owner-voting-project@afterburner.sonic.net]On Behalf Of Arthur
Keller
Sent: Monday, May 17, 2004 1:29 PM
To: voting-project@lists.sonic.net
Subject: RE: [voting-project] Why PIN or smartcard is REQUIRED

At 10:02 AM -0400 5/17/04, Popkin, Laird (WMG Corp) wrote:
>My wife provided technical support for a printer company for years,
>and based on her experiences, I wouldn't rely on the general public
>loading printers correctly. Many office workers call for help when
>the copier needs paper. :-)

As was reported earlier, voters use sheet feed equipment for ballots
already. Since we seem to be calling in our wives, I should point
out that my wife (who is an expert on Total Quality Management) says
that the *human* processes should be as simple as possible. If the
computer processes have to be made more complex, so be it.

---
I agree with her. My concern with having voters feed individual paper
ballots into the printers is that it raises all sorts of "operator error"
situations that are more controllable if the paper is pre-loaded in batches
by poll workers. Cheap consumer printers are pretty easy to mis-load with
crooked paper, etc., so by having the poll workers do the additional work of
pre-loading the paper, the voter's voting process gets significantly easier.
---
>I think that it'd be better to avoid the issue of paper handling on 
>the way into the printers, and pre-load the printers with a 
>sufficient number of pages to print a day's worth of ballots. I've 
>heard "70 ballots per voting station" quite a few times, which will 
>certainly fit in a high end printer. For really cheap printers, we 
>might want poll workers to load the printers, but since they can be 
>trained to load the printer and print a test alignment page, that 
>isn't too much of a concern.
>
>About scanning, my understanding is that we're proposing that 
>ballots are simple stored when the voter hands them in, and are 
>scanned as a batch when the polls close. Thus, the scanning would be 
>performed by a trained poll worker (and the software would reject 
>bad scans, duplicate scans, etc.).
The voter may use the BVA to validate a ballot.  That should be a a 
flat bed scanner, not a sheet fed scanner.  A flat bed scanner 
doesn't require that the ballot be taken out of the privacy folder. 
A sheet fed scanner does.  A flat bed scanner is probably cheaper 
anyway.
---
I forgot about the vote validation station (VVS, right?). Yes, those would
need to be scanned by the voters by definition. And I agree that a flatbed
scanner is friendlier (to the blind, etc.) than a sheet feeder.
---
>Personally, I like the idea of scanning the ballots immediately, in 
>which case I'd think that it's better to have the poll workers scan 
>the ballots, because voters are likely to have problems with which 
>paper orientation is correct. Also, is there any reason that we're 
>talking about sheet feed scanners instead of the (IMO) more obvious 
>handheld scanners? It's a lot easier and faster (and with fewer 
>moving parts, I think) to wave a "laser" scanner at a barcode than 
>to feed a ballot correct through a sheet feed scanner.
There are privacy implications of having the poll worker scan the 
ballot before the polls close.  The BRP should use a sheet fed 
scanner.
---
I've seen this said a couple of times. But what are the specific privacy
issues,
and why are they move of an issue for our ballots in privacy folders than
they
are for systems that currently scan ballots in real-time (e.g. optical mark
readers).
Admittedly the error rate for barcode scanning should be very low, but my
thought
is that real-time scanning will catch even those few errors while the voter
can re-vote.
Later, the error recovery method is a bit more work (read the printed text).
---
Under Ellen's approach with my mods, one could also rig up a flat bed 
scanner underneath the sheet feeder for the printer to ensure that 
the ballot was in the correct orientation and to determine the 
ballot-type.
---
This would help with pre-printed ballots. I'm not sure that we gain much
with pre-printed ballots (I guess they might be harder to pre-print) and
they make things more complex.
---
My wife also points out that most poll workers are retired and do not 
have very good eyesight, and many of them cannot handle the kind of 
exercise required to attend to a voting machine at the start of every 
ballot case.  Things get real busy right before and right after work. 
Especially after work, when the poll workers have been at it all day.
---
What do you mean by 'ballot case'? If you mean when a batch of paper is
loaded, if there are typically 70 ballots cast per machine, and the paper
tray can hold more than 70 ballots, we're not talking about a lot of paper
reloading, unless we're talking about really cheap printers with tiny paper
trays, I suppose. :-)
Don't the poll workers need to reset each machine for each voter? If there's
an issue with loading the paper, could there be an issue with requiring them
to punch in codes, etc.?
---
Best regards,
Arthur
>- LP
>
>-----Original Message-----
>From: owner-voting-project@afterburner.sonic.net
>[<mailto:owner-voting-project@afterburner.sonic.net>mailto:owner-voting-pro
ject@afterburner.sonic.net]On 
>Behalf Of
>steve.chessin@sun.com
>Sent: Monday, May 17, 2004 12:29 AM
>To: voting-project@afterburner.sonic.net
>Subject: Re: [voting-project] Why PIN or smartcard is REQUIRED
>
>
>  >Date: Sun, 16 May 2004 12:19:56 -0700
>>From: "Alan Dechert" <alan@openvotingconsortium.org>
>>Subject: Re: [voting-project] Why PIN or smartcard is REQUIRED
>>
>>Arthur,
>>
>>>  I'd like to figure out a way to make Ellen's system work.  It
>>>  is  cheaper than smart cards and has other benefits too.  ...
>>>
>>Fine, Arthur.  I also think it's worth looking at.  However, large trials
>>are needed to see how good/bad it is to have voters insert the paper.  I
>>predict big problems.
>
>I don't know that I agree.  Many jurisdictions today have
>precinct-based scanner systems, where the voter has to insert their
>ballot into the scanner.  I haven't heard of problems with those.
>
>Of course, the feed on those scanners is custom-designed by the
>vendors.  You're planning to use COTS printers, so Ellen's proposal has
>to work with COTS sheet-feeders.  At work we have Lexmark Optra S 1855
>printers.  They have a sheet-feed capability that seems fairly simple
>to use.  Of course, those printers are probably a lot more expensive
>than your design point.  I don't know what kind of sheet feeders are
>available in inexpesive printers.
>
>  >A person with gout will have a tough time.  Others with any of a number
of
>>disabilities will have trouble with it.
>
>There are no privacy issues with assisting someone in inserting a blank
>ballot into a printer, so I don't see this as an important factor.
>Once the paper is there, they can still vote privately.  Of more
>concern is if someone will need help getting the paper into the privacy
>folder.
>
>On the other hand, no one expects a voting system to be accessible no
>matter what the disability or set of disabilities.  Some people are
>going to require assistance no matter what.  (For example, HAVA doesn't
>require voting machines to be accessible to someone who is both vision-
>AND hearing-impaired.  Helen Keller would still require assistence to
>vote.)
>
>  >Even perfectly capable people will
>>fail to insert the paper far enough--when they go to print, the printer
>>won't grab the paper.
>
>Presumably the printer will detect this as a "no paper" condition
>and not attempt any printing.
>
>  >Some people will get it in a little crooked and their
>>ballot will be mangled.
>
>Then they declare it to be "spoiled" and try again.
>
>  >Pollworkers will spend a lot of time assisting people with this and the
>>people being assisted will feel dumb and will be turned off by the system.
>
>That's speculation.
>
>  >I'm not saying it's unworkable, but large scale human factors testing
would
>>be needed before using this live.
>
>As will the entire EVM.  But first, start with small-scale human
>factors testing.  Check out the single sheet-feed capability of various
>COTS printers.
>
>--Steve
-- 
----------------------------------------------------------------------------
---
Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA  94303-4507
tel +1(650)424-0202, fax +1(650)424-0424
==================================================================
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
==================================================================
Received on Mon May 31 23:17:50 2004

This archive was generated by hypermail 2.1.8 : Mon May 31 2004 - 23:18:16 CDT