Re: Specifications

From: Ken Pugh <kpughmisc_at_pughkilleen_dot_com>
Date: Mon Dec 13 2004 - 20:44:02 CST


I took a look at the references you mentioned. Most of the points appeared
to refer to a specific architecture. I guess I'm trying to specify the
system from the user-centric perspective (sort of like use cases, if you're
familiar with them). At this level, the features required of an operating
system or a particular language are important, but not the actual O/S or

Results may be sent via Access database format, comma-delimited files, XML,
or some standard format. They could be sent via ftp, http POST, email or a
custom protocol.
What is important on the level I'm trying to focus on is that they be
printed out prior to connecting to the communication system so that copies
be cross-signed and distributed to a number of poll workers.

There are certain features that would be necessary from a security aspect
that are not readily apparent to the voter or poll worker. These might
include features as:

1.) All ballots will be stored in two separate physical types of storage
(for backup).
2.) There will be no accessible input or outputs to/from the unit other
than the printer connection, the monitor, and the mouse.
3.) There will be an input/output device that is accessible only by
physical key. This device will be used to import/export data from the
computer via a secure mechanism.
4.) The communications protocol needs to prevent non-authorized machines
from transmitting data.


At 11:34 AM 12/13/2004, you wrote:

>Hello Ken:
>& is the link to some
>previous work that's been done on specifications. There are also other
>items that are like speicifications in the wiki. Perhaps you could try
>and incorporate these? Admittedly, not all of them hang together.
>Thanks, Ed Kennedy
>Ken Pugh <> wrote:
>Based on Ed Kennedy's stepping stone, here are some suggested
>features/specifications for the system. These are user-related features.
>They do not include security-related aspects.
>* Voting machine level
>a.) Uses or produces paper ballots.
>b.) Votes should be electronically tabulated during normal voting times or
>shortly thereafter
>c.) Detects invalid ballots (over-votes or illegible ballots)
>d.) Provide for sight-impaired voters a means of voting using audio.
>e.) (Optional) Detects under-votes and provides for correction
>f.) (Optional) Should permit voting even in the event of power or equipment
>g.) (Optional) Works the same for absentee ballots as for regular ballots.
>On the precinct level
>a.) Provides for paper vote totals at the precinct level
>b.) Precinct totals should be postable to the web for voter review.
>c.) Tied back to the voter check-in procedure to insure that the vote
>totals agree with the check-in. In the event of discrepancies, the totals
>must be reconciled.
>* Vote tabulation
>a.) Vote tabulation system should have checks to insure that all precincts
>have reported and that the precinct vote totals are reasonable in regards
>to voter registration and past history.
>b.) Numbers for voter-check-in and vote-totals are entered by separate
>processes. Numbers cannot be manually manipulated.
> >_______________________________________________
> >OVC discuss mailing lists
> >Send requests to subscribe or unsubscribe to
>OVC discuss mailing lists
>Send requests to subscribe or unsubscribe to
>10777 Bendigo Cove
>San Diego, CA 92126-2510
>"We mus! t all cultivate our gardens." Candide-Voltaire
>OVC discuss mailing lists
>Send requests to subscribe or unsubscribe to

OVC discuss mailing lists
Send requests to subscribe or unsubscribe to
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Fri Dec 31 23:17:12 2004

This archive was generated by hypermail 2.1.8 : Fri Dec 31 2004 - 23:17:22 CST