Re: [w3ctag/design-reviews] User-Agent Client Hints & UA Reduction (#640)

Thanks for the reply @hsivonen.

> There are mainly three kinds of harmful here:

> 1. Exposing detail that's not currently exposed or that would be feasible to stop exposing. (The argument that the UA can choose to return bogus values that don't really expose more detail collapses this case to the third case below.)

For Chromium-based browsers, no additional information about the browser, OS, or device is exposed. For Firefox, I think the only thing that isn't regularly exposed, or possible to infer already is Android device model (please correct me if I'm wrong!).

I'll note that it is possible to expose the device model in the Firefox for Android UA string today, but as far as I'm aware the stock browser does not ship with that enabled using the `general.useragent.use_device` pref (I wouldn't know if there are partner distributions or Fenix forks that do ship with that on): https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsHttpHandler.cpp#988-1004

> 2. Added structure making it harder to use lesser structure to have things be multiple ways at the same time for compat. Notably, Sec-CH-UA-Full-Version doesn't allow for a real Gecko version and a fake Chrome version such that there'd be a good chance that sites that haven't considered Gecko would end up seeing the fake Chrome version. 

This sounds like https://github.com/WICG/ua-client-hints/issues/196, and I agree we should fix this (this was raised by Microsoft as a possible compat foot-gun). I think the right thing to do here is deprecate `Sec-CH-UA-Full-Version` and adding something like `Sec-CH-UA-Full-Version-List` that allows for GREASEing on versions. I'm hoping we can make progress on that this quarter.

> 3. I don't see the argument that something is already available as a reason to expose it in another way.

I see your point, but one of the things we're trying to achieve - beyond fixing passive fingerprinting via the UA string - is to create a more useful, ergonomic API for developers. UA string parsing is non-trivial and libraries are prone to errors (especially when new browsers are released - I [worked for many years](https://miketaylr.github.io/arewedetectableyet/) trying to get sites to update their site bugs caused by somehow incorrectly identifying the new Firefox OS, Firefox for iOS, Firefox Reality, etc. User-Agent strings). In my opinion its desirable to create a new, cleaner API to expose this information, even if it's duplicative.

> I'd like to see an explanation of why having policy/setting/request-budget-API modify the HTTP User-Agent value and the values returned by the existing navigator APIs wouldn't solve the entropy problem that User Agent Client Hints aims to solve. 

and

> AFAICT, if returning fictitious values in User Agent Client Hints is already proposed at this point in time, we might as well not add new headers to requests and not add API surface and put the fiction, perhaps conditionally, in User-Agent and the existing navigator APIs that we already have.

I don't know how realistically solve for passive fingerprinting in a conditional fashion at the HTTP layer. I suppose you could use a list of trackers (something like DuckDuckGo's or Disconnect's tracker lists) and modify behavior on that existing list. But sites can just create new domains and you have no idea if they're creating or sharing server-side fingerprints - how would the list ever be updated to keep up?

> (As noted above, I view structuredness less of a problem that needs solving.)

We'll have to disagree on this point. So many Opera Mobile and Firefox Mobile (Firefox OS and Firefox for Android) compat issues in the early days were caused by mis-parsing the UA string, or assuming all mobile browsers would have similar looking UA strings to the popular ones for a given region. I think providing a better, more predictable API is worth solving for, both for users and developers.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/640#issuecomment-881682853