Re: Reflections on the election and implications for the OVC

From: charlie strauss <cems_at_earthlink_dot_net>
Date: Wed Nov 03 2004 - 15:47:32 CST

Arthur I think I addressed the same issue you raise here, in somewhat different form, in my own simmilarly titled observations on the election e-mail.

As I saw lines, electrical faliure and problems starting up in the morning are the issues. And OVC actually has or could have potential advantages in these areas.

Lines: lines caused by the sheer number of voters (and not other problems) come from one source alone: Not enough polling stations at the precint. How OVC addresses this: there are two ways. first, unlike other systems using an inflexible number of expensive polling stations OVC uses cheap, almost discardable (give them to schools) stations. Thus dynamically increasing the number of polling stations a few months before anticipated heavy turn-out is indeed a possibility. Just buy more cheap PCs. Yes you have to buy more screens too. But the point is there's no bottle neck in supply. And after the election you are not stuck with more machines than you need on hand for most elections.
   The second way OVC addresses this is philosophically. OVC is inherently about counting paper ballots. While its nice that it has some advantages with regard to tracking ballots electronicalling in the end you have paper ballots to handle, count and store. These are the same problems you have with tradional paper ballots. Thus one can see that a mixed scheme of OVC and tradional paper ballots is simpatico. It's not as inhomogenous as DRE+paperballots where the lines of ballot custody are different. What I am saying is that OVC will play nice in counties that want to mix it with optical scan. One might argue that if this factor alone is considered then the Vogue Autromark system fits the bill even better. I would not disagree, but this is not the only point to consider.

Electrical failure:
  Electrical failure can take three forms. Brief electrical outage, complete loss of power, and low voltage. OVC in its current implementation does not fair well on any of these marks. A breif electrical outage could be handled by UPS battery backup, but since OVC platforms are not designed with power miserly platforms this is problematic (this is one reason I gave in suggestng using something like a palm pilot as the platform--16 hour battery lifes). So one may need heavier duty solutions such as generators. And these can also deal with complete power loss. Low voltage is a subtle problem. Here in New Mexico in the last election we discovered that the screens on touch screens go out of calibration when the voltage dimms. (someone overloaded the lines in sandoval county and certain candidates were impossible to vote for on some machines). OVC is no better or worse than anyone else on that score.
    The good nesw for OVC on this score is the above simpatico relation with paper ballots. If you have to switch to paper ballots then your OVC trained poll workers are already prpared to deal with paper trial cusotdy issues.

Morning start up:
here OVC has some advantages. there are two ways to deal with morning startup issues in OVC. First, as mentioned above cheap ovc machines means you can have backups on hand. Currently In many places backups are in short supply, are kept in a central place and rushed to the scene of a probelem. But this can let perhaps 90 minutes of critical morning voting time pass with diminished service. Second, Because OVC deals with paper ballots and cross referenceing records and voter verification, there is much less pressure to have pristine machines. It should be possible to somehow create a set of OVC protocols that allow more extensive machine testing following a complete software install. for exmple if it boots from CD, boot it from CD, verfity it works, shut it down and it should work the next time. But if it does fail to start you can restart it again and again knowing that each time thmachine is prsitine

-----Original Message-----
From: Arthur Keller <>
Sent: Nov 3, 2004 12:56 PM
Cc: Karl Auerbach <>, Dow Patten <>,
        Amit Sahai <sahai@CS.Princeton.EDU>,
        "Peter B. Maggs" <>,
        "Douglas W. Jones" <>
Subject: Reflections on the election and implications for the OVC

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