Re: Is Open Source Enough?

From: Brian Behlendorf <brian_at_behlendorf_dot_com>
Date: Wed Sep 05 2007 - 01:05:43 CDT

On Mon, 3 Sep 2007, 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.
> 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. 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.

In my humble opinion, this should be one of the last reasons to be in favor of
Open Source voting software, primarily because one can not easily inspect
software while it is running, so one can not be sure that the software one
inspected is the software actually running on the voting machines being used.
The software, no matter how thoroughly inspected, should not simply be trusted
to get the job right - it should do its job, but other processes should be
involved that can make sure it did its job correctly. Furthermore, how much
time is "enough" time for the system of public scrutiny to notice security
holes? How do you elimanate the potential for corruption outside of the
software running, like opening up Microsoft Access and changing the table
entries directly like Bev did for Dean in "Hacking Democracy"?

Trust comes from defining a process with enough checks to raise the cost of
fraud high enough to make completely unattractive. That process should work -
i.e. should be able to detect fraud - no matter what software is running on
those systems.

The primary reason to be in favor of open source voting systems is not
technological, but economic. Such software encourages competition, as it
lowers the cost of becoming a voting system vendor. It forces those vendors to
spend less time thinking about towers of code and more time on quality
hardware, service, and auditable systems. It allows districts to run their own
voting processes if they'd like to, or an NGO to do so. Implementation of
special voting techniques, like ranked ordering, can be done once and shared
with everyone else rather than re-implemented at cost-plus to the districts
that need it. Skills around maintaining the software (and hardware that
matches it) can be developed across a whole industry rather than specific to
one vendor, meaning greater resiliancy in the face of election-day meltdown or
other problems. Of course the economic problem with open source voting systems
is getting the money to pay to be certified - but IMHO there should be
subsidies for certification of fully open source systems, if not an outright
freebie, as the end result would be available to any vendor to deploy in an

Sunshine is indeed a disinfectant, and disclosure of source code would make it
somewhat easier to find a systematic bias for a specific outcome. But it is not
the guarantee of trust that a proper election process would bring, within which
computerized automation is just a tool.

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

I would restate this somewhat - software written to be open from the beginning
is usually more thoughtfully designed from a security perspective. This is due
to knowing that security-by-obscurity is no longer an architectural option, and
because developers don't wish to risk their reputations by publishing lousy

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

I agree, definitely.

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

This isn't stated strongly enough. I don't know who said it first, but it's
been said that for any given software package, the last defect is fixed when
the last user is deceased. There is no provably secure software out there,
only software whose security defects have not yet been found. Even the most
security-minded open source projects, like OpenBSD and OpenSSH, occasionally
have security defects and issue patches, and often vulnerabilities are known
about and shared amongst black-hat groups before they're publicly known and
corrected. We should take it *as a given* that all software has defects, that
any system might be compromisable. That's back to my reasoning that it's the
process, not the software, that should create trust in the system.

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

Certainly, an open source voting system, especially one in widespread and
mostly-standardized use, makes it straightforward for researchers, officials,
and citizens to work together on scenarios for attacking the system and
determining how to shield against them. If a hole is discovered in the
elections process, if the fix is in software, it gets fixed once rather than
fixed over and over for every N different voting system software vendors. But
good security processes and policies transcend specific software packages, and
IMHO should be defined abstractly.

> Let us clearly understand what vulnerabilities are handled with open
> source voting systems and what vulnerabilities are NOT
> vulnerabilities are NOT handled with open source voting systems. Let
> us also understand what new vulnerabilities are potentially
> introduced by open source voting systems, particularly when
> disclosing existing systems not designed to be disclosed. 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.

Makes sense.


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