Re: Free Software for Electronic Voting - Help Wanted!

From: Edward Cherlin <cherlin_at_pacbell_dot_net>
Date: Tue Mar 22 2005 - 18:42:57 CST

On Friday 18 March 2005 16:28, Joseph Lorenzo Hall wrote:
> Thought the OVC list might want to see this story at Kuro5hin

We need to do more than see it. We need to talk to these people.
We should be working together. (Also, there are a few errors
that should be corrected in their statements about us. They have
confused the demo architecture with the design of the real
system.)

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

-- 
Edward Cherlin
Generalist & activist--Linux, languages, literacy and more
"A knot! Oh, do let me help to undo it!"
--Alice in Wonderland
http://cherlin.blogspot.com
_______________________________________________
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:08 2005

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