Re: Principles of Open Voting

From: Alan Dechert <dechert_at_gmail_dot_com>
Date: Sat Jul 02 2005 - 13:56:51 CDT


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

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!

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

> 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. SB1438 explicitly declares that
the "paper record copy" produced by the paper audit trail printing mechanism
is NOT A BALLOT. This non-ballot is unacceptable. I think it's clear that
open voting principles require "hard copies of ballots" (as Irwin Mann put
it ).

While requiring that DREs print the paper audit trail, SB1438 says
absolutely nothing about what is to be done with this paper record.
Furthermore, SB1438 gives no specifications related to paper handling
properties of the record.

It appears that the "paper record copy" promulgated by SB1438 and Kevin
Shelley's guidelines issued a year ago is intended to go unused. The
printing mechanism appears to be designed as training wheels for DREs -- to
be discarded once people see the electronic record always matches what's

In addition, preserving the order of the vote on the roll may violate basic
election code that guarantees the right to a secret ballot. I don't think
it would survive a serious challenge.

In short, AVVPAT is a bad idea. I don't think it's worth trying to make it
work. We may have to tolerate them for a few years until DREs can be
replace (or turned into ballot printers).

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.

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

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.

> 3. Some of the existing voting machine vendors are likely to continue in
> that business. While I want new vendors to be established using the
> systems created by or for the OVC, I believe the movement is better off if
> we collectively try to get some of the existing vendors to adopt open
> voting principles than if we refuse to work with any existing vendor.
No disagreement there. That's perfectly consistent with our strategic plan.

> After all, if an existing vendor joins the OVC, is the vendor co-opting
> the OVC or is the OVC co-opting the vendor? Probably both. What's
> important is that the OVC stand up for principles of openness and not be
> lured by the potential payments that might come from membership by
> existing vendors.
Yes, fine. Old news.

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

> First, it is hard to keep to a schedule with volunteer software
> development. Second, typical open source contributory software development
> is made possibly by the employers of the contributors covering the cost of
> the employee/contributor's time. That isn't in general the case here.
> (Jan may be an exception.) One should no more expect to write portions of
> the production central tabulator than should one expect to write portions
> of the next release of the Linux kernel. Selected and vetted volunteers
> will be engaged (just as is done with the Linux kernel) and contributions
> will be reviewed by paid staff who will be responsible for developing
> quality systems on time and within budget. Anyone will be able to make
> comments, suggestions, bug reports, etc., but the specs and code won't be
> a Wiki editable by just anyone. After all, we must insure that some
> "volunteer" does not introduce a trapdoor or intentional flaw at the last
> minute in order to harm the effort.

Alan D.

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