This is a duplication of a posting I made elsewhere.
A Draft Proposal For An Open Voting SystemBackground:
Given the recent furore
over the verifiability (or lack) of the electronic touch screen voting systems used in the recent US election, it astonishes me that a google on the topic turns up just one
reference to an open source electronic voting system! That is the eVACS
system that was used for the 2002 Canberra election in Australia.
I do note that there is the OpenVote
organisation that has set up in the last 12 months, and which is using eVACS as a basis for their own offering.
I may give Open Vote a hand at some point. Before I do, however, I want to get a few thoughts of my own down.General Thoughts:
(NB: this is based on Australian procedures. Please point out any variation to your own local system that would affect the associated reasoning. eg, unlike the US and UK systems, voting is compulsory.)
Unlike the eVAC solution, I want a system that does *not* rely on specialised voting machines. Voting should be accessible online from any network access, and should be as easy as online banking. In other words, it should be a server solution.
I also want a system that can be used anywhere. This may be a pipe dream, but hey, this whole thing is a pipe dream at the moment!!
The way I see it, specialised voting machines have the following problems:
- availability: one problem cited in the US was the lack of available machines in certain districts (which more often than not 'happened' to be Democrat...)
- inconvenience: Why do we need to go and stand in long queues to exercise our sliver of democratic privilege anyway? this is the 21st century!
- flexibility: the inconvenience thing also prevents the general public from a greater participation in how society functions (but that's something for down the track)
- tampering: a number of reports also cited that machines were mysteriously shut down for 'maintenance'. Later, many machines appeared to be unavailable for scrutiny (and the data they contained possibly destroyed)
OK. So the server solution isn't without drawbacks either:
- tampering: all data being sent to one location is a very tempting target for tweakers... There is a very simple mechanism for discouraging this: allowing the voter to review (and even modify?) their ballot.
- control: access to data in one central location is much easier to control.
- trust: how do you know that the final result presented is a true representation of the input? How do you *ever* know this? This is what scrutineers are for, and why it is critical for the workings of any voting system to be open for viewing.
Any new system must achieve at least the same standards of integrity, verifiability, and general confidence in use as the one it is replacing so, before we go into details, let us for consider what a voter must do in order to successfully place a vote:
- Registration: First off, a voter must be entered onto the electoral role. ie submit whatever personal details are needed to establish that they are, in fact, eligible to vote...
- Identification: On voting, voters must identify themselves
- Declaration: The voters must declare that they have not voted anywhere else.
- Acceptance: The officer, on confirming the voter's eligibility, crosses their name off the role and issues voters with ballot papers
- Submission: Voters make their choice (in confidence) and deposit their ballot in the box provided.
From the POV of the polling officials:
- Audit: All ballots papers must be accounted for
- Procedure: All votes must be counted.
- Verification: Scrutineers must agree that the voting is proper
So, how do we go about meeting these criteria?
- Registration: this is going to depend on locality, and is best handled by a separate database. All an open vote system really needs is an identifier and a password. Each entry should be referred to by the main electoral role database. Registered voters should be provided with their ID and password.
- Identification: A voter provides their login and password. They are then given options to enter, view or edit their ballot. This provides opportunities to: record their vote, review their recorded vote for any irregularities, and to change their minds! (Why not? So long as all changes are recorded!)
- Declaration: A voter may vote as often as they like: ie, only the last entry will be counted. An audit trail report may be providedto the voter on demand .
- Submission and Acceptance: Both criteria are covered by one action: submitting the completed ballot (after it has been validated). This fixes one problem with the current system: after you're crossed off the role and given your ballot papers, there's nothing to stop you walking out (in oz, it is illegal to *deliberately* cast an informal vote, or incite people to do so: actually, invalid votes are surprisingly rare, for the lower house, at least)
- Audit: Checks on the validity of the count can be made at a number of levels: the voter can log in and confirm that their vote is as they remember it, vote transaction details (of varying levels) can be sent to various emails for scrutiny etc., the voting station can store a list of ballots cast, central stations can store stats. on how many votes were received from how many stations (10,000 votes for Scudder only from *this* address between 5:50-5:55pm??? Hmmm! All these people seem to have death certificates...)
- Procedure: The database stores the raw votes, and useful stats like time of voting, nominal seat/district. Should be simple enough to provide totals etc.
- Verification: The raw data should be available to all (with exception of who voted for whom)
I think that lays out the bare bones of what I envision.
What next? I will start pottering about with a database design, check out whatever the various Electoral Comissions require, and let anyone wishing to comment in passing do so!
Then, I might be ready to set up an open source project...PS:
...Oh Yes! We need a name: suggestions welcome
Personally, I like the sound of 'We, The People'