Fighting fraud without fingerprinting

• Past
• Confirmed
• Breakout Sessions

Many critical anti-fraud use cases depend on highly re-identifiable client information to discourage scaled abuse and detect specific attacks. Scaled abuse includes problems like bulk account creation, password guessing, and spam, and generally centers on one client misrepresenting themselves as many (i.e. Sybil attack). Although these anti-fraud use cases generally do not track users, the browser cannot distinguish these from information collected for the purpose of tracking. If we were to reduce fingerprinting by limiting access to entropy-rich information without solutions for anti-fraud, we would encumber the people fighting fraud and accidentally encourage access gating or degraded experiences for benign users. We would like to explore whether some of these use cases can be satisfied without the risk of cross-site user tracking.

We previously suggested a device attestation mechanism experiment (WEI) that tried to provide rate limiting and allow the platform to prove its authenticity without limiting browser modifications, devtools, extensions, and similar. The feedback we received made it clear that we did not adequately anticipate the openness and interoperability concerns of the web, which we now share. As an alternative, we would like to explore experimenting with a narrowed use case and discuss how we can address interoperability and access concerns in our design. Specifically, is there value in attesting that the request is associated with a single user by proof of a “scarce resource” such as a third-party identity or proof of hardware, in a way that preserves privacy and allows attesters to compete on the basis of their performance?

Specifically we want to ask:

1. Is there value in downscoping to “attestation of a scarce resource” (e.g. third-party identity, proof of hardware, etc) with some protection against scaled misrepresentation / over-claiming?

   1. Confirm: Enforce rate limiting against a scarce client resource is a capability that currently relies on collection of re-identifiable information.

   2. How scarce does this resource need to be?

   3. What latency-tolerant use cases are relevant?

   4. What other anti-fraud / defensibility requirements should we keep in mind?

2. In order to preserve the openness of the web, a diverse set of “sources of scarcity” should be available to users. In order for the confidence of all verdicts to not be compromised by a single source, a quality bar has to be upheld.

   1. Where should the discussion about how an issuer identifies suitable attesters take place?

   2. Opinions on high barrier to entry and no feedback on observed quality vs. lower barrier to entry and feedback on observed quality

Agenda

Chairs:
Philipp Pfeiffenberger

Description:
Many critical anti-fraud use cases depend on highly re-identifiable client information to discourage scaled abuse and detect specific attacks. Scaled abuse includes problems like bulk account creation, password guessing, and spam, and generally centers on one client misrepresenting themselves as many (i.e. Sybil attack). Although these anti-fraud use cases generally do not track users, the browser cannot distinguish these from information collected for the purpose of tracking. If we were to reduce fingerprinting by limiting access to entropy-rich information without solutions for anti-fraud, we would encumber the people fighting fraud and accidentally encourage access gating or degraded experiences for benign users. We would like to explore whether some of these use cases can be satisfied without the risk of cross-site user tracking.

We previously suggested a device attestation mechanism experiment (WEI) that tried to provide rate limiting and allow the platform to prove its authenticity without limiting browser modifications, devtools, extensions, and similar. The feedback we received made it clear that we did not adequately anticipate the openness and interoperability concerns of the web, which we now share. As an alternative, we would like to explore experimenting with a narrowed use case and discuss how we can address interoperability and access concerns in our design. Specifically, is there value in attesting that the request is associated with a single user by proof of a “scarce resource” such as a third-party identity or proof of hardware, in a way that preserves privacy and allows attesters to compete on the basis of their performance?

Specifically we want to ask:

1. Is there value in downscoping to “attestation of a scarce resource” (e.g. third-party identity, proof of hardware, etc) with some protection against scaled misrepresentation / over-claiming?

   1. Confirm: Enforce rate limiting against a scarce client resource is a capability that currently relies on collection of re-identifiable information.

   2. How scarce does this resource need to be?

   3. What latency-tolerant use cases are relevant?

   4. What other anti-fraud / defensibility requirements should we keep in mind?

2. In order to preserve the openness of the web, a diverse set of “sources of scarcity” should be available to users. In order for the confidence of all verdicts to not be compromised by a single source, a quality bar has to be upheld.

   1. Where should the discussion about how an issuer identifies suitable attesters take place?

   2. Opinions on high barrier to entry and no feedback on observed quality vs. lower barrier to entry and feedback on observed quality

Goal(s):

1. Confirmation that anti-fraud use cases should seek alternatives to fingerprinting-like practices. 2. Explore whether an experiment with a narrow focus would have anti-fraud value, and help tackle those use cases. 3. Collect requirements for open access to attesters that also ensures effectiveness of attesters for relying parties.

Attendance:
This session is restricted to TPAC registrants.

Materials:

• slides
• minutes
• live google doc minutes
• Session proposal on GitHub

Track(s):

• privacy

Minutes

 Read minutes

Export options

Personal Links

Please log in to export this event with all the information you have access to.

Public Links

The following links do not contain any sensitive information and can be shared publicly.

• Download as ics