Re: Is Open Source Enough?

From: Arthur Keller <voting_at_kellers_dot_org>
Date: Wed Sep 05 2007 - 01:34:09 CDT

At 11:05 PM -0700 9/4/07, Brian Behlendorf wrote:
>On Mon, 3 Sep 2007, Arthur Keller wrote:
>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.

I agree entirely.

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

That's still a theoretical argument. Suppose there are two companies
competing using the code based by Open Voting Solutions? Would that
help them compete better against closed source vendors?

>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

Those are nice ideas. The enlightened self interest that has led to
the creation of Linux and Apache doesn't seem to have worked yet in
voting system software. The need for government subsidies, in the
creation of R&D in the development of open source voting systems, and
in the certifications of these systems would be useful. The problems
with creating variant version of voting system software include the
potential that fraudulent or errant code can creep in, and the need
to recertify every changed version and configuration.

>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


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

Yes, and for line of reasoning it is worthwhile rethinking the design
of voting systems, and not merely creating open source equivalents to
electronic voting systems.

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

Agreed. We need the combination of threat analysis, new design for
security, and open source development based on the first two, as well
as new operational paradigms designed with security in mind. I don't
see this happening yet, but pieces of it are coming into place with
the ACCURATE project. We don't yet have a design project that
dovetails with the ACCURATE project. (That's one I'd like to be
involved in.) And then we need an open source implementation. How
do we get there?

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


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