Free Software for Electronic Voting - Help Wanted!

From: Joseph Lorenzo Hall <joehall_at_gmail_dot_com>
Date: Fri Mar 18 2005 - 18:28:13 CST

Thought the OVC list might want to see this story at Kuro5hin
(pronounced like corrosion)... which is a peer-reviewed version of
Slashdot. -Joe

http://www.kuro5hin.org/print/2005/3/16/144321/983

----
## Free Software for Electronic Voting - Help Wanted!
As we have all been hearing a lot about for almost five years now, the
situation with electronic voting in the United States (and elsewhere)
is a mess. More than that, we all know that we have precious little
time to do something about it.
* * *
Dear friends at k5,
I'm not going to waste your time, I'm going to give you the pitch
right up front and then some brief supporting information for those of
you who may be compelled or uninformed. Here it is:
As we have all been hearing a lot about for almost five years now, the
situation with electronic voting in the United States (and elsewhere)
is a mess. More than that, we all know that we have precious little
time to do something about it. There has been some talk around this on
K5, see: [here][1], [here][2], and (disparagingly) [here][3]. There is
at least [one open-source voting project][4] currently under
development using the Python language, and there are a series of
recommendations for software designs ([Blind signature [pdf]][5]1,
[n-Version [pdf]][6], [FROGS [pdf]][7], etc.) available.
The group [Blue Screen Democracy][8] set out with the mission of
building a widely-distributed developer base and implementing what the
most people thought were the best methods used in the abstract designs
available for voting systems software. In other words, we wanted to
develop the software not in the way we thought best, but in the way
the most people thought best; **democratically**.
There is no doubt in our minds that free (GPL) software makes
absolutely the most sense for voting machines, for a [host of
reasons][9]. With efforts as widely distributed as they are, however,
what seems to us like clearly _a very good idea_ isn't making much
headway. To our eyes, every attempt as yet to extend the reach of
open-source voting software into public use has been unsuccessful. We
feel like a fair amount of this is attributable to the lack of
solidarity on the part of the disparate groups attempting to work on
this problem. Not wanting to cause yet another unnecessary crack in
already patch-work body of the free-software voting machines
advocacy/development effort, we find ourselves at somewhat of an
impasse.
Thus, this appeal, "What should we do?" Do you all think that the OVC
system (EVM 2003)2 is good? (To us, their effort seems stale-mated, to
you: Should we be supporting it anyway?) Are we even happy with their
implementation? As an organization, we would be happy to support a
system that would be supported by the rest of the community. If you do
think that something besides the OVC system is needed, we have opened
up a [SourceForge page][10] which begins with [a discussion][11] of
what needs to be done. Cryptographers, security experts, coders,
architects: Please help! With no need to over-dramatize, the future of
open government is at stake in this issue.
If you are compelled already by this issue, please come on over to
[our sourceforge page][10] or directly to our [forums][11] and get
involved in the discussion. If not, read on compadre.
**1. Why GPL Voting Software in the first place? Or, Why paper trails
     won't cut it.**
We believe that paperless, privatized voting systems are an especially
bad idea and are in full support of the inclusion of voter verifiable
paper trail on current machines. In the event of something as simple
as a storm related power outage or something as complicated as a
coordinated effort by a party to interfere with U.S. elections, there
must be a non-electronic record of voters.
However, a paper trail is not enough to secure the accurate tabulation
of votes in the United States. As long as the electronic voting
software in use is the property of a private, for-profit firm the
inner-workings of our elections will remain obscured. Private
companies do not have to reveal how they are secure and so citizens
have to simply, "take their word for it." Moreover, if an error in
tabulation occurs, we must trust the company to catch that error and
correct it. This possibility brings up a variety of issues, not the
least of which follows: If it is a central goal of for-profit
electronic voting software companies to make profits by selling their
product, and if in order to sell their product they must maintain the
notion that their software is secure and accurate, what is their
motivation to announce breaches of security or errors in accuracy when
this could hurt their market value? In short, who wins should voter
interests and market interests collide?
We provide a _lot_ more information with regards this kind of thinking
at our [web site][8]. Check it or something else out, if you will.
**2. Why we aren't convinced by the current efforts.**
Which is not to say that we aren't behind them 100 percent. Our group
has the highest regard for and shares the goals of the OVC, and
frankly would be pretty happy if their software were to be integrated
into the voting process. However, at this point, we are not convinced
by their development model (for a variety of reasons), and as such, we
have constructed a sort of vague architecture for [our own][12].
The gist of our idea is that we probably wouldn't be convinced by the
development model _I_ came up with either. We find that the real
strength of the open-source/free software model comes in numbers. In
other words, the way you make software rock-solid is you have tons of
eyes on the code. More than that, you have tons of opinions before you
even start making the code - we'd like to harness the valuable
opinions and expertise of the huge open-source developer community and
_all work on this together_. As such, what we're suggesting involves a
ground-up involvement by a significant number of developers, making
decisions from the lowest level in the most democratic way we
can. Sourceforge is a handy tool for this, but in order for it to
work, we all have to get involved. Hence, again, this call.
So again, if you are interested, please come get involved. We need
developers, but we need you if you're not a developer as well. You can
gather information at our [home page][8] (which also has links to tons
of other valuable resources for this issue), come check out the status
of our OpenVote software at our [Software page][10], or just jump
directly into the discussion at [our forums][11]. Hell, [email me][13]
personally (check the spam-blocking spaces). There is a lot of work to
do on this issue, and we're pretty convinced that the only way it's
going to get done is if we all do it together. Selah.
* * *
  1. This is developed well for practical use in: Fujioka, A, Okamoto,
     T., and Ohta, K. A practical secret voting scheme for large scale
     elections. In Advances in Cryptology - AUSCRYPT '92,
     Springer-Verlag, Berlin. 1993, pp. 244-251. (Sorry no link).
  2. For those who haven't read up on it, the EVM2003 is a system
     which uses the Python 2.2.2+, wxPython/wxWindows (for
     presentation of the interface elements) and the Gnosis Utilities
     1.1.0+ to access XML (election) Model and (ballot) View
     documents. The view documents control the style and the placement
     of elements in the display, and the model holds the actual
     election elements. The encoding of cast votes takes place on a
     paper ballot which is the final record used for the vote count
     (requiring, presumably, the use of an optical scan machine, thus
     eliminating some of the ease for election officials, and possibly
     some of the likelihood of its being implemented). The secrecy of
     the vote is guarded with a visual obfuscation schema for unique
     barcodes on the final individual paper ballots. The source code
     is [here][14].
[1]: http://www.kuro5hin.org/story/2003/2/26/22521/9799
[2]: http://www.kuro5hin.org/story/2003/9/4/18148/56550
[3]: http://www.kuro5hin.org/story/2002/11/7/222359/785
[4]: http://openvotingconsortium.org/
[5]: http://www.seas.gwu.edu/%7Epoorvi/Chaum/chaum.pdf
[6]: http://www.vote.caltech.edu/media/documents/vtp_wp16.pdf
[7]: http://www.vote.caltech.edu/media/documents/vtp_WP2.pdf
[8]: http://www.bluescreendemocracy.org/
[9]: http://www.bluescreendemocracy.org/archive/bsd/gpl.php
[10]: http://bluescreen.sourceforge.net/
[11]: http://sourceforge.net/forum/?group_id=132400
[12]: http://www.bluescreendemocracy.org/archive/bsd/model.php
[13]: mailto:paul%20@%20bluescreendemocracy.org
[14]: http://sourceforge.net/projects/evm2003
-- 
Joseph Lorenzo Hall
UC Berkeley, SIMS PhD Student
http://pobox.com/~joehall/
blog: http://pobox.com/~joehall/nqb2/
_______________________________________________
OVC discuss mailing lists
Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
==================================================================
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
==================================================================
Received on Thu Mar 31 23:17:07 2005

This archive was generated by hypermail 2.1.8 : Thu Mar 31 2005 - 23:17:09 CST