Prevent/Reduce/Detect fake (already know) connections

Connections (with already know set as level) is most important thing most anti-sybil algorithms will rely on to verify users.

Here we discuss how we can design systems to prevent or reduce fake (already know) connections, or define algorithms that detect them or give accuracy weights to (already know) connections.

There can be different types of fake (already know) connections:

  • connections between multiple accounts created and managed by a single attacker
  • connections between multiple accounts created by an attacker to different group of people that already know him
  • connections between multiple accounts created by an attacker to different honest accounts
  • connections between multiple accounts created by an attacker to multiple accounts created by another attacker to help each other getting verified

I don’t think you can reduce this. We can assume that attackers will mark the connections between their sybils as “already know” or whatever other confidence level benefits them the most.

Another very important consideration is to make sure normal users use already know correctly. We can encourage correct usage by how we design verification levels as I commented here.

1 Like

Current many to many group connection codes that are being shared by the call manager can potentially be one of the sources of fake already know connections.

As @monomesa suggested here one solution can be implementing a many to many group connection qr codes for just met level to be used by call managers, so users do not be asked about confidence level and all level be automatically be set to just met.

Another solution can be implementing a one to many QR connection which call managers share and connect to all attendees to themselves using that code, instead of asking everyone in the party to connect to everyone else. I think asking everyone to connect to others in the party with just met level is not helpful and make things hard for users that are trying to connect to the manager to get verified.

One of the most obvious ways to reduce fake connections is penalizing flagged users. So honest users should be educated to flag any stranger that send connection requests to them as spammer.

One of the concerns that should be solved is false flags. The question is how we can ensure that someone who is flagged really sent spam connection request? What if someone share Trump BrightID somewhere and ask everyone flagging him.

As discussed before, we can add a signature to the connection request, to be used as the proof that the qr/link creator accepted that he created and requested the connection.

In this way the user that want to flag someone as spammer can include that sig in the request to prove he was requested to make the connection and anyone is responsible to not request connection and share connection link with someone that they do not know.

What about if spammers ask others to send them the link? If attacked users be educated, they will reject, but is there a way to report such spammers? One possible approach is to accept the chance of being reported and share the link with them and wait for them to first connect to you and then report them as spammer based on the fact that they connected first.

If we want to follow this approach for reporting spammers who request the link instead of sharing that, it’s better to update the client to only show the profile info of the other side to the link generator after who shared the link with submit the connection. In this way spammers who are phishing connections and do not generate the link themselves, will be forced to first connect to the targets to be able to have their connection, but those attacked users can report them instead of making connection to them. Also the client should only show just met if the other side selected just met as confidence level to not allow attackers avoid getting reported by selecting just met and wait for the other side to select already know.

Another challenge for applying strict rules on sharing connection links is the group connection links. What if spammers share group connection links? Do we want to allow anyone join a group connection flag anyone that generated the link and also others joined before them? What about seeds sharing those links to strangers not to spam them but they can flag the seeds?

One of the solutions can be limiting the group connection links to just met so users do not see any already know option in the confirmation screen. If someone want to update level to already know should go through the connections list manually. In this way we can disable reporting on such connection requests, but such requests can not help attackers in phishing already know connections.

To sum up the discussion:

  • You can report someone as spammer if:
    • they shared one-to-one connection code with you
    • they connected to you as already know
  • Group connection codes can only be used to make just met connections

Penalizing users because of actions that damage the network like spamming the network and getting flagged because of that is very important.

One approach to penalize bad behavior seems to be making verification more difficult for users with such behavior as @castall suggested here.

We can also apply penalties to users who are connected to penalized users to enforce more social care in the network.

There was a long discussion before about implementation of white hat attacking game into BrightID to ensure users will be more careful in making (already know) connections. Is there any document about that? @castall @UBIpromoter

This is an immature idea and I’m not sure if it can be used in anyway, but one of the things that is different between real and fake (already know) connections is that real (already know) connections can be repeated. It is much simpler to find and reconnect someone that I already know, compared to someone that I do not already know. If we could ask users automatically to ask random already know connections to reconnect to them or send some sort of operation that show they are in contact with each other, we could consider not reconnecting or sending that operation just like being reported as an evidence of making fake (already know) connections and penalizing users based on that.

There are challenges about this immature idea:

  • It may be hard experience for users to find and reconnect to users even if they really and already know each other.
  • There are technical complicacy in server side and client side implementation of such a thing for a decentralized network of BrightID.
  • Users may bypass this by sharing contact info when making fake connections (if both sides are attacking?)

One important question is that how we can prevent:

  • connections between multiple accounts created by an attacker to different group of people that already know him

We expect users who know their friends/families have multiple accounts report them as duplicate. But how someone can find out their friend/family have multiple accounts?

If users had access to the connections list of anyone they are connected to (as already know), and it becomes the BrightID rule to use your real name and making connection with someone act as confirming the name, clients could easily detect and warn users about different BrightIDs with similar names

I’m not sure how detecting and reporting duplicates can be done without enabling users to see the connections list of their friends/families.

1 Like

@mahdi what does this mean?

@mahdi Reconnecting could be an interesting signal to use in analysis.

It definitely makes it easier and we talked in the past about the possibility of allowing someone to download the connections of someone they connect to. “Already known” could be a minimum confidence level to allow friend-of-friend connection sharing.

I mean when A share a link with B, and B scan the code, A should not see the B’s profile to connect to it, before B connect to A first. This enables A to report B based on the fact that B submitted connection to A.

1 Like

I can imagine a group connection with several people that already know each other. It’s happened to me before.

Yes, but how can we avoid spammers from sending group connection links? We discussed how we can do that in one-to-one connection by including a proof that the link creator requested the connection. But what if spammers use account A to create the link and join the channel after that with account B and wait for phishing already known connection to account B?

One approach maybe allowing anyone joining a group connection to be reported. But I do not like such a feature and will try to never scan such a code that may result in being reported without doing any bad thing. When we do not have such codes, I can easily click on links spammers share with me and report them. But if there are some sort of links that clicking on them may result in being reported, I will participate in reporting and ignore spammer links instead of trying to report them.

I think the good thing with one-to-one codes is that link creator can be responsible about who the link is shared with and can be reported as spammer if the link is shared with someone that should not. And the bad thing with group connections is that many one can join without taking responsibility.

I don’t think a user is going to click on a link that joins them to a group connection, realize it was a mistake and then start connecting to people in this mistaken group connection and raise the confidence level from the default level of “just met” to “already know.”

Are you talking about someone who receives a group link and then decides to forward it to other people to fish for already known connections–or how else are you imagining that the creator of a group connection link can’t be held responsible for it?

No, If I want to use group links to send spam requests, I make create a link with a dummy account and join the channel with attacker account and send the link to hundreds of people and wait to fish already known connections.

If we want to enable users joining such a group connection report the attacker, we reproduce the problem we described as fake reports. For example someone can share Trump BrightID in a group channel and share it publicly and ask others to come and report that BrightID.

If there was no group link, we could simply ask all BrightID users that if they got spam connection request, scan/click, and then report. But with group connection links, clicking on spam link may result in getting reported, so honest users will prefer to not scan/click and simply leave those links. So they can not help reporting those spammers anymore and spammers can continue trying to find some careless users.

How do you do that?

Also, I don’t think attackers are going to get many “already know” connections by spamming out links, because users have to change the default of “just met” to “already know” and I don’t know why they would do that.

The ideal would be for someone to receive a link they weren’t expecting (i.e. spam), then report it without having to share their profile information with the attacker.

It’s not possible with official client but can be simply done having programming skills and using our open source protocol.

Why not if having already known level helps both sides.
We should not rely on being hard to switch the level to prevent fake already known connections. What can help us to reduce fake already known connection is warning users that they will be penalized by making already known connections to someone that they do not know, because they may got reported (or even getting penalized if those users they do not know get reported).

If there was no group connection, we could simply rely on every report to penalize the reported user, because we could accept only reports that include the proof that reported user initially requested the connection and shared the link (or reported user had already known connection with reporter before).

It can be simply achieved in one-to-one connections by uploading scanner profile to the channel after he selected to connect not instantly. We should reject uploading if the scanner selected to report the link creator. I’m working on that now under reporting branch on client.