Device mesh (Androids/Chromes) to share suspicious behavior

[kazuoteramoto]

(Disclaimer: this issue is intended to be a general discussion and is not a specific implementation proposal yet. It’s more an open conversation around the theme and approach then a defined proposal)

Identity fraud is a billion dollar problem in Brazil, generating compliance and regulatory rules that stop business operations from easily scaling up while maintaining security and User Experience. idwall's solutions use machine learning and other cutting edge solutions to provide our clients with answers to those problems in the best possible way.

Context and threat

This threat is relevant to the Account Creation Abuse and Account Take Over (ATO) use-cases, a main one for any institutions concerned with fraud detection and containment in LATAM.

Compromised devices are sophisticated attack vectors and can be used by well organized criminal groups as a weapon against legitimate businesses and users. Likewise, attack automation enables scale for an engaged malicious actor, pushing the need to prioritize its detection and containment for a better user experience.

Proposal

Create a protocol to allow information exchange between devices (the mesh) preserving user privacy and, at the same time, identifying suspicious behavior in a distributed and resilient way.

The proposal is to use the consensus between devices on genuine and suspect characteristics without transferring sensitive information associated with these decisions. The mesh network would only make available the device's behavior comparison result for a certain period of time, which could be used to determine the trust in the device current behavior.

A device should be able to query from a safe and reliable source if another device has performed (within a defined period of time) some malicious action similar to the one it is going to perform, so it could make the decision not to perform that same action, autonomously.

A malicious action can also be identified through anomaly detection when compared to behaviors considered genuine.

This protocol can provide a consensus mechanism between devices (based on Yes/No questions - like Oracles - reducing the risk of leaking sensitive information), in order to create this “decentralized shared knowledge base” of actions that are being implemented and executed on specific domains.

Entities such as Google and others could act as mediators between devices ensuring, through encryption and signatures (PKI), that the devices are able to create a network of trust with each other.

Relevant signals

The signals will depend on the protocol to be created, however, it is possible to say that several signals that may indicate the compromise of a device can be used for this, such as "If a device made many requests in the same domain in the last 60 minutes”.

Privacy implications and safeguards

It is necessary to assume and mitigate that other mesh devices are unreliable and may actively seek to compromise the integrity of this feature.

[kazuoteramoto]

+@nicolasfkm

+@GuiMiranda

[dvorak42]

We'll be briefly (3-5 minutes) going through open proposals at the Anti-Fraud CG meeting this week. If you have a short 2-4 sentence summary/slide you'd like the chairs to use when representing the proposal, please attach it to this issue otherwise the chairs will give a brief overview based on the initial post.

[kazuoteramoto]

We'll be briefly (3-5 minutes) going through open proposals at the Anti-Fraud CG meeting this week. If you have a short 2-4 sentence summary/slide you'd like the chairs to use when representing the proposal, please attach it to this issue otherwise the chairs will give a brief overview based on the initial post.

We can prepare a slide to help with the understanding of the proposal! To confirm, the next meeting is 2022-10-28 correct?

[dvorak42]

Yup, this Friday.

[kazuoteramoto]

In text form, this sentence is a good summary:

Create a protocol to allow information exchange between devices (the mesh) preserving user privacy and, at the same time, identifying suspicious behavior in a distributed and resilient way.

We prepared a slide (pdf or Google Slides) with a visual representation of the proposal.

[npdoty]

It sounds very complex to design a privacy-preserving protocol to communicate between many devices that all know about one another, so I think some implementation experience would be useful prior to spending a lot of W3C community time on design.

[AramZS]

Hi, judging by the idwall sponsor I assume that the signals from the devices would be predicated on particular user identification being mapped against or inside some of the devices in the style of official document OCR as the user verification translated into the true/false signal?

[dvorak42]

From the CG meeting, there was some discussion about nailing down specific signals that would be used in the device mesh to try to focus the discussion/proposal on a more concrete variant of this. There was also a question about the potential complexity depending on what signals were being propagated through the system and if there were implementations or similar systems to point to to see the complexity of the problem. Another topic that came up was whether there was a way for sites that relied on the device mesh signal to report feedback if it turns out the user was fraudulent or the signal they received via this scheme ended up being false.

[kazuoteramoto]

It sounds very complex to design a privacy-preserving protocol to communicate between many devices that all know about one another, so I think some implementation experience would be useful prior to spending a lot of W3C community time on design.

We also believe that implementing this proposal is not trivial, is more a project than an isolated feature. The main goal of us bringing this to a larger forum is to have a better understanding of what is possible now and what should be developed to reach the goal of implementing this type of protocol. This type of protocol could also be used for other purposes than just fraud prevention.

Hi, judging by the idwall sponsor I assume that the signals from the devices would be predicated on particular user identification being mapped against or inside some of the devices in the style of official document OCR as the user verification translated into the true/false signal?

The sponsorship from idwall should not be taken as binding that our products or technologies must be part of the proposal. User identification from “real life identification” like official documents is one form of improving the capability of the mesh, but is not, and should not, be the only means of doing this. The main focus should be on the interaction between the nodes of the mesh.

From the CG meeting, there was some discussion about nailing down specific signals that would be used in the device mesh to try to focus the discussion/proposal on a more concrete variant of this. There was also a question about the potential complexity depending on what signals were being propagated through the system and if there were implementations or similar systems to point to to see the complexity of the problem. Another topic that came up was whether there was a way for sites that relied on the device mesh signal to report feedback if it turns out the user was fraudulent or the signal they received via this scheme ended up being false.

All very good questions! We can’t answer them fully right now, we have some ideas, but we believe the first work to be done on this proposal should be creating simpler cases to guide the overall design with input from the community to build a more robust protocol. As is right now this proposal is more a request for interest from the community that having something like this can greatly improve our ability to identify non trivial signals created from the interactions between the devices.