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?