|Vienna, 21-22 April 1997|
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.
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:
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.
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:
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.
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: http://www.nanospace.com/SpeakUp, 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 deliberate.com (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.
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:
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.)
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.
| About the conference |
Study on voting and rating