• Intro
• Downloads
• Community
• Development
• News
• TALK

Maemo.org team/How Elections Work

This page details the current voting system and how it works. It is presented as a means of offering transparency into how voting is handled and how the current system provides both anonymity and verifiability in community elections and referendums.

[edit] Overview

The voting system provides voters with a multiple-choice interface which can be used to create an ordered list of selected options. Voters can select some, none, or all of the choices, and order those choices as they prefer them.

For multi-seat elections, voters may choose any number of candidates, be that greater than, equal to, or less than the number of seats (see Single Transferable Vote below). For the special case of a two-choice referendum, voters should be aware that there is no (additional) sense in choosing both options, though the voting system may in fact allow them to do so. Only the first selection in a 2 option election will be counted.

Voters that dislike the choices, or want a choice not presented, may show their desire to participate by choosing nothing and casting an empty ballot. If enough voters cast empty ballots it can affect an election by making fewer (or no) candidates reach the required "quorum" levels to be elected.

[edit] Parts of an Election

The current voting process is divided into several pieces. Some of these are not visible to the voter, or are taken as a given. To ease the process of explaining the process, we will follow the "life" of a single vote, from the creation of the election to the final results.

[edit] Elections

Elections are created by an administrator (often Council) and stored in the database with several vital fields about that election. Included are the start and stop times, the title of the election, text about the election, candidates for the election, and the number of "winners". The contents of these tables generally show up in one form or another in the interface for voters.

[edit] Electorate

The system also contains an electorate list; the list of users eligible to vote in an election. That list generally gets updated from the main maemo.org list before elections are started. The date this happens is the relevant date for calculating karma, account age, and so on. Only users that meet the conditions at that date are included to the electorate table. It is difficult (but not impossible) to update or adjust this list after elections have started. To avoid complexity it is asked that voters check their account settings, particularly their email address, and setup any linkages needed at least a few weeks before elections start.

[edit] Voting Tokens

When an election is setup and ready to be used, and the electorate is verified, an administrator instructs the system to create and mail tokens for the electorate. A script in the system then generates a random voting token for every member of the electorate, and mails that token to each voter. The voting token, used as a password for the voting login screen, is valid for one vote in the election for a given voter. Administrators never see these tokens (aside from any token they may get as a voter).

The tokens are stored in a separate table, with a numeric pointer to the voter and election for which it is to be used. Storing them this way, in separate tables, makes it harder for an administrator to "accidentally" see a voter's e-mail and token together if they need to look at the database for any reason. The odds of anyone guessing a token is also quite slim, and both the token and e-mail address is required to log in to vote.

[edit] Voting Process

The entire voting process is state driven. When a voter chooses an election and logs in, the system validates the token to allow them into the voting interface. This is a "courtesy validation" to allow the voter to know that the token is still valid. Nothing is altered by this step.

The list of choices is presented to the voter, and stored in a javascript applet in the voters browser that allows the voter to chose as many options as they like, in the order they like (note that you can undo choices by clicking on the list of chosen items). When the voter is happy with their choice(s) and proper order, they submit the choices for validation and confirmation. The vote selection is validated, displayed to the voter to confirm that the system got their choice(s) and order correct, and the voter is asked to submit the vote for final processing.

The next step is the most complex and critical. Once the vote has been submitted, several things happen all in one single action:

1. A random vote validation string is created for this vote.
2. The vote is prepared for entry into the list of votes with this random string.
3. The system atomically (as one step):
   1. Validates that the vote token is still valid
   2. Adds the vote to the list of votes
   3. Deletes the valid vote token

At this stage, one of two things happens:

• If an error occurs, all sub-steps are undone, leaving a valid vote token, and an error is reported to the voter.
• If all works as expected, the random vote validation string is presented to the voter.

Lets look at those sub-steps a little closer:

The first sub-step generates a random validation string for your vote. When the vote is stored in the vote table, that is the *only* reference as to "who" cast this vote. Being that it's random, the only way one can know it is by seeing it on their screen, just after submitting their vote. This is important because it allows each voter to validate the public ballot later by looking up their unique entry to verify their vote was counted as they cast it.

The third step guarantees that a voter always has either a vote token, or has a vote cast with a random validation string. This prevents multiple votes per voter, and prevents technical problems from leaving a voter stranded without a vote. For this reason, at any time up to the point one hits the "submit vote" button on the validation page, and gets a validation token random string displayed, one may close their browser, or hit back, to change their choices, or start all over anew with the process.

[edit] Post Election Ballot Validation

Once the vote has closed, the ballot of all votes cast is publicly viewable (and downloadable) by everyone. The list includes the votes cast, including the order of the choices for multi-choice votes, and the random validation strings for each vote. Since each voter knows his or her validation string, they can validate their vote is correct. They can also count the votes, and validate that the results of the election are correct. But since only one random validation string is known per voter, voters (as well as admins) can not determine who voted for which candidates in the election. Since there are no links to the original owner or starting token in the final voting table, there's also no way for an administrator (or anyone with database access) to determine who voted for which candidates either.

[edit] Technical Details

This area is for a more technical look at how things work, and may be less interesting for the general voter.

[edit] Source Code

For those interested, the voting code is public domain and can be reviewed. At this point, the entire voting system consists of PHP code, a small piece of javascript that runs in the browser, and a perl script that handles e-mail delivery. Since the addition of the admin interface, even the administration functions are now in PHP. The OpenSTV portion is written in perl, and is also opensource, though there is a requested donation (which has been made on behalf of Maemo for our use of it).

[edit] Database Setup

The database schema for the voting database is also checked in as an SQL script that can be used to create all tables needed for the scripts to function. Any updates to tables should be included in this schema.

[edit] Individual Tables

There are several tables in the election interface. Below is a brief description of each, as they exist at the time of writing this wiki page.

[edit] Cloning Voting Tokens

One option available for administrators is to "clone" voting tokens from one election into another. This allows one "password" to be used in two or more elections. This process is often desirable when two elections are happening at the same time or in close succession, as it cuts down on the number of tokens mailed out, and eliminates confusion about which voting token string to use for a given election.

For example, the Coding Competitions often have 5 to 10 categories, each with a separate election. Having 5 to 10 tokens mailed to voters could cause spam triggers, and/or could confuse voters as to which token to use for which category. Instead, one token is created, and cloned to the other categories. The allows a voter to use the same e-mail and password to vote in all Coding Competition elections, but still only allows one vote per voter per category.

Cloning works because each token has a reference to the voter and election for which it exists. When a token is cloned a copy is made with a different election identifier. This means two tokens exist with the same random "string", but each points to the same user and a different election. When a voter casts a vote in one election, just the token for that election gets destroyed.

This is also the reason tokens can't be cloned after voting has opened on an election. Since voting tokens are destroyed as the vote is cast, cloning from an active election would mean those who already voted in the election would not have a token to copy, and thus would not be able to vote in the cloned election.

(3UA9VTp,Alice,Ref1) 
(oUB3VTq,Bob,Ref1)
(yUC9VTr,Chad,Ref1)
... [all eligible electorate]  

(3UA9VTp,Alice,Ref1)
(oUB3VTq,Bob,Ref1) 
(yUC9VTr,Chad,Ref1)
... 
(3UA9VTp,Alice,Elect2) 
(oUB3VTq,Bob,Elect2)
(yUC9VTr,Chad,Elect2) 
... 

(3UA9VTp,Alice,Ref1)
(oUB3VTq,Bob,Ref1)
(yUC9VTr,Chad,Ref1)
... 
(3UA9VTp,Alice,Elect2) 
(oUB3VTq,Bob,Elect2)
(yUC9VTr,Chad,Elect2)
... 

"Yes" ⇒ OMGuVotedN0wg0prty (Ref1)
"No" ⇒ Yualw4ysSoN3gatlve (Ref1)

(oUB3VTq,Bob,Ref1) 
...
(wUZ3VT5,Zarrah,Ref1)
(3UA9VTp,Alice,Elect2) 
(oUB3VTq,Bob,Elect2) 
(yUC9VTr,Chad,Elect2)
...

"Yes" ⇒ OMGuVotedN0wg0prty (Ref1)
"No"  ⇒ Yualw4ysSoN3gatlve (Ref1)
"Kyle","Lucy" ⇒ M4nUVote4YurBudzEh (Elect2)
"Jim","Mandy" ⇒ OMGuVotedTo0g0prty (Elect2)