Vienna, 21-22 April 1997

Features For Freedom

A Report From eVote Developers

by Laurent Chemla, Marilyn Davis, John Jacq, and Claire MacElroy

  • Prologue (by Marilyn Davis)

    The challenge facing us, the architects of electronic politics, is to implement a platform upon which people can work a miracle. People expect a miracle now, as the millennium draws to a close. People grasp for a miracle now, as the dire predictions of the religions press in on us, fueled by the increasing density of people on the planet.

    Our responsibility is to provide tools for a new collaborative art form: fun, powerful, intriguing. Using these tools, groups will learn to articulate a new group identity, and to find power and expression in the issues they care most about.

    This is how we take control of ourselves and our environment. This is the promise of the ages coming alive (see also Davis 1992).

    The key to the success of our species will be in creating software in concert with the highest ideals of equality for every human. Only on a level playing field can we achieve universal individual empowerment, and expect universal individual responsibility.

    As architects, our responsibility is to pass the power of the medium onto the user, collecting none for ourselves or for our administrators and funders.

    We forge the hinges for the gates through which the old world will transform into the new. We must build it to swing free.

  1. Introduction

    The advent of cheap personal computers and of large capacity fibre-optic communication cables is revolutionizing the way people work. A question asked in Australia can be answered within seconds by someone in California or France. Discussion or work groups are no longer bound by geographical considerations and, in the development of eVote, team members happen to reside in the three areas mentioned above, yet all work effectively together as a team. At present, the most effective means of communication is by email, and for the group, the ideal tool is the list server which explodes every message to each member of the list enabling all to take part in the discussion.

    But discussions also imply decisions. Propositions are presented in the course of the discussion and in a normal meeting, the way to deal with these is usually by some form of vote, often simply by raising one's hand. With a list server, a new tool is used to enable the list members to propose motions and to also vote on them. This tool is eVote.

    eVote's development began in 1992 as the implementation of two theoretical concepts:

    1. computer technology can expand the meaning of "democracy" by giving control of the administration of polling and voting to the ordinary community members;

    2. "specializing" a data-base server to serve only vote data, ie., removing flexibility in the server, enables greater flexibility and power for the user interfaces that rely on the server.

    In other words, the vote-server must not have a regular database server under it. It must store its own data if it is to gracefully handle the considerable complexity demanded by concept number one.

    Seeking to implement these ideas, the first piece of the eVote puzzle to be developed was the underlying vote-server, The Clerk. This seminal piece was developed to be the brick from which many voting applications could be easily implemented.

    To test and demonstrate The Clerk, a telnet user interface was built. This early configuration was largely ignored as it appeared to be of only theoretical interest.

    At the suggestion of several democracy fans, the next piece developed was the email user interface which allows any member of an email list to poll the other members. This interface has produced a growing avalanche of interest as new possibilities suggest themselves and the eVote tools undergo constant development, additions and refinements. Today, with a Web interface, and a petition facility giving easy access to the public at large, eVote has developed into a pivotal social element that brings together a conferencing system with voting capabilities.

  2. eVoting -- a New Paradigm for a New Medium

    The first important difference between eVoting and traditional voting is that with eVote, every participant in the system has equal power. Any user can create a poll for the rest of the group to vote on.

    The other important difference is that each individual vote is remembered by The Clerk as belonging to the individual. In the old polling paradigm, ballots immediately become anonymous. This new ballot-memory characteristic of electronic voting enables redundant checking of the statistics, verification of the ballots by the voters, changing of one's votes as the discussion develops, and seeing each others' votes if appropriate.

    A final important feature for the new paradigm is in the domain of the discussion-oriented groupware into which The Clerk is embedded. The democracy provided by eVote is perfect in the theoretical sense if the surrounding groupware allows any user to initialize a new, and possibly private, discussion group and invite whom she pleases.

    A comprehensive list of the important new features for a stronger implementation of democracy are:

    • Any user can propose a poll.

    • The polling/voting is coordinated with ongoing discussion.

    • The user can change her vote until the poll is closed.

    • Any user can initialize a private discussion group.

  3. Polling method

    In the eVoted email list, a variety of options exist. Any member of the list may choose to propose a fully public poll where voters and their votes are revealed for all to see. This is analogous to the raised hand type of votes in small meetings. It has the same social advantage, there is opportunity to coalesce a group opinion through further discussion and re-voting. Also it has the technical advantage that security problems disappear when there is no attempt to hide the votes and every member can compute the tally independently.

    Or the pollster may choose to have an If-voted (semi-public) type of poll where it becomes possible to discover who has voted but not how.

    Or she may choose to have a private type of poll where everything is completely secret and one neither knows who voted nor for what.

    In addition, the tally can be made visible during the course of the poll or hidden and revealed solely once the poll has closed.

    The choices are left entirely to the poll proposer though of course she may be guided in this choice by the existing rules or by-laws of the list.

    Votes can be yes/no or a range of values. In addition, complex polls like "Vote for one of the following", or "Distribute 100 vote points over the following 8 Budget Items" are supported.

    The architecture of the software allows for the easy addition of more poll types opening the possibility of experiments with different scoring algorithms.

  4. Architecture

    The Clerk is an object-oriented C++ program which acts as a specialized database server. Unlike the usual generalized database servers which provide low-level API functions like get_a_record and store_a_record, The Clerk's calls are high-level and suitable only for the poll/vote application programmer: create_a_poll, I_vote, etc. (See Figure 1.) The tedious tasks of translating generalized data records into data suitable for voting applications and back again to data records is unnecessary. In addition, when there is no underlying database server, complicated tasks like checking permissions and calculating statistics are all handled inside the server so the user interface can provide high-level functionality with very simple code. Furthermore, the administrator is not involved with schema evolution or data maintenance. These things happen seamlessly as needed when the users add and delete polls. This architecture also provides new opportunities for security which will be explained in Section 5, below.

    As mentioned previously, there is a telnet interface which allows many users to simultaneously participate in polling and voting on a single machine. This user interface, built as an example, has the disadvantage of not being associated with conversation. However it has another API layer for groupware developers so that it can be embedded into any discussion-oriented software. (See Figure 2.)

    The most popular piece of eVote is the email interface. It too has an additional API which allows it to be embedded into any email listserver. Currently, it is only used with Majordomo. The magical thing about this configuration is that it is embedded into the mail stream in the alias file, no modifications of the listserver itself are necessary and yet, the polling process takes place in a natural way and in conjunction with the ongoing conversation on the mail list.

    The mail interface has been translated to French and is currently in use in the United States, Canada and France.

    Under test-use now is the petition facility, an addition to the email interface. The petition facility is different from the regular poll facility in that signers of a petition are not required to belong to any email list so there is no discussion process in conjunction with the petition's issue. This enables global petitions where anyone with an email address can add his signature by sending one email message.

    The computerized petition facility is an expansion of the democracy demonstrated in traditional petitions because, as the signer of an electronic petition, you can change your mind and remove your signature. The data you contribute remains under your control until the petition is closed.

    However, the petition facility does not represent true democracy, only plebiscitism, because there is no discussion facility attached to allow the participants to deliberate together on the issue under consideration.

    This petition facility led to the development of the first HTML web page interface for eVote at the SpeakUp site:, dedicated to a local land use issue in Palo Alto, CA. Now it is possible to sign a petition by pressing a button on a web page.

    The advantages inherent in this user interface, namely simplicity and high visibility, have prompted us to extend the web interface also to the polls or even to the list server itself. For instance, to subscribe or unsubscribe from a public list at (the home base of eVote) it becomes merely a matter of picking and choosing among a menu of all the public lists on the site, each list being accompanied by a brief description. Just click on the button below and you have subscribed or unsubscribed as the case may be.

    Similarly, to create a poll, just nominate the list in which the poll will be presented, enter a title for the poll where prompted, choose and pick the type of poll from a menu etc. When finally you click on the "send" button, an email message is sent to the mail server, properly formatted, after the web interface has checked that all mandatory fields have been filled in. From there, voting instructions are sent to all the subscribers on the mail list.

  5. Security

    Usually a discussion about security in any computerized system centers around methods and techniques for the system's administrator to protect the system from users. In the case of eVote and The Clerk, security reduces to the opposite problem, protecting the users from the system administrator.

    We will discuss each concern in turn, speaking both to the case of the telnet interface and the email interface.

    For online voting, these are the concerns:

    I. Security

    A. Exactly one vote is allowed per person.

    B. No forged votes are possible.

    C. The tally is correct.

    II. Privacy

    A private vote must be seeable and changeable by the person who contributes it while it is protected from all others, most especially the system administrator.

    I.A. Exactly one vote is allowed per person.

    The Clerk guarantees one vote per email address, or in the case of the telnet interface, one vote per login id. If you vote a second time for the same issue, your first vote will be replaced by your new vote. If the poll has already closed, your vote will be rejected.

    For the telnet interface, The Clerk depends on the usual Unix security devices: you must give a password to gain access to your login and your ballot. Ensuring that exactly one login per person exists is the responsibility of the system administrator.

    Similarly, email eVote has no facility to guarantee that only one email address per person exists in the online community. This problem is beyond the scope of software/hardware and must be solved by a formal registration procedure as in traditional elections.

    I.B. No forged votes are possible.

    This again depends on Unix security for the telnet interface. The voting is password protected because the login is password protected. This scheme is vulnerable to attack from the system operator and to others if the system operator is not careful about security. A user can always check that her vote is still recorded correctly and raise an alarm if it has changed unexpectedly.

    The email interface sends back a receipt when someone votes. If the mail message is forged, the receipt will still go the real voter and the forgery will be discovered.

    I.C. The tally is correct.

    In both the telnet interface and the email interface, the tally itself is vulnerable to attack only from the system operator. The Clerk's architecture makes such an attack difficult, at best.

    In The Clerk, the central object is the ballot. There is one ballot for each participant in each list or conference. This data record contains a number id, the last modification time, and a series of bits and bytes representing the user's votes or non-votes on the various current polls for the group. The format of this data record is decided at run-time and it changes automatically as new polls are added and old polls are dropped.

    Because these data shift unpredictably and because the poll questions are not written until after the software is compiled and running, it would be very difficult to affect the tally on a particular private poll and not affect the other polls. Only very smart and desperate system operators would try.

    Worse yet for a cheat, the source code for The Clerk is not available. It will be released if and when there is a substantial eVoting community that agrees that it would be the appropriate security measure.

    There is an additional deterrent. The ballots are stored in binary format and are indecipherable by the human eye.

    The data file containing the ballots has no personal information about the individual users except a number id which is a key into another file containing the login name or the email address. This data file can be shipped to another site and the results verified by another Clerk without risk to privacy.

    II. Privacy

    The shifting binary ballots is also the first defence against invasions of privacy. This will deter almost all system operators from snooping. Accidental and casual peeking are impossible.

    Privacy en route and privacy from the administrator is completely securable by encryption methods. The only problems are legal and political. There are no technical problems.

  6. The Future

    Currently each eVoted community is isolated. However, The Clerk has a hook for networking in the future and we envision a global community as well as many smaller communities.

    This means a network will exist, with many Clerks, each Clerk maintaining its own database of votes and voters. Because the statistics are dynamic (each Clerk maintains its own set of local statistics in temporary storage, the system operator can force a recalculation at any time based on the raw data in the vote database), all the Clerks can communicate and exchange their statistics. Clerks can also access the ballots of another Clerk and compute the statistics for the remote Clerk directly without jeopardizing privacy. At any time any Clerk can provide up-to-date statistical information for the whole network. (Refer to figure 3.)

  7. Conclusion

    The traditional way to envision data collection is to think of an agency that collects data, processes them, and presents results. (See figure 4a and 4b.) Until recently, there has been no other configuration possible. Eliminating the traditional generalized database server in favor of the object-oriented specialized database server allows such flexibility in user features that it is now possible for any user to gather data from cooperating participants and present statistics automatically. The roll of the agency is totally automated.

  8. References

    1. Chaum, David, "Achieving Electronic Privacy", Scientific American, August 1992, p. 96-101.

    2. Special thanks to Peter Paul Sint for discussions with Marilyn Davis about security and encryption techniques, Vienna 1997.

    3. Davis, Marilyn, 'On Electronic Democracy and It's Profound Implications', an essay published in the 'Effector Online', the online magazine of the Electronic Frontier Foundation, Issue 3.04, September 11, 1992

About the conference
About Web4Groups
Study on voting and rating

Page created by Gernot Tscherteu