sybil attack defense strategy in Loomio

@alexanderzatko is this something you've experienced in groups you're a part of?

Not sure whether I understand the same as you in "experienced in my group", but there are real-world cases in "my group" of the world inhabitants :-), where this occurred. See http://en.wikipedia.org/wiki/Sockpuppet_%28Internet%29#Examples_of_sockpuppetry

The problem of fake identities is expected to be more of a problem in internet voting, because the costs of performing fraud is (currently) low. See section 3.2.3 in this document for a nice wrap-up:
http://www.sos.ca.gov/elections/ivote/appendix_a3.htm

@alexanderzatko I would suggest just sharing your possible solution; then the loomio devs can respond.

There are some robust (but possibly hard to implement) solutions like this one:

http://aamas2014.lip6.fr/proceedings/aamas/p1569.pdf

But I would be happy (others might not be) with a simpler solution, that might not take too much engineering effort to implement.

One idea is to delegate checking identity to a party that does it as a part of their regular business. One such option is a bank. You could allow an account to be created only if a person deposits a small amount of money into Loomio account using source like credit card or bank account that is owned by her. Advantages are:
1. Loomio app can check that the name on the account matches name on the bank/cc statement, thus getting a proof that human requested the registration
2. Asking for money (even a small amount, like a dollar or less for some communities) would deter most attackers
3. Loomio would create a revenue source that could be used to finance operations. You could potentially build-in an account expiration, so folks would need to periodically renew.
Disadvantages:
1. for some people paying money for a right to participate in decision making might seem preposterous, but I bet there are many issues where people will WANT to be heard and will not mind paying.
2. the act of making the payment might deter people from registering. To some degree, this problem might be addressed by engineering means - make paying as easy as possible.

Note: you could make this account verification optional - to make it possible to turn on or off on a group basis.

Finally, given that Loomio has a built-in functionality that allows coordinators to make registering in a group invitation-only, there exist an option to "outsource" account verification to group coordinators. They can create (outside of Loomio) a policy according to which only people who send a payment will be able to register. Of course you would be risking loosing a potentially interesting revenue stream, because the coordinator could direct the payments to an account of her choosing.

I understand this issue in theory, but in practice I haven't it seen it being much of a problem. In general, we only put resources into issues we actually find affecting users in practice.

The way Loomio is designed, minority voices can be heard. If one genuine person is disagreeing with 100 sock puppets, if the one person's position is actually the right one, I hope it would be apparent to another genuine participant coming in. That one person could easily block the proposal from the 100 sock puppets.

The larger issue of identity authentication is an important one. We've built one custom instance of Loomio for a political party where members had to be verified against their official party membership list. That seemed to work pretty well. I assume we'll need to look more and more into identity authentication features. I assume this would always be optional, since many groups prefer to allow anonymity.

@alanna wrote: "The way Loomio is designed, minority voices can be heard. If one genuine person is disagreeing with 100 sock puppets, if the one person’s position is actually the right one, I hope it would be apparent to another genuine participant coming in. That one person could easily block the proposal from the 100 sock puppets."

well, from the outside, nobody can tell whether a particular account is fake, so I do not understand the reasoning here. Possibly it is caused by my confusion about the blocking functionality, but that I need to study and maybe discuss in a different thread.

I consider the "sock pupet" abuse type a subset of identity abuse, so as long as that is on Loomio dev team's radar screen, I rest my case.

I work for a large membership organisation and if we were to use Loomio or something similar for internal processes it would have to be integrated with our membership system - or it could only be implemented on a very local level, where people are more likely to have some connection already.

Both examples come with solutions.

Where I could see it being a problem is if for example you were using Loomio for a specific local campaign and one faction or another could attempt to create multiple sock puppets to manipulate decision making results.

I wonder if then the ideal solution is more that anyone using Loomio for a local campaign should be using it to supplement face to face organising

@alexanderzatko the idea is that because Loomio is a consensus system, not a maiority vote system, one person blocking can be enough to get around sock puppets, or even just a disagreement with a good reason. Having a lot of sock puppets vote is "easy", but having them all argument against a block still needs that one sensible argument.

@mathewdanaher if you need a custom solution to integrate Loomio with your membership database, get in touch (contact@loomio.org) and we could potentially work on something with you. As I mentioned, we've delivered commissions to sync with membership systems before.

@joopkieftelapingvi, where are you reading about Loomio being a "consensus system" and not a majority vote system?

Question: if a moderator was concerned about this, can't s/he use an offline process to verify identity before approving a user to join the group? If so, this would mitigate this issue when dealing with smaller groups.

Hi @jeandaniel. That's what I meant when I wrote:
"...Finally, given that Loomio has a built-in functionality that allows coordinators to make registering in a group invitation-only, there exist an option to “outsource” account verification to group coordinators. They can create (outside of Loomio) a policy according to which only people who send a payment will be able to register. Of course you would be risking loosing a potentially interesting revenue stream, because the coordinator could direct the payments to an account of her choosing...."

That one person could easily block the proposal from the 100 sock puppets.

...

...one person blocking can be enough to get around sock puppets...

What if it's 10,000 puppets, one per community, single-handedly blocking everything?

I think @alexanderzatko is onto something really important here; Sybil attacks are problematic in general, and combined with the (very important!) blocking functionality could be pretty devastating.

@elimisteve -- Each sock puppet (or any malicious user in general) who wants to block a proposal needs to provide a plausible rationale for the block, or people will just ignore it and proceed anyway. An "empty" block, with no explanation, is completely worthless and functionless, at least in the community that I work in most. And a block with a compelling reason attached should be considered, even if it was posted by a sock puppet, in my opinion.

@sirwumpus Thanks for the response.

...or people will just ignore it and proceed anyway

What does that mean, though? Does Loomio not have a notion of a proposal that passed? Does a single block not prevent this, Occupy-style?

Looks like I need to use more of Loomio's functionality :-).

The meaning of a block is defined by each group for themselves. So if someone was intentionally disrupting the process, and was not actually bringing up valid concerns, I'd assume the group would either ignore them or boot them out.

@elimisteve seems to be under the wrong impression about the meaning of "Block" that I was when I saw it the first time. IMHO Loomio needs to change (as fast as possible) the default label "Block" as well as the corresponding icon, because this will continue to be source of confusion for most people. Some will see it as a manifestation of "occupy-style" concept and others (majority) will look at it with disbelief, thinking that Loomio allows an individual to stop a voting process.

@alexanderzatko My group that I brought to loomio had a long discussion called "How we use block vs disagree", in which we came to an understanding that worked for our particular group. Several differing understandings were presented by different people to start with, each of which was reasonable in its own way.

So based on that experience, I can agree that new loomio users don't seem to all arrive with the same ideas of what a block means. But since the system is flexible enough for it to mean different things to different groups, I'm not certain that is a big problem.

Do you have a suggestion on what the word "Block" should be changed to, or what icon would be better than the current one?

An improvement would be welcome; I'm just not sure that any change would be as good of a compromise as what we have now. I wouldn't want to see the system change in a way that suits one group, only to make it less suitable for some other groups. Customizing these options on a per-group basis seems to me to be the best option, and I think I've seen that potential feature discussed before.

@sirwumpus
I just read about that potential feature here:

Making a Decision with Loomio 1.0

In Summary

Here’s the default set of decision options (we’ll be adding plugins for different styles of decision-making):

agree – I think this sounds good
abstain – I’m happy for the group to decide without me
disagree – I think we can do better
block – I have really serious concerns

This set of four options came directly from our experience of collective decision-making at Occupy. We’ve found this protocol to work well in all kinds of groups. There’s more nuance than a simple yes/no binary, but it’s simple enough to be really easy to grasp.

@alanna @alexanderzatko @sirwumpus Flexibility is great, but having the same icons mean different things on different pages sounds like a UX horror story, don't ya think?

There could be different icon sets, I suppose, and as long as there's not too many to memorize, then that could work...

I agree @elimisteve -- If we can't have consistency between groups (which I think we realistically can't, except for small sets of related groups) then distinctive icons and text would be a very good thing to aid understanding.

But that feature is drifting far from the topic of this conversation, so I suggest that it be discussed here:
https://www.loomio.org/d/tOWDImxb/customizing-yes-no-block-abstain-text

or voted up here: https://trello.com/c/KM1cupt1/62-customisable-labels-and-colours-for-4-voting-options-per-group

O:-)