Re: Twelve subscriptions

From: Joseph Lorenzo Hall <joehall_at_gmail_dot_com>
Date: Sat Nov 06 2004 - 18:10:35 CST

On Sat, 6 Nov 2004 14:45:32 -0800, Arthur Keller <> wrote:
> So far today, we have 2 new subscriptions and no other donations.

I didn't get this up until late today... sorry I'm just too damn busy.
 It should attract a few people to the site as it's on the front of and in the feeds

(this is in markdown format and can be turned back into html with
markdown: ):

[Open Source Software in E-voting][1]
(This is a _highly abbreviated_ version of a forthcoming paper)
Approximately one year ago, [California Secretary of State Kevin
Shelley][2] handed down the first [open source software mandate
(PDF)][3] of any U.S. government official. This open source mandate
came in response to a specific subsystem of electronic voting
machines: the system that verifies the selections on an AVVPAT for
disabled voters must run on open source software. As well, Rush Holt's
bill ([HR 2239][4], 108th Congress) require that "No voting system
shall at any time contain or use undisclosed software."
There have been attempts in the past at coding open source election
software for Internet voting. For example: [Lorrie Cranor][5]'s[
Sensus][6], [MIT][7]'s [EVOX][8] and [Jason Kitcat][9]'s
[GNU.FREE][10]. All of these systems are now unmaintained, and voting
over IP (a/k/a the _other_ VoIP) has been [fundamentally
discredited][11] by David Jefferson, Avi Rubin, Barbara Simons and
David Wagner in their report examining the Pentagon's SERVE project.
However, there hasn't been a serious effort at developing an open
platform for polling place voting until recently. In the past few
years, the [Open Voting Consortium][12] (OVC) has developed software
and [a design][13] for an open voting platform. The software,
[EVM2003][14], is written in python using [XML ballot
specifications][15] and can run on a standard PC using a CD-bootable
GNU/Linux called [Knoppix][16]. The OVC is currently in the middle of
a fundraising campaign to get ["1111 subscribers by 11/11?][17] to
raise money for their efforts from small, grass-roots donations of $10
a pop; if you have a decent salary and less than two kids, consider
give them a few bucks. (None of which should be confused with the
[Open Vote Foundation][18] which intends to fork the [open source
Australian e-voting software][19] called [eVACS][20] code that is [no
longer open source][21])
### Why open source?
Elections have a long history of being open processes. Openness is one
of the central aspects that lends legitimacy to the electoral
process. Even with lever-based election machines, which have been
around since the last few decades of the 19th century, it was still
possible for election officials to hire a reasonably confident
engineer to open the machine up and verify that, in fact, the right
gears were turning the proper amount of times.
Over the past two decades, computerized technology has become a
growing element of election administration and many parts of voting
technology are now enshrouded in mystery. Computer software is subject
to all types of intellectual property protection (copyright, patents,
trade secrets and trademark) and electronic voting machine vendors are
notoriously protective of their products. They do business in a small
and highly competitive market that has just seen a large injection of
$3.9 billion from HAVA. While any trade secret that they may hold is
in no way rocket science, you can imagine that their implementation of
software and hardware would give their competitors an edge if known
Now that we are seeing serious concerns in the areas of vote
tabulation and human factors from Tuesday's election, there will be a
need, as [David Wagner suggests below][22], for comprehensive
investigation into the source of these problems. Undoubtedly, this
will involve examinations of source code and attempts to reproduce
problems on the same machines used in the election. The examination of
any vendor's source code is a particularly sensitive topic filled with
NDAs and negotiation; for example, it took the California office of
the SoS 6 months to negotiate the terms of an independent source code
examination of California's four EVM vendors (Diebold, ES&S, Hart
Intercivic and Sequoia).
Another benefit of open source, open standards, is also highly
desirable in election administration. As you can imagine, having
different types of raw vote data (encrypted or not) in proprietary
formats, makes combining results from different vendors at the state
level a major pain in the ass. In fact, I've got anecdotal evidence
that the "official" canvass here in California involves a few
employees of the office of the Secretary of State entering in county
totals by hand into a spreadsheet precisely because there is no
interoperability between data formats of our 4 vendors. Talk about an
environment ripe for human error... This is why it is heartening to
see [IEEE][23] standards work ([IEEE 1622][24]) and the [OASIS][25]
[Elections and Voter Services TC][26] working on voting data
### What are the risks of open source in e-voting?
Jason Kitcat, author and maintainer of GNU.FREE, wrote a piece for the
October issue of the _Communications of the ACM_ where he described
why he had switched from advocating open source software in elections
to advocating for closed source ("Source Availability and Evoting: An
Advocate Recants" _Communications of The ACM_ October 2004/Vol. 47,
No. 10, 65-67). He thesis can broadly be stated as arguing that
disclosure in software does add some benefits for e-voting in terms of
security and transparency, but not enough to outweigh the inherent
difficulties in "creating a secure, private, reliable and anonymous
system that provably records voters intentions accurately."
There are a few risks of open-source voting that have been pointed
  * **Disclosure or withholding vulnerabilities:** By having the code
      disclosed, attackers are free to examine the code at their
      leisure and exploit bugs and vulnerabilities that are not found
      before election day. As well, if a serious flaw is found right
      before an election, this might have adverse consequences on
      voter turnout. If the alternative is allowing a compromised
      election, I personally think this is a good thing.
  * **Reduced competitive advantage:** If vendors are required to open
      their source, this would mean new competitors could enter the
      market and "free-ride" off of the years of work that vendors
      have put into their software. Of course, this depends on
      licensing terms mandated by the regulating body. Of course, if
      the licensing terms, as in the Holt Bill, are merely
      disclosure-oriented, there's still something called copyright
  * **Reduced market supply:** If vendors are not allowed to keep
      software and interfaces proprietary, there will be reduced
      incentive to enter the market or create new products. I have a
      feeling that most of the money in election systems is in
      service-oriented contract work. Plus, vendor lock-in is always a
      good thing for the vendor and always a bad thing for the
  * **Lack of participation:** (This is Kitcat's "Transparency goes
      only so far" argument) E-voting isn't very sexy and as such,
      will not attract talented (or any) coders to
      contribute. However, _community source_ consortia-based projects
      like [SAKAI][27] are a better model for e-voting software
      development, whereby in order to be able to contribute and make
      changes to the application an institution has to devote a
      certain amount of coders and resources to the project.
  * **End users compromising security:** The end-users of open source
      e-voting software, the counties, could change the code,
      recompile it and implement it in very insecure ways not knowing
      the details of its design and the assumptions behind the
      model. This could be alleviated by having technicians in
      counties certified to make changes or requiring that no changes
      are made after a code-freeze date (which was properly scheduled
      to allow the code to be certified in time for use in the
      election in question). This would ensure that counties run the
      code through the ringer on the systems they intend to use and
      reconcile any bugs our vulnerabilities before the code-freeze
Of course, I'm sure I've left plenty out... please leave comments or
send me an email and I'll incorporate your arguments/suggestions (and
acknowledge you in my paper, of course!).
    [1]: (Permanent
Link: Open Source Software in E-voting)
Joseph Lorenzo Hall
UC Berkeley, SIMS PhD Student
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
Received on Tue Nov 30 23:17:14 2004

This archive was generated by hypermail 2.1.8 : Tue Nov 30 2004 - 23:17:44 CST