Determine how we will handle voting

[cweagans]

I didn't just make the change in the bylaws because it affects our day-to-day workflow, and I figured people would want to have some say in how this works. If/when we land on a solution here, I'm happy to write up the actual changes to the bylaws - just want to gain consensus here first.

Relevant sections:

• §1.V.2 (Remote participation)
• §1.V.8 (Vote)
• §1.IV.1 (Admission requirements - may not be changed)

We may need to add some extra definitions depending on the result of this discussion.

To start with, I propose that we use PGP signed email messages. When we have a vote, the member that's running the meeting should send a message to a members list with a summary of the question and the voting options. Each member should then respond with a signed message with their vote. This way, the email messages and signed responses can be archived with meeting minutes so that we have a paper trail.

This requires that members have a known PGP key, hence my suggested modification to §1.IV.1 -- there would be an added requirement to supply a PGP public key as a requirement of membership. This is easy enough to do with Keybase - they'll even generate a key for you, and you can create a signed message in the keybase web UI, which lowers the barrier to entry.

If PGP is not an acceptable solution here (and I totally understand if it's not - PGP is not a very simple thing in some cases), perhaps something like BitCongress would be a valid alternative?

I think that something that's based on strong crypto would be a good idea, as it eliminates scenarios in the future where there's any doubt about how or if somebody voted on a given proposal.

[ergonlogic]

I agree. I'd prefer PGP, personally, since it's mature, secure, and doesn't tie us down to any specific software or service. We should also make a habit of signing each others' keys whenever we meet up in person, to build out a proper web-of-trust.

Also, we should probably have the secretary of the vote sign the archive to show that they've verified the signatures, or something along those lines. Any way you look at it, we'll want to document the process thoroughly, and perhaps provide a script to automate the verification, or something.

This would also facilitate secure communication channels between us. We're likely to have SSH and sudo access to many of our clients' systems. We'll need to be able to communicate about the sensitive data we have access to as securely as possible.

[ergonlogic]

We discussed this issue in the latest co-op bootstrap meeting. We were thinking that one way to keep things simple here would be to eliminate email from the equation and just use signed git commits to record votes: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work.

[cweagans]

Oh, that's an interesting idea. So the person calling the vote would sign a commit that adds a file with the details of the vote, and then each person adds their vote to that file and does a signed commit? That way, we're forced to have a timestamped record of our votes, and there's no question about who voted and when. I'd be okay with that.

How much detail needs to go into the initial file (i.e. should we include details of what we're voting on and the different choices)? Where will we keep those files? In this repo?

[ergonlogic]

We already have some examples of Board resolutions: http://coop.aegirproject.org/by-laws/examples/. We should perhaps adapt these to the voting mechanism we're looking to adopt.

In addition, we should probably determine when to use this protocol. I suggest that we limits it to resolutions in General Assemblies and by the Board of Directors. I don't think we need this level of verifiability for more operational concerns. This also crosses into issues I raised in #2.

[anarcat]

Hi!

I have been asked by @ergonlogic to comment on this issue, given that I have some experience regarding online decision making. I assume he thought so because I was one of the driving forces behind the Decisions Drupal module, which aimed at providing many different voting systems (voter runoff, 50%, etc); i am part of the Debian project, which is one of the largest online voting communities and probably as well because of my involvement in founding Koumbit.org.

So. My first answer to chris was "what do you mean by 'secure voting'?" :) Reading this issue, I am not sure I see what the requirement is here, nor why PGP is necessary.

I have not made definite research into voting system, and so I shouldn't be considered a specialist, but I seem to identify many components that would make a voting system "secure", or, to put it a better way, optimal:

• verifiability: one person can only vote once (or as many times as they are allowed by the by-laws) and no other person can impersonate such people
• anonymity: a person's vote cannot be associated to the person (avoid blackmailing and pressured votes)
• representation: people have a say in decisions proportional to how the decision affects them

I am probably missing some issues here, but I thought it would be important to broaden the scope, since you guys asked for my opinion. :p Obviously, @ergonlogic expressed concern about the verifiability aspect, but I think it is important to introduce the other aspects since, right off the bat, the original from @cweagans mentions both "voting" and "consensus" which in some cultures can be seen as contradictory.

In fact, once could see voting systems as a failure: in my experience in Koumbit, voting was often a sign of us failing at our consensus-building process. The "though votes" we had were often due to lack of preparation in bringing proposals, vague proposals if not failure at agreeing on the decision-making process itself. So in my mind, it is important to think of the process that happens before you bring up a vote as much as what happens in the vote itself. In that regard, I think that tools like Loomio are really interesting platforms because they shift the focus from the vote to the discussion process. A proposal is brought up only after a discussion has happened, so it is in context, and has a documented outcome as well.

I should also bring up the fact that there is a plethora of election systems out there. We are used to the "50%+1" rule, but we see how western democracies have failed through that process, bringing absurd situations where a small minority of the voting population actually wins an election, with the vast majority voting directly against (or, in some case, not at all). Wikipedia has an interesting article about voting systems that goes over some of those key protocols and mathematical properties. Without going into details there (as I am a little out of my depth there), it seems obvious to me that there should at least be a system where a ballot should have multiple ranked options, if you are going to have votes at all, and have a reliable, deterministic and fast way of determining the outcome.

(By the way, Matt Corks has way more knowledge than me regarding those voting systems.)

Debian, in that regard, certainly has an interesting voting system. A quick search brought me to this fairly reasonable introduction to devotee the Debian voting system and software. Ironically enough, devotee is not packaged in Debian so deploying it would probably be a challenge, to say the least, especially since it is tightly coupled with Debian.org's infrastructure (including an LDAP server, for example). In Debian, the votes are not anonymous at all: for example, you can see who voted what in the last vote. This is partly because it is difficult to have a system that is both verifiable and anonymous, the latter being often just sacrified in most online voting systems i have seen.

Still, I encourage you to checkout the git repository of devotee, if only to figure out how the software is architectured: https://vote.debian.org/~secretary/devotee.git/

Finally, I should mention that using OpenPGP is a significant barrier for entry for any community. It has been a long standing problem in the Debian community, making it seen a little too elitist and difficult to get in, mostly because the main OpenPGP implementation (GPG) is so hard to use. Keybase may help there, but there are a significant number of security and usability issues there, which I detailed in this blog post. In particular, since private keys can (and are encouraged to) be stored on the proprietary keybase servers, I wouldn't count on keybase for my elections, unless i'm ready for them (or any determined attacker) to start hijacking my voting process. :)

Also, the properties you are looking for in PGP may actually be harder to implement than you think. For example, to be usable, a OpenPGP key needs to be certified by you or someone you trust. This could be difficult to accomplish if you haven't met the person and exchanged fingerprints. Keybase, again, helps with that, only insofar as you trust various social networking sites (e.g. github) and keybase with establishing that trust. And if you are going to do that, why bother with PGP at all and simply use Github's authentication systems? :) There is additional security in having multiple verified sources, but that's not a requirement on keybase anyways... (e.g. there could be only an HTTP or DNS proof). Furthermore, what happens if you look back at a decision and the vote from person X is signed by a revoked key? Or that the signatures on that key are revoked? Do you have software to actually verify those certifications retroactively? gpg can be quite clunky in that regard...

Finally, I agree that variable decision-making processes may be a good thing, but it cuts both ways: how do you decide what is critical and what is not? If something is not critical, why make a process at all? Often, when something is too complicated, it is never used or simply bypassed, so your shiny secure process is simply overlooked or used as a bureaucratic weapon in internal politics...

I'd be happy to discuss specific issues further if you have any more specific questions, and good luck!

[anarcat]

Ah, and one last link dump for you... I was trying to find that voting system that worked based on anonymous tokens that would be issued to trusted parties and would allow only one verifiable vote per person, but I couldn't find that in my bookmarks. I do believe such a system exists, however, and is a key component of future online democracies. If not, it should be built.

That said, there are other alternatives for software that you could look into:

• Liquid Feedback - "liquid democracy", is a fundamental concept in scaling democracies in that it allows a person to delegate their vote(s) to others, based on topics (e.g. "i think Antoine should vote for me in all aspects regarding network engineering, but I will vote on street maintenance"). you usually still have the right to revert to voting yourself if you disagree with your "representative"
• DemocracyOS was also lying around in my bookmarks, i haven't looked at it any further.

[ergonlogic]

Thank you, @anarcat. You've brought up a lot of very valid points.

This issue stemmed from an online, voice conversation between (some of) the founders of the Aegir Cooperative. That conversation wasn't particularly well-documented, and so lots of the context was probably lost in being written up here. The scope of what we're looking right now is drastically smaller than the full online-democracy systems you've pointed out.

Basically, we're looking at providing more verifiability to the decision-making processes of the Aegir Cooperatives 2 main policy-determining bodies, the General Assembly and Board of Directors. These meetings are, by necessity, online, since we're broadly distributed geographically. Up until now, we've operated broadly by consensus, but have also kept things fairly informal. As we approach the formal founding of the co-op, we'll need to develop and start following a more rigorous process.

So far, I suppose we've largely relied on simply recognizing each others' voices. We haven't been recording our meetings, and don't particularly want to. As a result, we aren't really in a position to go back to any particular decision and verify that it was valid.

While the more complete solutions certainly seem interesting, I don't think we have the resources, at the moment, to research, deploy and or implement anything so elaborate.

[ergonlogic]

FWIW, my reason for asking @anarcat's opinion had as much to do with his work on monkeysphere, as all the other reasons. From that project's page:

The Monkeysphere project's goal is to extend OpenPGP's web of trust to new areas of the Internet to help us securely identify [...] each other while we work online.

I believe that our most immediate need can be summed up as: a process for verifying the identify of voters, and the content of their votes, during formal decision-making instances of the co-op.

Just to be clear, I'm very interested in the other aspects of online democracy raised by @anarcat. However, I believe that we're currently trying to come up with a pragmatic solution for a much narrower problem.

[anarcat]

thanks for the context.

i do not believe recording meetings is useful, and may make things really uncomfortable, so i usually discourage people from doing that. having good minutes, however, should help a lot in figuring out past proposals.

in my experience, finding out who voted what hasn't been such an issue as much as figuring out what exactly was decided. koumbit has developed the habit of taking verbatim minutes, which makes it really hard to figure out what happened in a meeting, in retrospect, as there is too much data to sift through. having simple and systematic minutes help with that. once the minutes are published, it's the responsability of the people that attended that meeting to make sure they are accurate and that the decisions taken are well reflected in the minutes. this is often institutionalized as a specific step ("Adopting minutes from previous meeting") to make shire this is done systematically. A bit like how a git commit checksums previous ones. :)

So I do not believe cryptographic signatures are necessary here, especially if you have real-time, voice or chat meetings. One or many secretary (or all participants!) may sign the meeting to coroborate that it is accurate, for example.

Ah, and another thing that you might like is various "meet bots" that are useful in handling meetings in online conferences and chat meetings. This was described as a broader moderator bot in koumbit's documentation, but was never actually used at Koumbit. Such a bot (Zakim) may still be in use at the W3C, for example. Debian work groups often use MeetBot to take down minutes during IRC chats. Another IRC bot, which I maintain a Debian package of (Sopel) also has a meetbot module. None of those handle voting at all, they are mostly used to hold minutes through IRC.

[anarcat]

I guess I need more information about how you plan on holding meetings and making decisions. If things are synchronous (e.g. IRC, in-person meetings, voice/video conferences), then PGP signatures and similar processes will just be a pain in the butt and will bring little extra verifiability - except maybe for IRC meetings, where user identity can always be contested. But even then, in synchronous conversations, you reach consensus or vote, and note down the results, and then people can contest the results at the next meeting or after the minutes are published. I think that is a rigorous enough process for everything except extreme cases.

If you are making asynchronous decisions (e.g. by email on a mailing list), it may be more pertinent to have formal peer verification processes, because you will probably need a process that make decisions take effect after a specific deadline, and you don't want to have to go back and question that decision after that deadline (and therefore be able to verify that decision). In this case, PGP may be useful, but you still get into the problems of actually verifying the other people's keys. You may be able to use TOFU but that is not a trust model that is well supported in GPG and can bring all sorts of weird issues.

So, TL;DR: just hold good minutes, get used to reviewing them and approving them, and have ways of trusting each other (which implies having good ways of hiring and firing people).

[helmo]

wow, thanks @anarcat

[ergonlogic]

I've written up an initial draft for a process we could might here: https://github.com/AegirCoop/aegir-coop-docs/wiki/Resolution-signing

[anarcat]

Small clarification: some debian votes are actually secret, and you get a token that allows you to verify your vote is accurately reflected in the tally sheet. See for example the last debian leader election tally sheet:

https://www.debian.org/vote/2015/vote_001_tally.txt

To be quite frank, I am not sure how useful that is, considering how little the system is know and how inconvenient it is to check your vote.