Re: Respose to Joe Hall: Transparency and Access to Source Code in Electronic Voting

From: Arthur Keller <voting_at_kellers_dot_org>
Date: Sat Jul 29 2006 - 23:47:20 CDT

At 7:46 PM -0700 7/29/06, Joseph Lorenzo Hall wrote:
>On 7/29/06, Arthur Keller <> wrote:
>> It appears that you agree with my point 8 below.
>I'm not sure if I have enough information to explicitly agree with
>your point 8. I think it's highly plausible given what I've seen
>(although I don't make a habit of reading source code).
>Of course, anywhere you have a free market, you will have trade
>secrets*. Maybe you mean to reject trade secrets in voting system
>software? If the software is ever disclosed (as DESI's was) any trade
>secrets are no longer valid.

I mean no trade secrets in voting system software, firmware, designs,
specifications, etc. Full disclosure, period.

>* Note that the definition of a trade secret is pretty broad. UTSA
>defines "Trade secret" to mean information, including a formula,
>pattern, compilation, program, device, method, technique, or process,
>that: (i) derives independent economic value, actual or potential,
>from not being generally known to, and not being readily ascertainable
>by proper means by, other persons who can obtain economic value from
>its disclosure or use, and (ii) is the subject of efforts that are
>reasonable under the circumstances to maintain its secrecy.
>> I'm not suggesting that Windows or BallotStation of GEMS *become*
>> open source or be licensed under GPLv2. To do so would remove the
>> proprietary nature of those systems. I have no objection to
>> intellectual property rights over software. What I do object to is
>> trade secret protections for voting systems.
>Regardless of the proprietary claims that could be made, would it be
>wise from a security perspective to simply disclose the Windows or
>BallotStation+GEMS code without some other vetting process that
>gussies it up for the sunshine of public scrutiny? Your proposal
>below is definitely worth further consideration... instead of taking
>code and vetting it for public disclosure, you're advocating replacing
>code. That would probably be less work, from what I've seen in
>Silicon Valley with companies trying to release existing codebases
>under open source licenses (usually, it's tracking down contributors,
>etc.; not ensuring that bugs and backdoors are minimized).

The vendor should not need anyone's permission to publish the
software it developed or contracted for. The goal should be complete
public disclosure with no passwords stored in the code at all. Once
the software is replaced, there is no longer any security risk in
disclosure. But the full disclosure of the replaced software is
useful for restoring our faith in the electoral process or in
confirming our fears. There is no need to gussy up replaced
software. Let's see it, warts and all.

> > So here's my proposal:
>> 1. Escrow existing voting system software, firmware, and designs.
>> 2. Vendors may choose to fully disclose their software, firmware, and
>> designs other than security passwords or to replace systems with
>> publicly developed open source software designed to be disclosed.
>Is the idea here that they could keep their trade secrets in their
>software, firmware and designs if they replace them with disclosable

No, the idea is to defer disclosure until the disclosable replacement
system in put into practice. Once the old system is replaced, what's
the harm in full disclosure once that code is no longer running? The
choice to replace systems with publicly developed open source
software is to DEFER disclosure until the replacement is done.

> > 3. Election officials contract for the construction of a complete
>> system for the entire voting process of open source software.
>> 4. Vendors deploy fully disclosed systems (either their own or by
>> including the publicly developed systems).
>> 5. The escrowed systems are disclosed either by vendor choice or when
> > they are replaced with publicly developed systems.
>> Public disclosure of vendor systems once they are replaced by
>> publicly developed software should not pose any security risk, but
>> will aid researchers in investigating whether there were backdoors or
>> other security problems with existing systems.
>The vendors should be able to opt out of having their code disclosed
>at all. Is that in here? -Joe

I think that if any vendor that refuses to release its code at all
should not be in the market for selling voting equipment. Delaying
public release of the software is acceptable only with the agreement
to replace that software with publicly disclosable software, and then
full disclosure once it is replaced. Refusing ever to disclose
software begs the question of what is there to hide. Eventual full
disclosure is needed to confirm or refute the conspiracy theorists.
Eventual full disclosure is will make evident the benefit gained, if
any, in replacing the previously trade secret voting systems with
open source voting systems.

I argue that government funding of open source voting system
software, etc., will allow vendors to replace existing software not
good enough to be disclosed with software designed to be so reliable
and secure that there is no harm in disclosing it. It should benefit
the honest commercial voting machine vendors, as the government will
do the R&D for them. It will also benefit election officials, as it
will enable competition in downstream services and maintenance. The
resulting savings from the competition should more than offset the
cost of development of the open source systems in the first place.
The modern software development methodology should result in systems
that have better usability, are more secure, and restore the faith in
the electoral system. The adoption of interoperability standards,
such as the emerging IEEE P1622 standard, designed in as part of a
new built-from-scratch software system will allow the creation of
third party audit tools, just as there are third party tools for the
relational database market.

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 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 Jul 31 23:17:08 2006

This archive was generated by hypermail 2.1.8 : Mon Jul 31 2006 - 23:17:10 CDT