Open Vote

[dch24]

The Method and Deadline for the Daniel Robbins Decision is going along quite nicely. Although I note that the Trustees have decided to keep the doors closed, there is this really great idea by Square Bottle that we vote on whether to give drobbins what he has offered, or asked for, yes or no.

And there were some very well-thought-out replies about how "real" voting is hard. It's really hard. (The USA is having its share of troubles here.)

So I've started this thread to discuss an "Open Vote." I've got an idea on how it could be done; details below. Is it even possible to do an "Open Vote" and have confidence in the outcome?

Proposed Open Vote System
Since voters might be swayed by the results before the vote is over, it is crucial that the vote tally be secure until the vote is closed. Security is perhaps the core issue that makes fair voting so difficult. There are also issues with different voting systems, which is a branch of game theory (Economics and/or Computer Science). So taking that all in mind, one way to do it would be this:

Each person who wishes to participate in the vote must register their GPG (or PGP) public key to be considered a valid voter. The public key is associated with an email address, and to prevent "stealing" someone's vote, and/or "dead voters," the email address would need to be associated with the voter's identity. So a voter list (a roll) would be necessary, such as the list of current Gentoo developers. (I assume each developer has a known email address.) In other words, if a gentoo developer has already published their public key somewhere (available in a google search, for example) then that key would be the only one accepted for their vote, until the key expired. GPG keys and a "web of trust" would make this much easier. So one question I don't know the answer to is: should keys only be accepted if there is a web of trust linking each key back to the organizer of the vote?

Next each voter sends a GPG encrypted and signed email containing their vote. (The email would be encrypted using the vote public key, generated just for the vote and distributed in a signed email signed by the organizer of the vote. The email would be signed by the voter.) The email is sent to a specific email address at a subdomain that resolves to a server that reports a temporary failure. That's my idea, at least.

The email would need to follow a basic format (e.g. each option is described by a keyword; the very first keyword in the message body is considered the vote.) If any vote was invalid, the anonymized version would be published (see below) -- and the vote would not be counted.

Technically, this would limit the vote to the maximum retry time set out by the SMTP RFC.

No emails would be received until the vote was over; then the server would start accepting emails, but not accept any emails it had not previously seen and refused (by keeping a hash of the email headers refused). If the server was compromised during the vote, the results would not be available on the server--only the hash of the vote headers. After the vote was over, all the votes would be received and counted. Any voter whose vote was not delivered after it was rejected during the voting period would be counted as a no-show, but the "rejected initially, later no-show" count would be published, and if it was statistically significant, the entire vote would be invalidated.

The entire vote would be published--as encrypted, signed messages. No two messages would be identical, so voters could verify that their own vote was present. Also, anyone could count the total number of encrypted votes and verify that it matched the total number of votes (so no vote stuffing). A script used by the vote officials should verify that all the decrypted votes were from the vote roll, each used only once. Invalid vote emails would be published in anonymous decrypted form (the message body but not the sender, etc.) in the same file as the encrypted form of the email, and clearly marked, so anyone could verify that the vote was cast, but invalid (to settle disputes).

Two weaknesses (there are probably more):

1. A developer who was absent, who never had provided a key, might have someone impersonate them by gaining control over their email account, providing a key, and voting as them.
   
2. Individual votes could be "bought" by private email negotiation.

Like the voting system in the USA, the organizer of the vote should probably be a group. That is, the initial vote public key distributed to everyone would need to be signed by a key that could only be used when people from every interested group were all present, and approved. A password-protected key could be used, where the password was one entered by each group in series (a concatenated password). There are probably better ways of doing this.

At the end of the vote, someone representing each group would need to count the votes so that each group was satisfied, and "conceded the vote." They should verify that: any claims of missing votes were resolved, the number of invalid votes was statistically insignificant, and that the total number of votes matched the list of available votes, and that all voters voted only once. Using a script to count the votes would be less error prone; the script source code could be published and available openly. The individual votes should remain private.

The vote data should be securely wiped from the disk after all officials "conceded the vote," to protect voters' identity. Other security measures would be a good idea too. (e.g. a separate firewall that only accepted SMTP connections; unplug the box from the network when the SMTP maximum timeout expired and no more votes were technically possible.)

That's a long post. Sorry!

[jonnevers]

[dch24]

You are right. What do you think of an open vote?

[thewtex]

The GPG idea is pretty cool, but a lot of people do not have trusted, signed keys. Also, what about the users and retired developers? They are part of the community too.

Here is an idea that follows KISS:

Forum poll. You can only vote if you had registered before drobbins made his offer.


It is not perfect, since everyone does not necessarily use the forums, but it is decent.

[dch24]

Forum polls can be hacked, but a significant number of people would notice if the results were wildly inaccurate. And I think the drobbins offer will not be a close vote. I like the idea.

I was thinking a lot of the complexity of a secure vote would be automated. For example: I think when voters sign up to vote, there should be a "test vote" run. The question and the results should be something completely different. But it gives every interested voter a chance to check everything out.

[Genone]

FYI: For votes inside he dev community we have a working system, but as it's tied to user (shell) accounts on a specific server that's not really extensible to general users.

Some things to think about if you want to perform a community wide vote (that list is definitely incomplete):
- who is eligible to vote? (forum users are just a subset of the whole community for example)
- how to make sure a single person only has a single vote? (relying on forum accounts/email addresses isn't a good idea here)
- how to inform the eligible voters about the vote? (not everyone reads the same things)
- how to make sure the results are correct/can be verified? (not possible with a simple forum poll)

[dch24]

[Genone]

[Insanity5902]

No matter the voting system, the answer isn't a clear yes/no.

Daniel has imposed a lot of strings on his offer, it isn't to just come in and clean up the system. This topic though is for another thread.

The voting system needs a third option, of yes having Daniel come in and help, but on our terms or a set of agreed upon terms from all parties involved. Gentoo Trustees, Council, Devs AND Community.

The voting system within the Trustees, Council , and Dev's has already been implemented as previously mentioned.

The voting system needs a why for the Community to Vote. Sadly, the community votes can be strewn and altered, this is with any voting system. Using forum accounts is a good why, using GPG keys is good, but what is to prevent me from going out and registering 20 e-mails and getting gpg keys on all of them ... nothing.

If this system was already in place, then it would of been easy to allow only pre-registered GPG keys to the vote. Implementing this now would create problems of people false registering.

What we could end up doing. It's using the freeness of CACert's gpg and certificates to verify e-mails, qyeury this against the Forums. Only e-mails listed in the forums user accounts are allowed for voting. This would limit which e-mail address can be used, and forces those who want to vote to jump through a couple of hoops to register at CACert and get a valid certificate.

This is just off the top of my head, so I'll post back if I think of any other clarifications.
_________________
Join the adopt an unanswered post initiative today