Anonymous Voting

This page is an attempt to sort out the requirements for anonymous voting in the foundation election, and a possible implementation. It draws on David Neary's proposal that was posted here:

http://mail.gnome.org/archives/foundation-list/2005-June/msg00000.html

Requirements

These are the base requirements inferred from the existing voting system:

Each member must only be able to have at most one vote counted
- If a member can record multiple votes, then they can skew the election. This can be accomplished by discarding duplicate ballots (keeping either the first or last).
Only the election committee should be able to create ballots
- If someone can create ballots, then they can vote more than once. This requirement falls out from (1).
The email address alone can not be used as a unique identifier for voters
- In the past there has been a case of two members sharing an email address.
A member should be able to independently verify the election results
- To increase confidence on the results, the information necessary to retabulate the results should be available.
A member should be able to verify their own vote (or absence of a vote)
- A member should be able to ensure that their vote was recorded correctly according to their preferences.
The election committee should be able to issue new ballots if a member loses their original ballot
- Ballot delivery might fail, email might get deleted/eaten, etc. This need not be possible if the old ballot has been submitted.

Anonymous voting imposes some new requirements on the process:

The election results should not link ballots to the identity of the voter
- This is the basic definition of anonymous voting. Requirement (5) implies that voters should still be able to verify their own vote though.

Design Constraints

We probably want a system similar to the existing election system, which means:

Email based. Ballots sent out to foundation members by email, foundation members send completed ballots to a voting email address to have them counted.
We don't have a public key infrastructure, so PGP for authentication or privacy is out of the question. People's email accounts are assumed to be secure, but delivery failures are possible (see requirement (6) above).

Implementation Plan

Preparing the ballots:

The list of voters is tabulated
Random tokens are assigned to each voter. The following code snippet is one possible way to generate the tokens:
- ```
>>> fp = open('/dev/random', 'rb')
>>> BYTES = 12
>>> token = fp.read(BYTES).encode('base-64')
```
If there are any duplicate tokens (unlikely), reissue tokens as needed.
The list of (token, email, real name) tripples is stored to a file. This file should only be available to the election committee and voting software

Sending the ballots just involves a simple mail merge on the list created above.

Accepting completed ballots:

Completed ballots are sent to a given email address. This email address should feed through to a script.
The received message is checked for a token (probably using a simple regexp). If no token is found, the mail is discarded (probably spam)
If a token is found, check to see if the token appears in the voters list. If not, discard the message
If the token is good, the message is parsed to verify that it is well formed.
If the ballot is well formed, create a file $ballotsdir/$token containing (a) the token and (b) the ballot information gathered in the previous step in a canonical form. An email is sent to the email address associated with the token to acknowledge that the ballot has been accepted (this email should contain the contents of $ballotsdir/$token, so the voter can verify that their ballot has been correctly interpreted).
If the ballot is not well formed, an error message is sent back to the email address associated with the voting token.

Reissuing lost ballots:

Just send out another ballot, using the same voting token as before.

Counting votes:

The contents of $ballotsdir is all that is needed to tally the votes. The votes are tallied according to what ever counting method is in use for the election.
Voter turnout can be calculated by comparing the number of recorded ballots with the number of registered voters for the election.

Once the results have been accepted, the list linking tokens to voters can be destroyed.

Requirements Checklist

Requirement (1) is satisfied because each member is allocated a unique token which allows them to vote at most once. Since the tokens are randomly generated, it should not be possible to guess other member's tokens. If the number of possible tokens is much larger than the number of allocated tokens, then there is not much chance of someone brute forcing another token.

Requirement (2) is satisfied because the list of valid ballots is defined by a list that only the election committee has access to.

Requirement (3) is satisfied because ballots are identified by the random token rather than the user's email address.

Requirement (4) is satisfied because the anonymised ballots are available at the close of the election.

Requirement (5) is satisfied because each voter knows their token. If they voted, then they can look up the ballot with that token and verify that it is correctly recorded. If they did not vote, they can verify that no ballot includes their token.

Requirement (6) is satisfied because the election committee can use the token list to reissue a member's ballot.

Requirement (7) is satisfied because there is no personally identifying information in the set of ballots released at the close of the election. A member can still disclose their token if they want other people to know how they voted (doing this before the close of the election would be bad though).

Unresolved Questions

Election Committee can link ballots to members: I don't think this can be fixed without lowering the security of the system. The committee is already trusted not to rig the election, so I don't think this is too big of a deal.
Do we need to handle revoking tokens?: Are there cases where we'd need to revoke a token, and allocate a new one? If we add this ability to the system, we need to make sure that a member who doesn't vote can detect that someone revoked their original token and voted with a replacement token. This could be done by releasing which tokens were revoked with the rest of the election results.
Plain text email is not secure: The system could be more secure by using PGP encryption at the appropriate places, but this would require tht all members have PGP keys which we don't at the moment. The random tokens would still need to stay though, so members can identify their own ballots in the results.