Re: Is Open Source Enough?

From: Arthur Keller <voting_at_kellers_dot_org>
Date: Tue Sep 04 2007 - 23:19:33 CDT

At 3:01 PM -0700 9/4/07, Edward Cherlin wrote:
>On 9/3/07, Arthur Keller
><<>> wrote:
>1. One of the crucial reasons for open source in voting systems is
>the ability for the public to inspect the machinery of voting
>We do not want or expect everyone to inspect the software. We want
>enough people trusted by enough of the electorate to inspect it. Not
>that everybody will trust all of them, but that almost everyone can
>trust some of them.

While I agree with you in concept, there are some people who won't
trust anyone. The initial responses to my message reflect that other

>This concept is related to sunshine laws, public records
>acts, or the Freedom of Information Act. However, "published" source
>is sufficient for many of these purposes.
>By no means. It must be possible to alter and use the software in
>experimental environments, such as school elections, and adapt it to
>the needs of other countries where a proprietary developer would not
>judge the market large enough.

While there are some people who would like that opportunity, and that
is part of the reason for open source software in general, it is not
clear to me why that would be inherently true in voting systems more
than any other type of systems. My arguments were limited to the
reasons for open source in voting systems, not open source in general.

>3. While it would be useful for anyone to be able to publicly inspect
>voting system software, there are valid objections to publicly
>releasing software not designed to be published while it is in active
>use for public elections.
>Has someone proposed doing that? That's just stupid.

Actually, there have been proposals to do just that. I believe that
part of the reasons why some propose it is to drive secret software
for voting systems out of use and replace it with disclosed software.
But we have to be careful with such an argument because many election
officials are leery of open source software because they perceive
disclosure is risky. We need to clearly argue that disclosure of
software designed to be disclosed is not inherently risky.

>If the currently trade-secret voting
>system software is replaced (by open source, published source, or
>even new trade-secret software), then security reasons to keep such
>software secret not longer applies, and the software should then
>No, no, a thousand times no. It should be disclosed at every stage
>of development and testing.

I think you miss my point in that sentence. Once secret software is
no longer in use (because it is replaced), it can and should be
disclosed. Even if the replacement is by new secret software (and I
am not advocating replacement by secret software, but including it as
an (undesirable) possibility), then the old software can still be

>disclosed for public analysis. However, because of various patches
>and versions, it is still possible that some version may have
>contained a Trojan Horse, and not be able to detect that from the
>version being disclosed.
>4. If we are to go through the trouble of replacing old electronic
>voting systems with new electronic voting systems run on open source,
>unless the new systems are designed to be secure based on a threat
>analysis model, the new systems may still have security
>Why are you bringing this up again? We have said from the beginning
>that using a threat analysis model is our intention. Anyway, there
>will still be vulnerabilities. The idea in security is not to make
>breaches impossible, but to make them wildly impractical.

Some people have advocated the use of open source voting systems as
if the use of open source alone somehow engenders trust and security.

>Assistant Commandant, Colditz Castle prisoner of war camp: "There is
>no such thing as 100% security. We of the profession are not
>accustomed to speaking in such inexactitudes."
>SS Officer: "What profession?"
>Assistant Commandant: "The insurance profession."
>Colditz, BBC series
>5. I would like to see ACCURATE develop threat analysis models in
>conjunction with a new voting system design team. Preferably, the
>system developed would be open source, or at least disclosed source.
>Let us clearly understand what vulnerabilities are handled with open
>source voting systems
>Indeed. We have a long list, starting with elementary programming
>errors and malicious developers. Also a long list for hardware
>security, chain of custody, and other issues, where the software can
>detect and sometimes correct inadvertent and malicious errors.
>and what vulnerabilities are NOT
>vulnerabilities are NOT handled with open source voting systems.
>Name one.

Categorically those vulnerabilities that can be protected by
software. However, unique to open source voting systems is timing
the disclose of a vulnerability right before an election so as
intentionally to inject distrust and depress voter turnout.

>us also understand what new vulnerabilities are potentially
>introduced by open source voting systems, particularly when
>disclosing existing systems not designed to be disclosed.
>That would be completely stupid. The existing proprietary systems
>are known to be full of holes. It would take several years to patch
>them up if they were GPLed, and even then chunks would have to be
>thrown away and redone from scratch. It is easier to start over.

Again, some have proposed doing this, and it is one of the strawmen
used to attack source code disclosure in voting systems.

>I ask the
>last question because I think we need to understand the arguments
>against openness in order to counter them. In that regard, let us
>separate out disclosure of source code from disclosure of data
>formats and data itself.
>What arguments against openness? The only ones I hear are the
>discredited cries of "Security Through Obscurity", and "Stallman's a

There have been reasoned arguments, such as those made by Joe Hall.
Similar arguments exist about disclosing details about terrorist

>Anyway, don't forget that we need open testing, also.

True, but beyond the scope of my message.

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
By sending email to the OVC-discuss  list, you thereby agree to release the content of your posts to the Public Domain--with the exception of copyrighted material quoted according to fair use, including publicly archiving at
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
Received on Sun Sep 30 23:17:05 2007

This archive was generated by hypermail 2.1.8 : Sun Sep 30 2007 - 23:17:20 CDT