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

> Perhaps Henri can explain what he means by Harmful here.

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.)
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. (Notably, Chrome has benefited from being able to appear as Safari, Safari has benefited from being able to appear as a Gecko-based browser, and Gecko-based browsers have benefited from being able to appear as pre-Gecko Netscape for sniffing purposes. In that sense, the lesser structure `User-Agent` has been a feature rather than a bug.)
3. I don't see the argument that something is already available as a reason to expose it in another way. That adds more bytes on the wire / more API surface / more complexity to the Web Platform, in which case the harm is the data waste or increased platform complexity and not the identifying bits exposed.

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. (As noted above, I view structuredness less of a problem that needs solving.)

Having a lot of different headers makes it easier to `Vary` more granularly (assuming a distant future where you could `Vary` exclusively on User Agent Client Hints and not on `User-Agent` at all), effectively leaking a CDN-side concern (since ISP-side caches are no longer a thing) to browsers, but the spec and README only hint at that parenthetically instead of framing it as the big motivation.

Having different levels of fiction exposed via the pre-existing header / APIs doesn't seem conceptually different form returning fictitious values in User Agent Client Hints. 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.

-- 
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-880496675