Re: Principles of Open Voting

From: Arthur Keller <voting_at_kellers_dot_org>
Date: Sat Jul 02 2005 - 14:49:28 CDT

At 11:56 AM -0700 7/2/05, Alan Dechert wrote:
>>1. I'm not convinced that the choice of the ballot printer
>>architecture is part of the principles of "open voting."
>I consider the ballot printer architecture part of open voting
>because it's inexpensive. If a system is so expensive it's beyond
>the reach of jurisdictions, it doesn't qualify for open voting in my

Certainly, the existence of ballot printer architecture systems would
be a good thing. If Populex were open source, would that be open
voting? After all, that's a form of ballot printer architecture.

I think that openness should not necessarily imply a particular architecture.

>It's not clear to me that a ballot marking device costing $5,500 and
>weighing 65 pounds would be under serious consideration were it not
>for HAVA money available now. Voting systems must be inexpensive!

If each precinct in Ohio with long lines last November allowed
hand-marked ballots and had one ballot marking device that would have
been better than inadequate numbers of DREs. And it's the HAVA
requirements for accessibility that are pushing the expensive and
heavy ballot marking devices, not merely HAVA money.

>>I think that hand-marked optical scan ballots along with electronic
>>ballot markers for
>>blind/reading-impaired/language-accessibility/etc. is a perfectly
>>reasonable alternative architecture.
>Currently, we may have to work with these expensive electronic
>ballot markers because that's what can be done in the near term. In
>the long run, we want to offer something much better and much

Wanting to offer an alternative is fine. Saying that a previously
acceptable architecture is no longer considered "open voting" once a
"better" architecture is available does not sound reasonable to me.
There should be criteria for open voting based on openness. Cost
should not be a criterion for a system being considered open voting.
Rather, it's one of the evaluation criteria for jurisdictional choice
of system.

>>If someone wants to market a completely open and
>>secure/inspectable/auditable/etc. DRE with AVVPAT as part of an
>>open system, where they do AVVPAT right (for some reasonable
>>definition of right), why should we prevent such a company from
>>joining the OVC?
>I don't know how you can do AVVPAT right.

If AVVPAT has not been done right is not necessarily the fault of the
AVVPAT concept but its implementation. Suppose Rebecca Mercuri were
to write the specs and regulations, for example.

>Debra Bowen's bill, SB370, may change the equation slightly.
> "This bill would provide that on a direct recording
> electronic voting system, the electronic record of each
> vote shall be considered the official record of the vote,
> except that the voter verified paper audit trail shall be
> the official paper audit record and shall be used in the
> manual tally and any recount."
>While this language confuses the notion of "fundamental
>representation" of the vote, it would require that the printout roll
>be counted for the mandatory one percent random audit. If SB370
>passes and is enforced, it will make our ballot printer architecture
>look good.

I think we need to separate out the notion of open voting from the
notion of the "Dechert" architecture. After all, OVC's first CTO
Doug Jones proposed the term "Open Voting Systems" be plural. It is
clear that a properly implemented Dechert-architecture system is an
Open Voting system. It's not clear to me that the only Open Voting
systems will be those with Dechert-architectures.

>>2. To me, the notion of "open voting" have much more to do with the
>>use of open (inspectable/published) source, open processes, open
>>specs and requirements. I personally don't have the revulsion that
>>some others do to proprietary systems as long as they are
>>completely open to inspection by anyone and that no trade secrets
>>are employed (other than to the values of security codes and locks).
>Insofaras proprietary systems for voting increase costs, I don't
>want them. Voting systems need to be inexpensive.

You deleted my next sentence as reasons for using proprietary components.

"Similarly, if some degree of non-commodity (or even proprietary)
hardware (such as enclosures) considerably reduces the weight,
usability, security or deployability of an otherwise open voting
system, I would not rule it out provided that the designs and specs,
etc., were publicly inspectable."

Cost is to me not the only issue. Weight, usability, security and
deployability are, potentially among others, reasons for using
non-commodity (or even proprietary) hardware. For example, the most
of the components of a PC are industry standard. Is it necessarily a
bad thing to create a custom enclosure integrated with the computer
case to reduce weight and size if it had a minimal effect on cost?
If it increased the cost by $100 each but meant you would need 2
people to deliver and set it up rather than 3 people, is that
acceptable? While it should be a goal to reduce the total cost of
ownership, cost should not be one of the criteria for being an open

>The definition of OPEN VOTING SYSTEMS submitted to NIST by OVC CTO
>David Mertz, said "entirely COTS." Actually, I didn't necessarily
>want "entirely" in there. There may be enclosures and such that
>work with an open voting system that are specifically designed for
>the poll site. On the other hand, such enclosures may have
>non-voting applications so may be considered COTS -- depending.
>We debated the OPEN VOTING SYSTEMS definition some time ago. We
>started with the Irwin Mann definition and added a few tweaks. As
>far as I am concerned, this stands as official OVC.

That's why I started this section of comments with "to me." I'm
sorry I did not have the time then to participate fully in that

>>4. Digressing further, I want to make the distinction for open
>>source of open to public inspection vs. open to public
>>contribution. It is my intention that the systems developed by
>>UCSC be open to public inspection and that the "public" may
>>contribute through commenting, testing, bug reporting, discussion
>>groups, reviewing, etc. ......
>Yes. Furthermore, proprietary disclosed source is not what we're after.
>>Unlike our current EVM2003 prototype, I am not envisioning the
>>software development to be by a cadre of part-time volunteers.
>Right. Nonetheless, the open source community (1 million engineers
>now signed up on Sourceforge), could be a great help in testing. We
>may also expect to receive valuable suggestions from the open source
>community for on-going improvement and maintenance of the software.

Certainly public testing is important. I would like there to be a
paid liaison as part of a UCSC project that would provide outreach
specifically for public testing and filter bug reports and fix
suggestions back. That person would first serve as a liaison for
dealing with public comments on requirements, specs, and

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
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 Sun Jul 31 23:17:12 2005

This archive was generated by hypermail 2.1.8 : Thu Sep 15 2005 - 11:43:09 CDT