Re: Sketch of Voting Tablet design

From: Arthur Keller <voting_at_kellers_dot_org>
Date: Thu Dec 13 2007 - 06:24:55 CST

I don't have comments yet on Alan's design, as I
have not yet studied it. However, I do wish to
point out this famous saying:

In theory, there's no difference
between theory and practiceŠ.
In practice, there is!
- attributed to Jan L. A. van de Snepscheut

There are many practical reasons why custom
enclosures and custom hardware configurations
make for a more successful implementation. One
of the important ones is the need for lightly
trained and often elderly pollworkers to quickly,
efficiently and correctly set up polling places.
Having been in charge of doing that a number of
times for polling places in Santa Clara County,
California, I can say that it is easier to set up
a self contained voting machine than it would be
to assemble a componentized PC will all the
necessary accoutrements for accessibility. That
being said, you can create custom enclosures and
custom hardware configurations that obey the
requisite interface standards that allow a
variety of input and output devices to be

Security concerns likely limit the availability
and functionality of interfaces one would want to
a voting machine. How much harm can be done to a
voting machine from an external USB interface?
Would a PS-2 keyboard and/or mouse interface
involve less vulnerability? Does a PS-2
interface allow connection of all the necessary
interface devices?

I have never had a voter request to use the
accessibility feature of the voting machine. No
one has asked to use the audio interface. While
I know how to set up the four button input device
(colored shaped on a small box), pollworkers in
Santa Clara County, California are not trained
how to set up sip and puff interfaces, for

The California Secretary of State's strong rules
regarding hand counting of DRE VVPATs will
greatly discourage their use in Santa Clara
County, California, where I understand that
election officials will prefer that no one use
the DREs and everyone vote on paper ballots that
will be scanned and counted centrally. The
single DRE per precinct will have a polltape
total posted from the VVPAT. That will be an
interesting process involving switching a sealed
VVPAT enclosure used when casting ballots with a
second VVPAT unit for printing the polltape that
will be removed, signed and posted.

Using Electronic Ballot Printers, especially ones
that produce ballots that are functionally
identical to hand-marked paper ballots, would
enable simpler central count or precinct count
optical scan systems.

So the challenge is to create an end-to-end
system that works not only in theory but also in

I hope to find the time to analyze Alan's
proposed new design. However, I'm wondering what
are the set of requirements for which the design
is intended to satisfy. Without starting with a
requirements document first, and a threat model
second, it is hard to evaluate objectively
whether Alan's new design is or is not a good one.

If we start with a design without objective
evaluation criteria, it is not clear how this
*process* is better than those used by commercial
vendors. Or if we write our requirements
documents based on the design we've created,
aren't that circular reasoning? Yes, there is a
big benefit to having an open, inspectable design
and implementation. But there is a far better
benefit to going through a formal development
process that starts with a requirements analysis.
Creating a rapid prototype is a reasonable
approach in the exploration of what is possible,
so that a requirements document can be created
where the intended stakeholders are informed of
what is possible. It is not clear to me whether
Alan is proposing to create a prototype or a
design that can be built and used. It's amazing
how often prototype designs get put into
production. IBM 360 JCL (job control language)
is an example of an abominable stopgap measure
that was then used for decades.

I do not claim that requirements and
specifications necessarily correctly reflect real
world needs and that iterative refinement is not
appropriate. I remind you of my message from

Best regards,

At 11:05 AM -0800 12/11/07, Edmund R. Kennedy wrote:
>Hello Alan:
> Why is a special device required for
>accessibility? I would think that it would be
>quite a bit easier to find ADA compliant
>interfaces for standard hardware than for some
>special device. While I'm not directly opposed
>to the idea, you haven't adequately explained
>the need for this special device.

Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA  94303-4507
tel +1(650)424-0202, fax +1(650)424-0424
OVC-discuss mailing list
By sending email to the OVC-discuss  list, you thereby agree to release the content of your posts to the Public Domain--with the exception of copyrighted material quoted according to fair use, including publicly archiving at
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
Received on Mon Dec 31 23:17:05 2007

This archive was generated by hypermail 2.1.8 : Mon Dec 31 2007 - 23:17:10 CST