Re: Reflections on the election and implications for the OVC

From: laird popkin <lairdp_at_gmail_dot_com>
Date: Wed Nov 03 2004 - 15:17:19 CST

Interesting.

My immediate reaction is that this isn't that far from the current OVC
architecture, except that:
1. OVC uses barcodes to encode the vote data instead of optical marks
("fill in bubbles"). It'd be straightforard (i.e. an implementation
issue, not architectural) to print out simple marks instead, though in
that case you lose:
   - some voter privacy (poll workers and other voters can see read
your votes from the dots more easily than they could from barcodes).
People live with this now anywhere that they use mark sense readers,
since poll workers in the polling station (or central location) can
read all of the ballots.
   - limit ballot complexity, and additional data captured, because
you can't encode as much data into "bubbles" as you can in a barcode.
2. OVC also captures and collects electronic vote records, which
allows for a level of double-checking of voting station records with
tabulation station records. Admittedly, since the printed ballot is
"the truth" the digital vote records aren't critical, but it's nice to
be able to audit the ballot printing, collection and scanning.

In both cases, I think you're proposing appealing (to me)
simplification of the current OVC architecture, though with some
important tradeoffs that probably bear further discussion.

On Wed, 3 Nov 2004 12:56:53 -0800, Arthur Keller <arthur@kellers.org> wrote:
> These are my personal observations and do not represent the official
> position of the OVC. However, I am cc'ing members of the OVC board
> for their consideration at the next board meeting.
>
> I'm writing this message on an airplane, so I've not read email or
> the web since about 5:45am this morning Pacific time.
>
> In yesterday's election, there were reports of scattered identified
> problems with electronic voting machines. Of course, since the DRE
> voting machines did not have a paper trail, it is hard to tell about
> some of the failures. I look forward to the reports from Vote Watch
> on the statistical analyses based on exit polling.
>
> The most prevalent failures were (1) the DRE's are slow to use and
> caused there to be long lines, (2) power failures that prevented use
> of DRE's, and (3) failures of the machines to come up properly or to
> be shut down prematurely due to machine or clerk error. In addition,
> failures of two optical scan ballot counters in Iowa delayed the
> reporting of the results from that state.
>
> The Dechert design, which was roughly adopted for the OVC prototype,
> does not convincingly address these three prevalent modes of failure.
>
> So a review (and potentially revision) of the requirements and
> implications of these requirements is in order. Here are my list of
> requirements.
>
> 1. The system must involve a paper ballot.
> 2. The system must allow the casting of a ballot by a visually or
> reading impaired voter.
> 3. The system must have a way to prevent or at least check for
> overvotes and undervotes.
> 4. The system must provide a way for the voter to verify
> independently that the ballot properly reflects the voter's intent.
> 5. The system must support both automatic and manual tallying of
> ballots, including recounts.
> 6. The system must support provisional ballots.
> 7. The system must accommodate absentee ballots.
> 8. The system must be open source.
>
> Here are my list of desiderata.
>
> 9. A voter should be able to cast a ballot even if and when there is
> a power failure.
> 10. The system should have a consistent way of tallying regular,
> provisional, and absentee ballots, as well as hand-marked regular
> ballots.
> 11. It should be possible to canvas the ballots in public.
>
> Based on these requirements and desiderata, I draw the following conclusions.
>
> a. Absentee ballots are probably optically scanned, mark sense ballots.
> b. It is desirable for there to be a manual way for a voter to mark a
> ballot, if the power goes out or the lines get too long.
> c. If the system entirely uses optically scanned, mark sense ballots,
> then all ballots can be processed the same way.
>
> So I personally have been drifting towards this architecture.
>
> i. All optically scanned, mark sense ballots.
> ii. Sighted voters can mark their ballot by hand if they wish.
> iii. Voters who want a computerized interface, such as visually or
> reading impaired voters, can use a Computerized Ballot Marker.
> iv. Any voter should be able to use a Ballot Verification Station,
> which checks for overvotes and undervotes, and displays the voter's
> choices on the screen or "speaks" them through a headset.
> v. Precinct-based optical scan, mark sense tallying system that
> checks for overvotes, securely stores the paper ballots, and prints
> precinct totals for posting.
>
> I propose that the OVC consider building open source software (and
> designing hardware) for the Ballot Verification Station, followed by
> building open source software (and designing hardware) for the
> Computerized Ballot Marker, and then build an open source optical
> scan system. Finally, replace the county (or other jurisdiction)
> based tallying system with an open source version.
>
> Comments are welcome.
>
> Best regards,
> Arthur
>
> --
> -------------------------------------------------------------------------------
> Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA 94303-4507
> tel +1(650)424-0202, fax +1(650)424-0424
>

-- 
- Laird Popkin, cell: 917/453-0700
==================================================================
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
==================================================================
Received on Tue Nov 30 23:17:05 2004

This archive was generated by hypermail 2.1.8 : Tue Nov 30 2004 - 23:17:43 CST