Workspace:Proposed voting system
From Pirate Party UK Wiki
Contents |
Plan 1
Database Layout (Quickly jotted down, normalisation might be a bit wrong)
tbl_Member_key
email_address generated_key has_generated_voter_card
tbl_voter_card
voter_id voter_username voter_password
(Vote related tables)
tbl_vote_question
vote_id vote_text
tbl_vote_option
vote_id* vote_option_id option_text
tbl_voter_vote
voter_username* vote_id* vote_option_id*
Basic Idea
Each member gets sent an email with a link to a page, where they get generated a voter_username and voter_password which can't be tied to them personally, turn off mysql entry timestamps, turn off web server logging, turn off all logs so there's no way we can identify them.
(Maybe except a simple simple log, anonymised IP address log. So we can identify someone trying to brute force any codes.
e.g a list of literally
127.1.1.1
127.1.1.1
127.1.2.1
127.1.2.1
127.1.1.1
127.1.1.1
127.1.1.1
127.1.5.1
127.1.1.1
127.1.1.1
So we don't know the time, or anything else. Just so that we can check for any IP address that hits us over 1000 bloody times :D )
(Pages were chosen to display these voter_card details as we can do https:// and a lot of people throw a huffy about emails containing sensitive information. Although if you look at downfalls, email becomes more attractive)
This produced an anonymised voter account, which can be used to vote on the issue and we have an anonymous voting system, even to the web admins :o Oh noooo.
Disadvatanges
- The major downfall of this is that people will be screwed if they lose the voter_username and voter_password, as it'll only be generated once and can't be regenerated since it isn't linked to the email address. We just need to make the page as simple as possible, biggest text, tell them to write it down on paper AND save to notepad or something.
- But! What if their connection dies, and our server sends it and they never recieve it. This is a big issue, which could be reduced if we used email (We don't keep non-error log of email sent). But there's the argument from those that it's insecure to send the anonymised username + password in plaintext via email, it'd have to be a discussion.
- We get to know who has voted and who hasn't via the "has_generated_voting_card", my answer to this is to bring "Abstain" into every vote, with "abstain" the default vote for any generated voter_card. So we do end up with a non-anonymised list of who and who didn't vote (Not public of course, but a cause for concern for some) but it doesn't tell us anything politically. Abstaining isn't the act of not voting, it's an option in the vote so it isn't a list of those who abstained.
Advantages
- Easily prevent vote stuffing, total votercard records must equal total of "has_generated_voting_card = 1" from the first table. Unless someone stuffs fake users into the first table (Which wouldn't be possible since we'd have a public voter-number account, so exceeding registered user number is impossible)
- We can have audit log of the vote over a period, privately kept but take a snapshot of the totals each hour to show no last minute changes or falsities. The whole audit could actually be made public post-vote so everyone could look it over
How it would flow
1. Input, list of members. For each user take email address and enter into tbl_member_key with a user-specific key (sha1 of email concatenated with 20 random characters, or insert a random character inbetween every other character of the sha1)
2. Each email address on that list is emailed saying "The current rounds of votes are on the following questions (List of all tbl_vote_question.vote_text options.
Please generate your votercard at pirateparty.org.uk/vote/generatecard/email address/user-specific key outlined in part 1
3. When the page is visited it chhecks first if the user-specific key matches, then checks if they have already generated a voter card. Only one voter card may be generated per email address, ever.
4. Shows the user a completely random (Checks doesn't already exist) username and password combination on screen, inserted into the tbl_voter_card table.
5. Use those details to do voting as normal
Secondary Plan
Database Layout v2 (Quickly jotted down, normalisation might be a bit wrong)
tbl_members
user_id
(Cut down, not the actual table)
tbl_member_vote
vote_id* user_id*
(Vote related tables)
tbl_vote_question
vote_id vote_text
tbl_vote_option
vote_id* vote_option_id option_text
tbl_voter_vote
vote_id* vote_option_id*
Basic idea
Anonymise the vote itself, cut out the voter card. Don't record who made the vote, just that a user has cast a vote on each issue.
User makes vote -> mark them down on voting on issue X
Insert into tbl_voter_vote the vote, no record of who made it.
evaluation against the first
Pretty much the same as above, audit options seem to be viable just as well.
advantages
- No messing around with secondary accounts for voting only
Disadvtanges
- Admin knowing who has voted on which issues : that issue is deepend as little since the first, but relies on mistrusting the web admin.
- Can't change a vote, this anonymises the vote itself and as such once a vote is made that's final.
- Can't view your votes, as in "You voted option B"