Re: Is Open Source Enough?

From: Edward Cherlin <echerlin_at_gmail_dot_com>
Date: Tue Sep 04 2007 - 17:01:05 CDT

On 9/3/07, Arthur Keller <> wrote:
> I've been thinking about the role of open source in electronic voting
> systems. Here are some sketchy thoughts I'd like to share.

Do you use Free Software? Linux, the BSD underpinning Mac OS, Free apps such
as Open Office on Windows, anything? Because you sure sound like you don't
have any idea of how it works.

1. One of the crucial reasons for open source in voting systems is
> the ability for the public to inspect the machinery of voting
> systems.

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.

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.

2. One key side benefit of published source is that systems
> *designed* to be open are designed with better inherent security than
> systems designed to be trade secrets.


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.

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.

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

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.

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.

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

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 Communist!"

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

Best regards,
> Arthur
> --
> -------------------------------------------------------------------------------
> 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

Edward Cherlin
Earth Treasury: End Poverty at a Profit

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