BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Sabre//Sabre VObject 4.5.8//EN
CALSCALE:GREGORIAN
LAST-MODIFIED:20230923T163415Z
BEGIN:VTIMEZONE
TZID:Europe/Madrid
BEGIN:STANDARD
DTSTART:20221030T010000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
END:STANDARD
BEGIN:STANDARD
DTSTART:20231029T010000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20230326T010000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:fb2d135a-2f5c-44d5-9558-1f987788e8ba
DTSTAMP:20230923T163415Z
SUMMARY:Fighting fraud without fingerprinting
DTSTART;TZID=Europe/Madrid:20230913T171500
DTEND;TZID=Europe/Madrid:20230913T181500
DESCRIPTION:https://www.w3.org/events/meetings/fb2d135a-2f5c-44d5-9558-1f98
 7788e8ba/\n\nMany critical anti-fraud use cases depend on highly re-identi
 fiable client information to discourage scaled abuse and detect specific a
 ttacks. Scaled abuse includes problems like bulk account creation\, passwo
 rd guessing\, and spam\, and generally centers on one client misrepresenti
 ng themselves as many (i.e. [Sybil attack](https://en.wikipedia.org/wiki/S
 ybil_attack)). Although these anti-fraud use cases generally do not track 
 users\, the browser cannot distinguish these from information collected fo
 r 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 cros
 s-site user tracking.\n\n\n\n\n\n\n\nWe previously suggested a device atte
 station mechanism experiment (WEI) that tried to provide rate limiting and
  allow the platform to prove its authenticity without limiting browser mod
 ifications\, devtools\, extensions\, and similar. The feedback we received
  made it clear that we did not adequately anticipate the openness and inte
 roperability concerns of the web\, which we now share. As an alternative\,
  we would like to explore experimenting with a narrowed use case and discu
 ss 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-par
 ty identity or proof of hardware\, in a way that preserves privacy and all
 ows attesters to compete on the basis of their performance?\n\n\n\n\n\n\n\
 nSpecifically we want to ask:\n\n\n\n\n\n\n\n1. Is there value in downscop
 ing to “attestation of a scarce resource” (e.g. third-party identity\,
  proof of hardware\, etc) with some protection against scaled misrepresent
 ation / over-claiming?\n\n\n\n    1. Confirm: [Enforce rate limiting again
 st a scarce client resource](https://github.com/antifraudcg/use-cases/blob
 /main/USE-CASES.md#enforce-rate-limiting-against-a-scarce-client-resource)
  is a capability that currently relies on collection of re-identifiable in
 formation.\n\n\n\n    2. How scarce does this resource need to be? \n\n\n\
 n    3. What latency-tolerant use cases are relevant?\n\n\n\n    4. What o
 ther anti-fraud / defensibility requirements should we keep in mind?\n\n\n
 \n2. In order to preserve the openness of the web\, a diverse set of “so
 urces of scarcity” should be available to users. In order for the confid
 ence of all verdicts to not be compromised by a single source\, a quality 
 bar has to be upheld.\n\n\n\n    1. Where should the discussion about how 
 an issuer identifies suitable attesters take place?\n\n\n\n    2. Opinions
  on high barrier to entry and no feedback on observed quality vs. lower ba
 rrier to entry and feedback on observed quality\n\nAgenda\n\n**Chairs:**\n
 Philipp Pfeiffenberger\n\n**Description:**\nMany critical anti-fraud use c
 ases depend on highly re-identifiable client information to discourage sca
 led abuse and detect specific attacks. Scaled abuse includes problems like
  bulk account creation\, password guessing\, and spam\, and generally cent
 ers on one client misrepresenting themselves as many (i.e. [Sybil attack](
 https://en.wikipedia.org/wiki/Sybil_attack)). Although these anti-fraud us
 e cases generally do not track users\, the browser cannot distinguish thes
 e from information collected for the purpose of tracking. If we were to re
 duce fingerprinting by limiting access to entropy-rich information without
  solutions for anti-fraud\, we would encumber the people fighting fraud an
 d accidentally encourage access gating or degraded experiences for benign 
 users. We would like to explore whether some of these use cases can be sat
 isfied without the risk of cross-site user tracking.\n\n\n\n\n\n\n\nWe pre
 viously suggested a device attestation mechanism experiment (WEI) that tri
 ed to provide rate limiting and allow the platform to prove its authentici
 ty without limiting browser modifications\, devtools\, extensions\, and si
 milar. The feedback we received made it clear that we did not adequately a
 nticipate the openness and interoperability concerns of the web\, which we
  now share. As an alternative\, we would like to explore experimenting wit
 h 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 th
 eir performance?\n\n\n\n\n\n\n\nSpecifically we want to ask:\n\n\n\n\n\n\n
 \n1. Is there value in downscoping to “attestation of a scarce resource
 ” (e.g. third-party identity\, proof of hardware\, etc) with some protec
 tion against scaled misrepresentation / over-claiming?\n\n\n\n    1. Confi
 rm: [Enforce rate limiting against a scarce client resource](https://githu
 b.com/antifraudcg/use-cases/blob/main/USE-CASES.md#enforce-rate-limiting-a
 gainst-a-scarce-client-resource) is a capability that currently relies on 
 collection of re-identifiable information.\n\n\n\n    2. How scarce does t
 his resource need to be? \n\n\n\n    3. What latency-tolerant use cases ar
 e relevant?\n\n\n\n    4. What other anti-fraud / defensibility requiremen
 ts should we keep in mind?\n\n\n\n2. In order to preserve the openness of 
 the web\, a diverse set of “sources of scarcity” should be available t
 o users. In order for the confidence of all verdicts to not be compromised
  by a single source\, a quality bar has to be upheld.\n\n\n\n    1. Where 
 should the discussion about how an issuer identifies suitable attesters ta
 ke place?\n\n\n\n    2. Opinions on high barrier to entry and no feedback 
 on observed quality vs. lower barrier to entry and feedback on observed qu
 ality\n\n**Goal(s):**\n1. Confirmation that anti-fraud use cases should se
 ek alternatives to fingerprinting-like practices. 2. Explore whether an ex
 periment with a narrow focus would have anti-fraud value\, and help tackle
  those use cases. 3. Collect requirements for open access to attesters tha
 t also ensures effectiveness of attesters for relying parties.\n\n**Attend
 ance:**\nThis session is restricted to TPAC registrants.\n\n**Materials:**
 \n- [slides](https://docs.google.com/presentation/d/1kZNg8YMtYpVgDrAk215mn
 fkISyGpO9SdeMffIHv98mI/edit#slide=id.p)\n- [minutes](http://www.w3.org/202
 3/09/tpac-breakouts/62-minutes.pdf)\n- [live google doc minutes](https://d
 ocs.google.com/document/d/1Rr9pfGyJpQrNsTJ9VO183fbEgq9D7JwsoDlnnQgNXSE/edi
 t#heading=h.2cnghmlk7zlo)\n- [Session proposal on GitHub](https://github.c
 om/w3c/tpac2023-breakouts/issues/62)\n\n**Track(s):**\n- privacy
STATUS:CONFIRMED
CREATED:20230905T054053Z
LAST-MODIFIED:20230923T163415Z
SEQUENCE:2
ORGANIZER;CN=W3C Calendar;PARTSTAT=ACCEPTED;ROLE=NON-PARTICIPANT:mailto:nor
 eply@w3.org
LOCATION:Giralda III - Level -2
CATEGORIES:TPAC 2023,Breakout Sessions
END:VEVENT
END:VCALENDAR