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

> Is Google doing statistical analysis on the current UA strings?
> Are there patterns or features in this statistical set that could be explored?
> 
> My thoughts are along,
> 
> What are the UA string structure features extracted from the mass of the data (machine learning?) instead of the desired structure of the spec?

This seems like an interesting discussion to have elsewhere, perhaps in the UA-CH spec if you'd like to file an issue: https://github.com/WICG/ua-client-hints/issues/new, or maybe in the whatwg/compat repo: https://github.com/whatwg/compat/issues/new

> The optics of a browser vendors is there are thousands of websites using libraries that are locally deployed. These libraries have outdated strategies, bugs, and with logics such as:
> 
> * If `browser_x`, don't send this format (**even if the `browser_x` supports the format in the future**)
> * If `browser_version` > `nn` sends [this] else sends [that] (even when  `nn+1` changes the strategy)
> * no fallback, aka sites catering for most popular browsers.

Yeah, these patterns are bad, and sometimes browsers or the platform can force developers into these patterns, e.g. when there aren't proper feature detection mechanisms for a given feature, the UA string becomes the proxy for feature support. Or if a browser doesn't expose the buggy OS version number, there's not a lot of great options: browser fingerprinting? not supporting that browser? abusing non-standard interfaces to "feature-detect" a browser? Those options don't seem great.

(I recall a number of years back we couldn't remove the non-standard `window.controllers` from Firefox because sites were using it to "feature-detect" Gecko:

https://bugzilla.mozilla.org/show_bug.cgi?id=1010577#c5

It seems that's still the case: https://searchfox.org/mozilla-central/rev/9c91451cc2392d942a42493fc895f5aeeddde45d/dom/base/nsGlobalWindowInner.cpp#3035-3037)

> I agree with @miketaylr that bad parsing has always been an issue, but better parsing will not solve bad and unmaintained logic.

Yes, agree. It's impossible to fix these mistakes in the deployed web, short of writing a lot of site-specific workarounds (shout out to the Mozilla webcompat team for unbreaking sites for Firefox users).

> And we can be sure about two things:
>
> 1. that browser implementers will lie about the values provided in Client-Hints in the future because they have to for webcompat reasons
> 2. HTTP User Agent Strings will not go away because of legacy web properties.

re: 1 - Yes, probably. Developers don't always have the best incentives, budget, or even knowledge to make the web work for everyone, unfortunately. But that doesn't mean we shouldn't improve the passive fingerprinting surface that HTTP UA string provides. 

re: 2 - Of course. Our UA Reduction plan is designed to be pragmatic and backwards compatible. Nobody is proposing to stop sending the User-Agent header.

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