Re: The Bill -- version A

From: Ron Crane <voting_at_lastland_dot_net>
Date: Thu Jan 26 2006 - 13:22:41 CST
Joseph Lorenzo Hall wrote:
On 1/25/06, David Jefferson <> wrote:

I don't want to offer any language, since I serve the current SoS.  But I
think you think about want to changing your draft a little in the following

1) You want the SoS to make all of the code and related materials public as
part of the application for certification, i.e. the SoS should be mandated
to disclose the information at the time the application is submitted,
irrespective of what the vendor does.  The way you have written it, the SoS
cannot certify until the code is public; but at that point it is too late!
We need the public to be able to see the code before the certification
decision is made, so they can influence the decision.

2) I think you want the requirement that the code be made public to apply
retroactively to all currently certified systems, not just future
certification applications.  If a vendor declines, then the currently
certified system is decertified.

I'm writing a long paper, that is now in first-draft form, about
transparency and open sources in electronic voting.  I can't publicly
disseminate the paper yet as I have a co-author and it's still not
ready for that.

However, one of the points I make is that there are a few lines of
jurisprudence (past law and judicial opinions) that make compelled
retroactive disclosure a bad idea.  
You must be referring to the 5th Amendment's prohibition on compelled self-incrimination. I'd love to hear vendors argue that one.

Judge: I'm not sure I understand your objection to the requirement that you disclose your source code.
Vendor: Um, well, you see, your honor, it infringes our, um, 5th Amendment rights.
Judge: Which one in particular, counsellor?
Vendor: Um, uh, can I approach the bench?
Judge: Is this privileged information?
Vendor: Um, uh, um....
Judge: Or is it merely embarrassing?
Vendor: Um....
Judge: This is the public's court. The public has a right to supervise what we're doing here, and it has a right to know what claims and defenses litigants are asserting. So which 5th Amendment right do you contend this requirement infringes?
Vendor: Um,
Judge: Out with it, or I'll be forced to conclude you've waived this defense.
Vendor: All right. It'd infringe our right against compelled self-incrimination.
(To be clear: here, David is not
suggesting that; he's suggesting that the requirement be made
retroactive with the vendor able to decline, which would not run into
the specific problem that I'm talking about.)  The point is that a
regime like what is put forward in this draft bill is not nearly as
easy or desirable of a proposition as you may think.

Some of you will be disappointed to learn that I come away advocating
mandatory disclosure of sources and technical information to a subset
of the population (there would be an application and contract process
for review) and that the results of any analysis done by people with
access must be public.
I'm interested in your reasoning. Why shouldn't the public be able to review the software that handles its votes? Why should vendors -- who, after all, are really fiduciaries of the public trust of handing our votes -- be able to hide what they're doing? Why should the public be forced to trust the "experts"?
Anyway, I hope to share more about my paper within a month or so. -Joe

3) You need to require all documentation, both user and technical
documentation, to be made available as well as code.

4) I think your draft should make it clear that the vendor retains all other
intellectual property rights he may hold except right to keep the source
code and ancillary information secret.  That may go without saying, but
unless you say it you will be in for a lot of useless argument.

5) You might want to require the SoS to put a system in place so that the
public can notify him/her of any problems discovered in the code, or
complaints--and to require that the SoS must evaluate all such submissions
in a timely manner.  The public complaints, and the SoS evaluations thereof,
should become public after a suitable delay, except maybe within a short
period before an election.  This is important because the argument will
surely be made that by making the code public any security vulnerabilities
will also be findable by the bad guys.  You need to be able to say that the
same procedures and conventions that work in other software contexts for the
reporting and correction of bugs and vulnerabilities will also be in place
here for voting system code.

6) I think you want to be careful in using the term "voting specific" to
describe the code that has to be disclosed.  I know what you are trying to
get at, but you don't want to leave any room whatsoever for vendors to argue
that their code is not "voting specific".  For example, is the scanner code
that converts scan images to bits in a table "voting specific"?   It is,
after all, usable for other purposes, e.g. digitizing standardized exam

Best of luck with this effort,

On Jan 25, 2006, at 7:39 AM, Alan Dechert wrote:


a) By June 30, 2007, the Secretary of State shall not approve a voting

system for use in a public election until all details of the inner workings

of the system are publicly disclosed.

b) By June 30, 2007, while applying for voting system certification in the

State of California a vendor shall have an implied or express provision


 i) To any and all residents of the State of California the right to inspect

and test such Voting System, to retain test materials, test results, and to

freely publish the same openly.

 ii) The Vendor shall promise to refrain from exerting any copyright, trade

secret, or other rights that it may have to hinder any resident of the State

from exercising the right to inspect, test, and publish.

c) The Vendor may require reasonable notice of public testing and may

require that the tests be performed in a matter that does not burden the

vendor with significant costs beyond those of making the Voting System


d) The materials to be made freely available to the public include:

 i) All voting system specific source code

 ii) Detailed instructions for building the software, including compiler

used, compilation scripts, checksums

 iii) For voting specific hardware, complete specifications, drawings and

schematics must be made available

 iv) General purpose COTS components must be described in detail, including

versions and dates of manufacture

e) By June 30, 2007 the Secretary of State shall establish and maintain a

page on the Internet to provide the following:

 i) Free download of materials pertaining to each voting system certified or

under consideration for certification

 ii) A system for acquiring and processing input from the public

 iii) A reporting system to inform the public on findings, problems

reported, problem resolution, comments from the Secretary of State, the

public, and vendors

 iv) Standards used by the Secretary of State for evaluating voting systems

including test plans and specific test cases employed

For purposes of this article, the following terms shall have the following


a) "COTS" means Common Off-The-Shelf component that is manufactured in large

quantities and is widely available.

b) "General purpose COTS devices" -- a COTS component intended for use in a

variety of non-voting systems

c) "Voting specific" hardware or software means a component manufactured

specifically for use in a voting system

d) "Vendor" -- Any person, partnership, corporation, or other entity that

offers a Voting System, whether for money or not, to the State of

California, to any county or city of the State of California, or to any

government agency.

e) "Voting System" -- Any computerized machinery used in a Public Election

to present one or more Contests to voters, to obtain voter choices, to

verify voter choices, to store voter choices, to communicate voter choices,

to tabulate voter choices, or to present partial or full results of one or

more contests.

f) "Source code" -- computer instructions written by programmers

OVC-discuss mailing list


Joseph Lorenzo Hall
PhD Student
UC Berkeley, School of Information (SIMS)
blog: <>

This email is written in [markdown] - an easily-readable and parseable
text format.

OVC-discuss mailing list


OVC-discuss mailing list

= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Mon Jan 8 20:24:34 2007

This archive was generated by hypermail 2.1.8 : Mon Jan 08 2007 - 20:24:39 CST