Make election_vote records anonymous

Hi Antoine_k

Quite busy now - I'll be able to respond to this in more detail later.

I thought I'd just post some fairly relevant facts:

• There's already a bit of separation in place:
  • "Ballots" record that the person has voted (necessary for preventing multiple votes). Stored in the election_ballot database table.
  • "Votes" are how someone has voted (the politically sensitive part). Stored in the election_vote database table.
• If you somehow remove the "ballot_id" from the election_vote table, then all votes are completely anonymous, because the link between ballots and votes is broken
• The ballots (election_ballot) table also contain one item of personal information - the IP address. But you can use the IP Anon module to remove IP addresses (after a configurable period of time).

The feature you propose should be accomplished as a setting in election_vote.module. It would not really be possible in a separate module.

Regarding the use case, I can see why you might want completely anonymous votes. There are disadvantages though:

• impossible to audit previous votes for security - obviously if there's a security problem you should just re-run the entier election
• the "undo" feature would not be possible

BTW a colleague of mine suggested an exotic solution a while ago: you could encrypt the "ballot_id" with the user password, or with a separate password set by the voter. That would be extra effort while voting of course.

The column {election_vote}.ballot_id can be left NULL.

function election_vote_schema() {
  // ...
      'ballot_id' => array(
        'description' => 'Relates to {election_ballot}.ballot_id.',
        'type' => 'int',
        'unsigned' => TRUE,
        'not null' => FALSE,
      ),
  // ...
}

Here's how you might do it (clear caches after applying the patch).

Quite simple really.

By the way, the statistics (as they currently are) break if you use this. And any other DB query that uses a JOIN between the election_vote and election_ballot tables will no longer be reliable.

Yes that would be how you'd do it.

Meanwhile, I'm not sure about whether this should be added to Election.

It's quite a strange feature, and it adds a bit of confusion (votes are kept anonymous anyway, just not from those with database access and a bit of SQL knowledge).

Those with admin + database access will normally be able to see a whole lot of personal/sensitive information about a website's users - thus usually this kind of access should be highly restricted at that level. Beyond that, sometimes encryption is used (with credit card numbers or user passwords) but it seems over the top to do it with other information.

Votes are peculiar in that nearly all the information needs to be read very easily - the main bit that's sensitive is the relationship between a vote and the voter. Encrypting a relationship seems to be quite exotic to me. And who should be allowed to decrypt this? Just the voter? Or administrators/developers too?

Hello

I was looking for the exact same option.
And I had pretty much the same idea as Antoine_k for the implementation.

Although I agree that the administrator and whoever has access to the database, already has access to all sorts of sensitive data, it is not truly a secret vote if it is possible to check the relationship.

On the other hand, even i you hide the relation is is not "secret" for someone monitoring the database. (all you would have to do is track changes in the two tables with some other dirty script and there you go knowing who voted for what)
So acknowledging this limitation I think it would be a nice compromise to "anonymize" the election after the election has been closed and then disallow reopening it. This would solve the issue with the changing the minds while the election is ongoing. Yet afterwards it is not possible any more to track the voters.

Its just an idea...

On the other hand, even i you hide the relation is is not "secret" for someone monitoring the database. (all you would have to do is track changes in the two tables with some other dirty script and there you go knowing who voted for what)

Indeed - actually, knowing the time someone voted could reveal their identity, if you were also watching something else, like "Session opened for @name" watchdog messages. That's why the election_vote table doesn't store timestamps.

I think we can aim to add extra protection or anonymizing to cover the case of people who might have accessed a copy of the database (maliciously or otherwise). To protect properly against actual site admins would be pretty much impossible.

The site could be monitored outside of Drupal for admin access during an election and any such access would raise an alarm.

The column election_ballot.value can currently cause a vote to not be counted. This needs to be taken into consideration if election_vote.ballot_id is to be allowed to be null.

This does FPTP and referendum, but not STV, which requires more elaborate changes to make it work.

@#8: $ballot_id is not used again in the function, so I don't see why that extra code is needed.

This is fixed for all built-in types except STV, which will be done in #2834454: Make election_vote records anonymous for STV.