search

gitcoinco / web

Grow Open Source
https://gitcoin.co
Other
1.79k stars 776 forks source link

DESIGN -As a moderator, I want a mini CLR monitor sybil/collusion attack dashboard so i can see whether mini CLR is being sybill or collusion attacks #6492

Closed owocki closed 4 years ago

owocki commented 4 years ago

User Story

As a moderator, I want a mini CLR monitor dashboard so i can see whether mini CLR is being sybill or collusion attacks

Why Is this Needed

Summary: bc anti sybil is an ongoing problem

Description

Type: feature

Current Behavior

no dashboard

Expected Behavior

a dashboard that is

Additional Information

original CLR attackable spec : https://github.com/gitcoinco/web/issues/6179

this scope is for mini CLR, but could be re-used for grants CLR

owocki commented 4 years ago

@molecula451 @oussema feedback on this?

frankchen07 commented 4 years ago

hm could be useful for regular CLR too. I can jerry-rig something in metabase (show txns for ones made by day or something), but having something less psql db-like would be nice

maybe we can tack this onto ben difrancesco's work?

oussema commented 4 years ago

I think we need to focus on account age, sybill attacks are generally done by fresh accounts, to make a dashbord for monitor is a good idea, but it will be nice if you get more info from Github accounts, there are many github accounts created recently without any project or with only forked projects which means that they are 90 % fake, so it's possible to add information about their github account age ?

molecula451 commented 4 years ago

I would opt for the fulfilled bounty model object playing a key role on this one. Some user that are not willing to contribute or to even come back to the site at least 1 bounty, 1-3 bounties could potentially prove reliability, user activity and engage on the site hence preventing sybill (for users that do not show something reliable on github) the pop-over card that @octavioamu deployed contais this very reliable info for users "on the site"

The motto is about "Grow Open Source" I will assume Owocki doesn't want to discard any potentially collaborative, future, well behaviour users just because their account it's new on "Github"

Hence show me what you got (by metrics) and I'll tell you what you get important key. Trust in the metrics of https://gitcoin.co

oussema commented 4 years ago

the problem for me is simple, for example the next CLR round starts June 15th, til this date , I'll create one account each day, and each hour I'll choose an account to connect with and participate to bounties and help people, with this method I'll make those accounts look like they real accounts.

Let's assume that til the June 15th I'll create 30 accounts, let's assume also that I used this method in the previous 5 CLR Rounds , That it means that on June 15th I'll have 180 accounts created by the same person ( 5 * 30 + 30 =180 accounts).

If a sybill attack wil be launched by those accounts , every account contribute to same grant by 10 Dai , we could estimate at least 3000 Dai of CLR match ( I estimate this CLR from the distribution of the CLR round 5 @owocki ).

It's better now to find a solution to prevent this kind of attacks, you see what I want to say @molecula451 ? and the problem it's more dangerous because it's like snowball effect, the next CLR there will be 30 other accounts , and the next one and the next one ...

molecula451 commented 4 years ago

Could you perhaps capture user's browser fingerprinting on that dashboard

molecula451 commented 4 years ago

the problem for me is simple, for example the next CLR round starts June 15th, til this date , I'll create one account each day, and each hour I'll choose an account to connect with and participate to bounties and help people, with this method I'll make those accounts look like they real accounts.

Let's assume that til the June 15th I'll create 30 accounts, let's assume also that I used this method in the previous 5 CLR Rounds , That it means that on June 15th I'll have 180 accounts created by the same person ( 5 * 30 + 30 =180 accounts).

If a sybill attack wil be launched by those accounts , every account contribute to same grant by 10 Dai , we could estimate at least 3000 Dai of CLR match ( I estimate this CLR from the distribution of the CLR round 5 @owocki ).

It's better now to find a solution to prevent this kind of attacks, you see what I want to say @molecula451 ? and the problem it's more dangerous because it's like snowball effect, the next CLR there will be 30 other accounts , and the next one and the next one ...

All that points out oussema is very accurate. But in fact. How would I be able to age an account for a CLR matching if haven't complete at least 1 bounty yet! and If I am serious on the site why would I bother in aging many accounts - completing many bounties (it's irrational)

molecula451 commented 4 years ago

Let's suppose I have 5 virtual machines deployed with all different user devices/OS.. for each instance I would create a github account for each because I found tasty the CLR matching on Gitcoin. I will age them. But haven't succeed in found a liquidity funder, in fact, nobody have approved to work that certain "new" account to start bounty because funders still do not trust because of new account metrics.

Me being the attacker. Shall I throw-time in waiting to age the accounts by completing bounties one by one and then pretend to make an attack? I would be 6 CLR rounds late some months lost

trust fulfilled bounties

oussema commented 4 years ago

That's right ! if we will use the number of a fulfilled bounties as a metric, to tip grants or other person in mini-CLR , will minimize the effect of the Sybill Attack. And I think for the future , KYC is necessary to controbute to a grant , $250K in each round it's money !

L-KH commented 4 years ago

I am not sure if the number of fulfilled bounties is a good metric for that. we will take an example of a youtube channel grant that invites their subscribers to join the grant and tip only 1DAI. how can that happen if those subscribers are totally new or the first time to use Gitcoin?

molecula451 commented 4 years ago

I am not sure if the number of fulfilled bounties is a good metric for that. we will take an example of a youtube channel grant that invites their subscribers to join the grant and tip only 1DAI. how can that happen if those subscribers are totally new or the first time to use Gitcoin?

Not to be confuse, that metric would be for mini-CLR

owocki commented 4 years ago

I think we need to focus on account age, sybill attacks are generally done by fresh accounts,

This is true right now, but only for unsophisticated attackers. Will change over time I bet

I would opt for the fulfilled bounty model object playing a key role on this one.

I think this is an elegant step forward, but I worry about the user onboarding costs. Its very easy to send/receive a tip. Bounties are 10x harder to do.

Could you perhaps capture user's browser fingerprinting on that dashboard

UserAgent maybe but its easily foolable.

One suggestion that came out of the recent Gitccoin livestream was using SMS numbers as proof of unqiue human.

Btw have you guys read this? Very good canonical source of truth on collusion /sybil attacks https://vitalik.ca/general/2019/04/03/collusion.html

L-KH commented 4 years ago

I think we need to focus on account age, sybill attacks are generally done by fresh accounts,

let try to think like an attacker. I will create right now many accounts for example 10 accounts. and wait like 1month and then use them to attack in future CLR. so I think further age, we have to check the address of new accounts and see the first transaction. attacker for sure he will need some amount in a new account to send tips(attack). so if we find collusion in a new account and the old one in the first transaction of the new one. then we have to make those accounts on the scope.

One suggestion that came out of the recent Gitcoin Livestream was using SMS numbers as proof of unique human.

good one. even there is a possibility to create many numbers (there is some services on telegram like this, but not free). so perfect solution is to fusion (age, first transaction, SMS)

owocki commented 4 years ago

yeah i wondered about that too. asking on twitter here https://twitter.com/owocki/status/1254756810092802049

On Mon, Apr 27, 2020 at 6:55 AM Lahcen-KH notifications@github.com wrote:

I think we need to focus on account age, sybill attacks are generally done by fresh accounts,

let try to think like an attacker. I will create right now many accounts for example 10 accounts. and wait like 1month and then use them to attack in future CLR. so I think further age, we have to check the address of new accounts and see the first transaction. attacker for sure he will need some amount in a new account to send tips(attack). so if we find collusion in a new account and the old one in the first transaction of the new one. then we have to make those accounts on the scope.

One suggestion that came out of the recent Gitcoin Livestream was using SMS numbers as proof of unique human.

good one. even there is a possibility to create many numbers (there is some services on telegram like this, but not free). so perfect solution is to fusion (age, first transaction, SMS)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gitcoinco/web/issues/6492#issuecomment-619967680, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5PCOSWGGRYLV7GKLLF6DROV6DZANCNFSM4MOMS2TA .

--

@owocki http://www.twitter.com/owocki

gitcoin is live and has generated over $4.0mm for Open Source Software - see our results https://gitcoin.co/results

molecula451 commented 4 years ago

Owocki there are some flaws on the SMS verification. but one way to avoid. (I've seen in other apps) some they match the phone number code, with the country code and the IP address data you are perfectly viewing this data on all users.

There are some reasons:

Most virtual phones apps are US Based. Yes, there are some API that detects whether it is a virtual one or not.

owocki commented 4 years ago

what APIs are you using to do that? That'd be useful

On Mon, Apr 27, 2020 at 7:34 AM Paul notifications@github.com wrote:

Owocki there are some flaws on the SMS verification. but one way to avoid. (I've seen in other apps) some they match the phone number code, with the country code and the IP address data you are perfectly viewing this data on all users.

There are some reasons:

Most virtual phones apps are US Based. Yes, there are some API that detects whether it is a virtual one or not.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gitcoinco/web/issues/6492#issuecomment-619989248, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5PCKURQBZUK3EDX26J2TROWCW3ANCNFSM4MOMS2TA .

--

@owocki http://www.twitter.com/owocki

gitcoin is live and has generated over $4.0mm for Open Source Software - see our results https://gitcoin.co/results

molecula451 commented 4 years ago

I think we need to focus on account age, sybill attacks are generally done by fresh accounts,

This is true right now, but only for unsophisticated attackers. Will change over time I bet

I would opt for the fulfilled bounty model object playing a key role on this one.

I think this is an elegant step forward, but I worry about the user onboarding costs. Its very easy to send/receive a tip. Bounties are 10x harder to do.

Could you perhaps capture user's browser fingerprinting on that dashboard

UserAgent maybe but its easily foolable.

One suggestion that came out of the recent Gitccoin livestream was using SMS numbers as proof of unqiue human.

Btw have you guys read this? Very good canonical source of truth on collusion /sybil attacks https://vitalik.ca/general/2019/04/03/collusion.html

I have seen "old" github accounts getting into Gitcoin lately. Although. Github is exposing their reputation and old age. But that's not necessary means they want to contribute to the whole Community or stay in Gitcoin. I have seen a lot of accounts getting into Gitcoin and they claim a Kudos and they don't come anymore.

Do these users really need to get into the CLR matching at first sight?

frankchen07 commented 4 years ago

I think we're highlighting here that this is a tough problem that might not have a perfect solution. While there are exceptions to every solution, I think keeping an eye on making sure there's some medium-level of activation energy that is required to prove uniqueness is key.

Github account age is definitely a crude way of doing this. SMS slightly better, but still, it can be game-able. Given enough time and resources, anything is. What I'm learning is that it's basically a spectrum, from nothing, to Github accounts, to SMS, to full-on "show me your face & government ID and give me a blood sample" type of verification.

We have to land on the spectrum somewhere, and we'll gradually move towards more and more secure and "identified", but I'll say let's not make perfect be the enemy of good (and getting better).

owocki commented 4 years ago

Thanks for everyones help on this. Just created a BUILD ticket and added a few thoughts from this thread to the ticket scope. Did I get it mostly right? Any scope change proposals for the https://github.com/gitcoinco/web/issues/6548 build ticket?

gitcoinbot commented 4 years ago

⚡️ A tip worth 0.05000 ETH (10.54 USD @ $210.83/ETH) has been granted to @molecula451 for this issue from @owocki. ⚡️

Nice work @molecula451! Your tip has automatically been deposited in the ETH address we have on file.

gitcoinbot commented 4 years ago

⚡️ A tip worth 0.05000 ETH (10.54 USD @ $210.83/ETH) has been granted to @oussema for this issue from @owocki. ⚡️

Nice work @oussema! Your tip has automatically been deposited in the ETH address we have on file.

gitcoinbot commented 4 years ago

⚡️ A tip worth 0.05000 ETH (10.54 USD @ $210.83/ETH) has been granted to @l-kh for this issue from @owocki. ⚡️

Nice work @l-kh! Your tip has automatically been deposited in the ETH address we have on file.