Re: WHAT THE DEMO WILL DEMONSTRATE -- V.001

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Wed Aug 20 2003 - 18:57:12 CDT

Alan's document helps to clarify many of the issues surrounding the
purpose and requirements of the demonstration for developers and others
joining the project.

I believe that someone--probably either Matt Shomphe or I--should
produce a complementary document discussing the architectural decisions
we have made for the demo construction (Python, wxPython, MVC
design, XML formats, etc). While most of Alan's document applies
equally to the final system, the demo architectural details are subject
to revisitation prior to the production system.

One issue that WILL carry over to the final system falls between
requirements and architecture. The layout of a presented ballot
(including the various languages and the large font version), WILL need
to be approved by elections officials. That is, while we may produce
tools to automatically generate plausible or suggested ballot layouts,
the final layout needs to be human configurable (not, for example, only
flow automatically based on numbers of lines of text). The MVC
architecture already discussed privately between some developers
contemplates this requirement (and, in fact, for the demo, the layout
will be manually set to match Alan's sample).

I have a few comments that may be appropriate for inclusion in a revised
"What the Demo Will Demonstrate" document (however, I do not try to
phrase them in the tone of such a document, but rather to point list
members to the underlying concerns; i.e. probably they should be
rephrased).

|In this scenario, a PC remarketer could take existing PCs from
|inventory -- sanitize them, test them, deliver them to the polling
|places and then, after Election Day, put them back on the road to
|wherever they were headed.

This raises a security concern in my mind. And actual elections
district (hopefully) has a procedure in place to assure the physical
security of voting machines against alteration.

Assuming such multi-district re-use, a vendor would need similar
procedures to protect against tampering. And specifically, a vendor
should need to demonstrate the integrity of these procedures to voting
districts. The phrase "sanitize them" points in this direction, but I
think we should be fairly explicit about recognizing this issue.

|We'll probably use an inexpensive compact laser printer, like maybe an HP
|LaserJet 5L that can be had on eBay for 50 bucks.

We should not push the $50 ebay machine idea, IMO. I have a LJ6L a few
inches from me that suffered a terrible misfeed/jam problem for several
months (I eventually discovered that a physical part was available from
HP to fix the issue).

I'd sure rather spend $300-400 on a brand new model, selected
specifically for reliability, than save a few hundred and get paper
jams. This issue was raised by one elections officer quoted in the _San
Matteo County Times_ article posted by Dennis Paull.

|This will be achieved by the use of a bar code on the long edge of the
|printout (duplicated on opposite edges -- say within a half inch of the
|edge).

This raises an anonymity concern in my mind. While people are not
skilled at reading bar codes, it is not all difficult to memorize a
simple pattern.

For example, suppose that I wished to vote for G.Bush for the
first-listed (Presidential) race. After my own ballot was printed, I
might notice that the exposed edge started with:

   || | | ||| ...

And I might notice that someone else's started:

   | ||| | | | ...

Even without knowing the barcode system utilized, I can pretty much
memorize at a glance the difference between those two patterns. If I am
a poll worker, I have plenty of opportunity to see these exposed edges
as they are placed in ballot boxes.

>From there, I know quickly who votes the same as I do. In fact, after
I've seen that pattern two is more common than any other initial pattern
(other than maybe my own pattern one), I can make an awfully good
assumption that the second thing is a Democrat vote, rather than a
minor-party vote.

As well, ballots with write-in candidates will presumably require
considerably longer bar codes than will ones that only select standard
candidates. Even without recognizing specific patterns, it might be
obvious THAT someone voted for a write-in candidate (which partially
punctures ballot anonymity).

|Most touch screen systems literally have the voter touching the screen with
|their finger. Fingers are too broad to precisely locate a position on the
|screen. Fingers also transfer grease to the screen necessitating frequent
|wiping. Our touch screen printer will work with a stylus allowing for more
|precise location of the touch and eliminating the need to wipe the screen.

Some voters with neuro-motor handicaps have greater difficulty utilizing
a stylus than pointing with a finger.

|Selecting "Write-in" will bring up an on-screen typewriter. A QWERTY layout
|will appear on the top half of the screen (three rows plus space bar below).

I wonder if a QWERTY layout is well suited to voters who are not touch
typists. An alphabetical layout might be more appropriate.

|The printout will utilize "special paper." One measure could be dipping a
|corner of the ream of paper into an ink that no one would know in advance
|the exact color and composition.

A much greater degree of protection against false ballots can be
provided by the cryptographic protocol that I described in an earlier
post. Use of this protocol, of course, is not inconsistent with also
physically distinguishing the ballot paper.

At the least, I would request that Alan's document include the idea that
SOME cryptographic procedures can be used to prevent tampering or
substitution of physical ballots (i.e. I recognize that it is premature
to firmly commit to the specific protocol I propose; but cryptography in
general is certainly relevant).

Yours, David...
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Sun Aug 31 23:17:13 2003

This archive was generated by hypermail 2.1.8 : Sun Aug 31 2003 - 23:17:18 CDT