[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

Wed, 08 May 2024 15:33:58 -0700


On 8 May 2024, at 21:39, Sam Goto <g...@google.com> wrote:

On Wed, May 8, 2024 at 1:26 PM Neil Madden <neil.e.mad...@gmail.com> wrote:
Looking at these slides again, and at the spec, does this even work to defeat tracking? The browser makes two requests to the IdP prior to getting consent from the user:

1. To lookup the accounts of the user (identifying the user)
2. To lookup the metadata of the client (identifying the RP). 

Isn’t it rather trivial for a tracker posing as an IDP to correlate these two requests? The privacy considerations talk about IP addresses and timing ways to correlate

The timing attack is the one that we think we are most vulnerable to at this layer, but we know how to (a) detect it and (b) address it (e.g. by introducing UX friction).

IP addresses are also a problem, but we think it will be best addressed at a different layer: 

For example, in Chrome:
 
and Safari:

In both cases the TLS connection is end to end, so I guess all user agents need to setup and teardown two independent connections? And make sure the IdP/tracker doesn’t encode tracking information into session resumption tickets?

As a user of the Safari method, I also know that I have to turn it off surprisingly frequently. (And some people deliberately turn it off). 

 
, but there are plenty of others.

Outside of the timing attack and IP masking, can you expand on what else an attacker could use to track the users?

Does this assume that the tracker is trying to track a lot of people at once? Obviously, in the limit, if only a single person pings the endpoints at a certain time then it is obvious that those requests are related. How many near-simultaneous pings of a tracker do you need to ensure a sufficient level of non-correlation? For n simultaneous users the tracker needs to smuggle through log2(n) bits of entropy to be able to precisely correlate the two requests. 

Another method I can think of is that the tracker responds to the request for the /config endpoint with randomised /accounts and /client-metadata endpoints, such that it can correlate the two calls to those endpoints. Maybe browsers should fetch it multiple times from different IP addresses, geographically distributed?

I’m sure I can come up with other methods. 

Browsers are working towards removing every bit of entropy that can be used for fingerprinting, so I'm curious if anything occurred to you that isn't being actively worked on. For example:


— Neil
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Reply via email to