On Wed, May 8, 2024 at 3:33 PM Neil Madden <neil.e.mad...@gmail.com> wrote:
> > 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 <https://fedidcg.github.io/FedCM/#timing-attacks> 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: > https://developers.google.com/privacy-sandbox/protections/ip-protection > > and Safari: > https://support.apple.com/en-gb/guide/iphone/iph499d287c2/17.0/ios/17.0 > > > 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. > Yeah, that's the kind of analysis that we are starting to do too: does it become asymptotically harder to correlate users when n simultaneous users grow? I think I'm a lot more concerned about the n > 1B users scenario than I am with the n=1 scenario, so if we stopped the former but not the latter, it would be forward progress. > > 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? > Yep, those are interesting approaches (caching comes to mind too). > > I’m sure I can come up with other methods. > I'd love to work with you - and others here - to harden the system. I'm really grateful for the thought you put into this analysis so far, and exactly the reason why we figured this would be a great community to connect to: thanks! > > 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: > > > https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity > > > — Neil >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
