Detect suspicious location behavior

[menegais1]

Hello! I'm from CAF, a Brazilian company founded in 2019 that aims to prevent identity fraud with a variety of products, such as digital onboarding, background checking and facial authentication.

Context and threat

In successful attacks to steal legitimate accounts in LATAM, we observed several relevant signals that could be used for detection, however, one of the most relevant signals is the geolocation of the user/device.

One of the most striking examples of recent years in Brazil is the physical theft of the device on streets of large cities like São Paulo or Rio de Janeiro.

You can usually detect these events because:
A cell phone that has been stolen will likely be used in a different location than it was used in previous legitimate transactions;
Sometimes, transactions also take place in areas considered risky by the company (anti-fraud company or company that owns the business);

The same behavior can also be observed in cases of digital ATO, where criminals somehow manage to bypass the security controls implemented by the companies.

Proposal

Our proposal is similar to the On-device Score Calculation proposal #16, where the logic (Worklet) is pre-existing in a browser and the parameters are inserted remotely through a configuration API (called at the moment page/component load, for example).

Combined with this API, there will also be another API capable of querying whether the location behavior pattern of that device (respecting the parameters configured initially), matches the desired one.

For example:

1. User visits a page of the money transfer feature (for example, using Brazil's instant transfer mechanism, known as PIX) - at this point a Worklet is configured with parameters from the anti-fraud company's backend - one of these parameters is the data of a polygon considered as a risk area by that company;
2. At the time of the transaction, the browser, using logic/real and historical data from that user, concludes whether that device was present (geolocation) in that region initially configured or not in the last 24 hours (for example);
3. The result of this On-device calculation must also be sent along with the request to the backend that will use it as a relevant signal for the decision to authorize or not this transfer transaction.

The decision is entirely made On-device and can be configured in advance by the company interested in that signal.

Seeking to protect the integrity of this device signal, it is also important to create some mechanism to prevent unwanted and malicious tampering with the device (anti-tampering).

Relevant signals

• Current location of user/device
• Location history
• Areas considered as high risk by that company
• Time of day
• Day of the week or month

Privacy implications and safeguards

To avoid device position triangulation: add the need to provide a list of areas with minimum size.

---

This post was made together with @ricardosw

[bmayd]

I think this is an interesting proposal, but that we'd want to put in place protections to guard against abuse, perhaps among them something like the carve-outs suggested in the Anti-Fraud Safe-list proposal.

I also think we should always assume our tools will be misappropriated and be very careful about the information provided by the questions we allow an API to answer, with a strong bias toward revealing as little information as possible. Considering your example from that perspective:

You suggest providing the API with data for a polygon considered as a risk area, having the device determine if it was present in the risk area or not within a given period and then sending the signal to a back-end for decisioning.

You're interest is in ascertaining whether or not you should trust a device interaction based on whether it is occurring in a location that is suspect, but making that determination requires potentially revealing specific information about the user's location at a given point in time. Although the intended use is to provide a location suggestive of fraud, there is nothing in the technology that would prevent someone from providing a time and location of a political protest, a place of worship, a low income area, etc. and using that information for purposes other than fraud detection.

I suggest as an alternative, an API which can be asked the equivalent of "Is this event happening at a time and location that makes sense given the user's history?" In your example the answer would be "no" if the device was being accessed in a location the user didn't frequent, which may indicate something abnormal while revealing very little about the device owner.

[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.

[npdoty]

I think on-device scoring is difficult, for the reasons generally discussed elsewhere (the attacker can change it, and there are privacy and user control issues with trying to prevent users from controlling their devices).

But attestation (perhaps through privacy pass or some similar protocol) of a normality/abnormality of geolocation could be a promising area to brainstorm.

[dvorak42]

From the CG meeting, there was more discussion about having a mechanism to determine whether the device is still at a "normal" location rather than being able to ask about specific locations, to limit the privacy impact of the API. There was some concern for larger-scale movement with how you'd deal with the user legitimately traveling or moving between locations. Trying to nail down some of the privacy costs of this API and how to mitigate them might be a good next step.