> Moving stuff around (from User-Agent to Sec-CH-UA-*) doesn't really solve much. That is, having to request this information before getting it doesn't help if sites routinely request all of it.<p>I think this is sort of ignoring the whole point of the proposal. By making sites <i>request</i> this information rather than simply always sending it like the User-Agent header currently does, browsers gain the ability to <i>deny</i> excessively intrusive requests when they occur.<p>That is to say, "sites routinely request all of it" is precisely the problem this proposal is intended to solve.<p>There are some good points in this post about things which can be improved with specific Sec-CH-UA headers, but the overall position seems to be based on a failed understanding of the purpose of client hints.
> "User Agents MUST return the empty string for model if mobileness is false. User Agents MUST return the empty string for model even if mobileness is true, except on platforms where the model is typically exposed." (quoted from <a href="https://wicg.github.io/ua-client-hints/#user-agent-model" rel="nofollow">https://wicg.github.io/ua-client-hints/#user-agent-model</a>)<p>Honestly now - who drafts and approves these specs? Not only does it make no sense whatsoever to encode such information this way - it also results in unimaginable amounts of bandwidth going to complete waste, on a planetary scale.<p>This is just plain incompetence. How did we let the technology powering the web devolve into this burning pile of nonsense?
I would rather have all this information (along with whatever is being inferred from them) be exposed through a Javascript API instead of having browsers indiscriminately flood global networks with potential PII.<p>Chrome came up with this? Figures. Stay evil, Google.
> UA Client Hints proposes that information derived from the User Agent header field could only be sent to servers that specifically request that information, specifically to reduce the number of parties that can passively fingerprint users using that information. We find that the addition of new information about the UA, OS, and device to be harmful as it increases the information provided to sites for fingerprinting, without a commensurate improvements in functionality or accountability to justify that. In addition to not including this information, we would prefer freezing the User Agent string and only providing limited information via the proposed NavigatorUAData interface JS APIs. This would also allow us to audit the callers. At this time, freezing the User Agent string without any client hints (which is not this proposal) seems worth prototyping. We look forward to learning from other vendors who implement the "GREASE-like UA Strings" proposal and its effects on site compatibility.<p><a href="https://mozilla.github.io/standards-positions/#ua-client-hints" rel="nofollow">https://mozilla.github.io/standards-positions/#ua-client-hin...</a>
I hope they avoid situations like the SameSite=None debacle[0] if they are going to freeze the User Agent header and not provide an alternative.<p>The assertion of Mozilla seems to be:<p>>At the time sites deploy a workaround, they can’t necessarily know what future browser version won’t have the need for the workaround. Can we guarantee only retrospective use? Do Web developers care enough about retrospective workarounds for evergreen browsers?<p>When there are significant numbers of users on devices like iPads that don't get updated any more, you can't rely on "evergreen browsers".<p>[0] - <a href="https://www.chromium.org/updates/same-site/incompatible-clients" rel="nofollow">https://www.chromium.org/updates/same-site/incompatible-clie...</a>
> I'm not sure why you used such an old Chrome version to test this.<p>That quote from the first comment on the issue is just a cherry on top.<p>Chrome 88 was released in December 2020. 7 months ago.