Skip to content

Commit

Permalink
Update tpac-2024.md
Browse files Browse the repository at this point in the history
  • Loading branch information
dvorak42 authored Oct 2, 2024
1 parent 0653b7f commit a9c5145
Showing 1 changed file with 256 additions and 0 deletions.
256 changes: 256 additions & 0 deletions tpac/tpac-2024.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,3 +26,259 @@
* [Shared Storage and Device Age](https://docs.google.com/presentation/d/1-VjSchD47FoLK1e_Iv4b6DGsUb70JE5No3VG_zLptbY/edit#slide=id.g3041befa8d0_6_325)

### Minutes

Steven: Welcomes everyone to the meeting, reviews the agenda and reminds everyone that the meeting mins will be public.

Browsers and AAF

First presentation Chrome

Presenter Eric PM in privacy sandbox

Eric: Anti fraud is foundational to privacy features. It is a key pillar to the work that we do. Without AF technology it’s possible to see sites doing things on their own that are a pain for the users

A lot more people have been using the AF signals and it’s important to consider AF when we look at privacy focused solutions, effectively it’s getting harder to tell what is fingerprinting for tracking and what is anti-fraud.

Impacted signals for fighting fraud

PArtitioned Cookies and local storage

Reduced API entropy

Proxied IP Addresses on incognito

Looking primarily for feedback on the IP protection as it has the most AF implications

Looking to hear from community about the use cases that need to be preserved and the capabilities



* Areas of focus:
* Private state tokens
* Expecting to see a jump in adoption as sites move away from depending on 3rd party cookies
* Client/Cookie Age
* Helping to ensure that the data that is stored is can expire
* Zero Knowledge Proofs
* Verification with low entropy
* Trusted Servers
* Using TEE for private aggregation is a promising area to explore

General discussion

Vinod: Is the plan to run IP proxying only in incognito mode

Eric: Plan is to use it in incognito mode

V: Original plan was to proxy all third party trackers is this going to be impacted

E: The original explainer suggested all chrome but now the plan is incognito

Aram: Will node mapping be made available?

David Schinazi: smallest size of node would be 500k people.

Nick Doty: Presumably the fraudster is going to hide their IP address so are they just going to use incognito. Presumably they already have access to tools to hide their ip

Eric: This is a free service openly available, while other paid proxy options might have a higher cost to potential fraudsters. We don’t yet know if fraudsters will attempt to use the proxy but we are preparing for or assuming that they might. We have plans to defend the proxy to limit abuse.

Nick Doty: It’s necessary beyond incognito

FIREFOX Presentation:

Ben Vandersloot:

3rd party cookies is not something that we should be relying on. Storage Access API (SAA) is a way to get access back if you need it. Requires a user interaction and a user prompt.

Once you get past cookies, AF looks a lot like fingerprinting with a few key differences. Tracking is trying to do identification and AF is trying to do reidentification. This difference is critical

Technical approaches to fingerprinting

Removing unique signals like fonts

Add noise

For users opting into strict and private mode we use disconnect.me list and block resources hosted on those sites. Even if something on those lists is being used as an anti fraud tool, then we still err on the side of blocking.

Privacy pass is a thing, it’s interesting but not a silver bullet and a few questions need to be considered

Who is the testers

Who is deploying

What the use case

(Check out the slide for additional context)



* RFC 9576 4.1 can tie your hands but is effective
* If you use a browser to help you communicate between two sites then you’ll be leaking bits
* Humanity test: Government ids have issues, ad impression value, false negatives are costly
* Political and complicated

RFC 9576 section 5 has a good overview

General discussion:

Per Bjorke: Where is the curve on the anti-abuse vs antifraud? Can you clarify what you mean by reidentification

Ben: I’ve seen you before, are you the same person as I saw before.

P: Our use case (ads) they don’t care who any individual is but that the behavior is normal

B: this is likely a third problem unless you consider reidentification of your bots

P: Human detection is not enough there are edge cases

Ben Kelly: Important to know where the knee in the curve (of the slide Fingerprinting Accuracy and Utility) is

BV: We could put a rough magnitude on the number of bits on where the curve elbows

B: Policy approaches don’t make an exemption to partitioning

Kaustubha: We’re hoping that a few solutions can be combined to help combat AF

BV: Thinking more from the context of payment processing

K: PST is the solution in the privacy pass slife. Many of the AF vendors don’t participate in privacy CG so having these conversations in this group is important

BV: A joint meeting could be helpful to have to get a sense on the acceptable constraints would be for the solution

Nick Doty: Users care about why a capability is being used. At lower level might be some appetite for exposing that you’re using a script for an anti fraud purpose. Could be a signal used by browsers

Aram: It’d be more useful if they attested that they aren’t doing fingerprinting

BV: We do have some manual validation

N: Speeding up the process for validation would be good and there should be consequesnecs for materially misleading users by misrepresenting your attestation about uses for anti fraud.

Eric: Middle of the venn diagram slide how is that handled

BV: If you’re in it we block

Eric: With only a few signals like IP+UA adtechs have a lot of uniquely identifying data which is very useful for tracking, are we sure the curve is like this?

BV: IP, UA both have a good number of bits already and we should start going after the low hanging fruit. The curve shape actually takes into account these high entropy data points, so utility might drop significantly (as the shape shows).

SAFARI PRESENTATION

Matthew Finkle: Privacy pass is not a silver bullet. There are open questions to consider particularly how it scales. Abuse is a problem that we want to help address. There are a lot of use cases for a lot of the signals that browsers provide. As safari removes the signals, we want to have conversations on how to engage on what signals are necessary that respect user privacy.

Recently added privacy pass tokens in 3rd party context such as capta vendors. Looking for feedback to see if this is helpful.



* Safari is moving to private browsing 2.0 was announced
* Link tracking protection (link decoration)
* Third party script if you try to access url, you won’t have access to link decoration
* Some small edge cases with breakage
* Blocking network lods of known trackers
* Anit fingerpringing protection removing signals
* Canvas, screenside etc.
* Extensions are not enabled by default
* Capped lifetime of cookies
* Partitioned sessionStorage
* Partitioned blob URLS

Erik Anderson: The token is pretty similar to an earlier Google proposal

Matt: It’s a tool to help solve the problem. Make sure that lack of access to token doesn’t necessarily mean they aren’t human

E: Any documentation

M: An [explainer](https://github.com/WebKit/explainers/tree/main/ThirdPartyPrivateTokens) but nothing developer focused

Per Bjorke:Privacy pass not bing a silver bullet, what other ways are you looking to add more capabilities

Matt: constantly looking for new solutions. Looking to work with others to find them

P: Making a viable solution requires the issuing of tokens. How to we encourage the ecosystem to adopt the issuing of tokens

M: Most of the adoption we've seen is captcha providers. One issue and one consumer.

P: How to we make this useful or is it tied to the same entity as this will limit the utility.

Scott Hendrickson: Signal from privacy pass isn’t enough to signal to prevent fraud. Capthca might be an exception. We need to be creative and open to new ideas

Eric Trouton: How do you handle other use cases or exemptions for AF. In our experience you end up with breakage,

Matt: we don’t but want to hear more

Eric (from Apple): A single bit isn’t sufficient but at the end of the day, we get to a low number of possible states. Who is responsible for looking at the information that gets you to the limited number of states.

Zainab: Fingerprint.com is a tool that’s indicated that there’s still room for advancement

E: Nice to get some outside confirmation but not a solo adventure

Nick Dotty: One of the limitations mentioned is list of trackers. Would you be interested in more sources of data

Matt: lists are initial defense we would be interested in augmenting lists with more information

#END BROWSER PRESENTATIONS


## Shared Storage and Device Age

Presenter: Manuel Caballero

[Slides](https://docs.google.com/presentation/d/1-VjSchD47FoLK1e_Iv4b6DGsUb70JE5No3VG_zLptbY/edit?usp=sharing)

Shared Storage API similar to 3rd party cookies but highly limited by retrieval. Can’t see the stored values but you can’t see the values directly.

Using SelectURL (8 buckets) we are using the buckets to indicate time. First goes in 1 then 2 etc.

Device age is important because most legitimate publishes have balanced distribution between the site buckets

Used shared storage as a way of trying to determine the device age without compromising the privacy of the user.

50% of traffic for legit websites are from devices that have been around for at least 6 months

70% of traffic for illegitimate sites are brand new. Probably because they clear cookies and then all go to the same site. With very small amount <20% older than a month



* Challenges and limitations:
* Restricted to enrolled domain
* Registration for each site is overhead
* Attestation file might be a good solution going forward to move away from domain
* Multiple round trips
* It’s slower than all the other signals
* Lots of processing
* Iframe
* Worklet
* Etc.
* But it works
* Plain-text storage can be tampered with
* Fraudsters will find out and change data
* Considerations and suggestions
* Improve performance
* Allow to be loaded through tech of one pixel image
* Expand functionality
* By increasing the size of array allowed by SelectURL from 8 to 16
* Strengthen protection
* Encryption
* Make it more expensive for fraudsters to hack

Statements/question:

Theo: Apple said that we need one bit only and this is an example of more bits needed

Eric: Question for Apple and Mozilla, if you suggest fingerprinting is not acceptable even for anti-fraud, do you feel that there's a room for developing web apis for use cases like this? If not, what alternatives should we be thinking of to fight fraud on the web?

Raj: Comment you made about mfa websites?

Manuel: Not looking at MFA specifically, we are trying to classify the ones where we know for a fact that are being visited by a high number of new devices

Fabian: What happens when the browser privacy budget is exhausted ? Are the measurements accurate ?

Manuel: We didn’t find any significant differences in real scenarios.

Nina: You were concerned about bots and automation. What’s stopping someone from making a browser that can fool it

Manuel: Totally right, if you change browsers we can’t stop you but it’s hard to do at scale.

**IP Address Usage in Payments**

3DS Secure: Merchant opens in sandboxed iframe, this gets considered as a 3rd Party. IP address is part of whether the user should be challenged.

GeoIP is a horrible hack, but there’s no better information currently.

0 comments on commit a9c5145

Please sign in to comment.