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

From: Joseph Lorenzo Hall <joehall_at_gmail_dot_com>
Date: Sat Jul 29 2006 - 21:46:33 CDT

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.

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

> 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

> 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

> Best regards,
> Arthur
> At 6:31 PM -0700 7/29/06, Joseph Lorenzo Hall wrote:
> >Thanks again for great feedback. While the comparison to Linux is
> >easy to make, Linux was not an ugly commercial project and then
> >suddenly its source was opened. For example, could you imagine what
> >would happen in the short-term if all of Windows was released under
> >GPLv2only tomorrow? How could we take something like Windows (or
> >BallotStation and GEMS) and go from purely commercial to open source?
> >
> >I believe there needs to be some transitional procedure and I think
> >it's going to take the cooperation of a bunch of constituencies. I
> >also think that the transition should include a wider disclosure of
> >source code culminating in public disclosure. Something that makes
> >sense to me is if a vendor decided to voluntarily open its source to a
> >limited group of people* in order to encourage finding holes, flaws,
> >etc. and then after a round of that, to a wider group of people (say
> >technical activists) and then finally to go public. If anyone knows
> >of how a business has done something like this before and not
> >suffered, let me know. -Joe
> >
> >* And, yes, I'm not sure how the state or vendor or anyone chooses
> >these people. I've brainstormed about this and nothing seems
> >particularly good to me.
> >
> >On 7/29/06, Arthur Keller <> wrote:
> > > 8. If existing voting systems are so poorly written that they must
> >> rely on "security through obscurity," then the software in those
> >> systems should be replaced expeditiously with software (open source
> >> OR proprietary published software) that can withstand public
> >> scrutiny. The concept that existing systems should be kept secret as
> >> a security measure should be a stopgap towards their replacement, not
> >> a permanent artifact. And once these existing systems are replaced,
> >> then there is no reason why they should be publicly disclosed so that
> >> we can see for ourselves whether they were or could have been avenues
> > > for fraudulent activity.
> --
> -------------------------------------------------------------------------------
> 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

Joseph Lorenzo Hall
PhD Student, UC Berkeley, School of Information
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