Reflections on the election and implications for the OVC

From: Arthur Keller <arthur_at_kellers_dot_org>
Date: Wed Nov 03 2004 - 14:56:53 CST

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

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
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 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 Tue Nov 30 23:17:05 2004

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