Re: Specifications

From: Ed Kennedy <ekennedyx_at_yahoo_dot_com>
Date: Mon Dec 13 2004 - 21:52:39 CST

Ken Pugh wrote:
> Ed,
>
> 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).

No, could you please explain.

>At this level, the
> features required of an operating system or a particular language are
> important, but not the actual O/S or language.

Yep, I was just trying to codify what people were saying at the time. One
of the biggest headaches of this sort of effort is the constant reinventing
of the wheel.

>
> Results may be sent via Access database format, comma-delimited
> files, XML, or some standard format.

Results from what? The polling place level canvassing system? I think we
were planning to hand carry these to what we've generically called,
"Election Central" typically, the County Registrar's office. The 'we' would
consist of one member of each party to keep an eye on the other one(s). I
guess we might have to use a van in San Francisco.

They could be sent via ftp,
> http POST, email or a custom protocol.

>From where to where? From election central to the Secretary of State might
be acceptable but from anywhere else to anywhere else, the design is network
phobic for security reasons.

> 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.

Multiple copies, cross signing? While I can imagine what you might mean,
why not make it easy for me. I'm just a middle aged bureacrat after all.

>
> 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).

The idea had been to not only print the ballot but also to write them to a
US B memory stick and to the program/ballot source CD. These were intended
to be the backups.

> 2.) There will be no accessible input or outputs to/from the unit
> other than the printer connection, the monitor, and the mouse.

Why a mouse with a touch screen?

> 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.

see item 1. Also, we had in mind put the CPU in a locked basket under the
table.

> 4.) The communications protocol needs to prevent non-authorized
> machines from transmitting data.

See my discussion about being network phobic.

Thanks, Ed Kennedy

>
> Ken
>
>
> At 11:34 AM 12/13/2004, you wrote:
>
>
>
>> Hello Ken:
>>
>> <http://gyaku.pair.com/vote/drupal/?q=book/view/87>http://gyaku.pair.com/vote/drupal/?q=book/view/87
>> & http://gyaku.pair.com/vote/drupal/?q=book/view/88 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 <kpughmisc@pughkilleen.com> 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 failure
>> 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.
>> Ken
>>> _______________________________________________
>>> OVC discuss mailing lists
>>> Send requests to subscribe or unsubscribe to
>>> arthur@openvotingconsortium.org
>> _______________________________________________
>> OVC discuss mailing lists
>> Send requests to subscribe or unsubscribe to
>> arthur@openvotingconsortium.org --
>> 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
>> arthur@openvotingconsortium.org
>
>
> _______________________________________________
> OVC discuss mailing lists
> Send requests to subscribe or unsubscribe to
> arthur@openvotingconsortium.org

_______________________________________________
OVC discuss mailing lists
Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
==================================================================
= 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