This is going to directly impact the selection script and permutation-based compilation of GWT 2.x. I've read several times that some people use a single user.agent value (can't remember if it's gecko1_8 or safari), do we have some guarantees that this will work reliably across "evergreen browsers"? Time to make gecko1_8 and safari permutations converge? (and let's declare ie8/ie9/ie10 as dead; in other words, time to remove UA-based permutations even before GWT3/J2Cl?)
On Tuesday, January 14, 2020 at 12:22:00 PM UTC+1, Yoav Weiss wrote: > > Contact emails > > [email protected] <javascript:>, [email protected] <javascript:> > > Summary > > We want to freeze and unify (but not remove) the User Agent string in > HTTP requests as well as in `navigator.userAgent` > > Motivation > > The User-Agent string is an abundant source of passive fingerprinting > information about our users. It contains many details about the user’s > browser and device as well as many lies ("Mozilla/5.0", anyone?) that were > or are needed for compatibility purposes, as servers grew reliant on bad > User Agent sniffing. > > On top of those privacy issues, User-Agent sniffing is an abundant source > of compatibility issues, in particular for minority browsers, resulting in > browsers lying about themselves (generally > <https://www.zdnet.com/article/vivaldi-to-change-user-agent-string-to-chrome-due-to-unfair-blocking/> > > or to specific sites > <https://github.com/mozilla/webcompat-addon/blob/master/src/injections/js/bug1472075-bankofamerica.com-ua-change.js>), > > and sites (including Google properties) being broken > <https://www.onmsft.com/news/google-has-apparently-blocked-its-stadia-cloud-gaming-service-on-the-chromium-based-microsoft-edge> > > in some browsers for no good reason. > > The above abuse makes it desirable to freeze the UA string and replace it > with a better mechanism. There have been past attempts at UA string > freezing from the Safari team, but without an alternative way to perform UA > based content-negotiation, they had to be partially reverted. > > > > The User Agent Client Hints <https://wicg.github.io/ua-client-hints/> > (UA-CH) feature provides an alternate source for the information the > User-Agent string provides, both in its request header form as well as its > JS API one. > > Its main advantages are: > > - > > It provides the required information only when the server requests it, > over secure connections, making any fingerprinting that relies on it be > active > fingerprinting, which enables such use to be audited, as well as > acted-upon by the browser (e.g. in a future implementation of the Privacy > Budget <https://github.com/bslassey/privacy-budget>). > - > > It provides the information in small increments, so servers are only > exposed to the information they need and request, rather than being > exposed > to the full gamut of the UA string even if they are just trying to figure > out one detail about the browser. (e.g. brand and major version) > - > > Since it provides the information via dedicated fields, it enables > better ergonomics and makes it less likely for servers to get it wrong and > cause compatibility issues. > - > > And finally, starting fresh will enable us to drop a lot of the legacy > baggage that the UA string carries (“Mozilla/5.0”, “like Gecko”, “like > KHTML”, etc) going forward. > > > Once UA-CH ships > <https://groups.google.com/a/chromium.org/d/msg/blink-dev/A4wxFpvqUfA/g7iccl9ICgAJ> > > as an alternative means for browser-specific content adaptation, we would > like to freeze the User-Agent string. > > We propose to deprecate at M81 (starting to emit console warnings in pages > that read that string in JS), freeze its version information at M83, and > unify strings of different devices at M85. See detailed freezing plan > below. > > This timeline provides 3 months for developers to move to the new > mechanism for their future browser and OS version needs, and 6 months for > more sophisticated OS or device specific targeting. > > Freezing plan > > Different parts of the UA string have different compatibility > implications. > > Some parts of it, such as the browser version and the OS version, can be > frozen without any backwards compatibility implications. Values that worked > in the past will continue to work in the future. > > Other parts, such as the model (for mobile devices) and the OS platform, > can have implications on sites that tailor their UI to the underlying OS or > that target a very specific model in their layout. Such sites will need to > migrate to use UA-CH. > > > As such we are planning to freeze the parts that are amenable to freezing > fairly early, and gradually unify the rest. > > > Milestone > > Stable date > > Action > > M81 > > Mid March ‘20 > > Deprecate access to `navigator.userAgent` > > M83 > > Early June ‘20 > > Freeze browser version and unify OS versions > > M85 > > Mid September ‘20 > > Unify desktop OS string as a common value for desktop browsers. > > Unify mobile OS/device strings as a similarly common value for those at > M85 (*) > > > (*) For the mobile value, we may split it further based on common device > dimensions, as a one-time exercise, to reduce the compatibility risk of > unification. > > > > Interoperability and Compatibility Risk > > The compatibility risk varies at different stages. > > For the freezing planned for M83, the compatibility risk is low. Existing > UA sniffing code will continue to work as expected. It is only future UA > sniffing code that will need to change and use the UA client hints instead. > > For the unification planned for M85, the compatibility risk is medium. > Some sites can modify their responses based on the OS and device model, and > those sites will have to change their UA sniffing code to use UA-CH. We > expect such sites to be well maintained (otherwise, how can they keep up > with OS UI and device model changes?). Therefore, having 4 releases to > modify their code seems sufficient. > > In the long term, we expect this change to improve compatibility, as UA > sniffing based on UA-CH is bound to be more reliable than the current > status quo. > > As for interoperability, we have other vendors on board with UA freezing, > but not necessarily with the UA Client Hints mechanism, that is supposed to > replace it. That can create a tricky situation, where developers would need > to rely on the User-Agent string for some browsers and on UA-CH for others. > > Edge: Public support > <https://twitter.com/_scottlow/status/1206831008261132289> > > Firefox: Public support > <https://github.com/mozilla/standards-positions/issues/202#issuecomment-558294095> > > for freezing the UA string - “freezing the User Agent string without any > client hints—seems worth-prototyping” > > Safari: Shipped to some extent. Safari has attempted to completely freeze > <https://twitter.com/rmondello/status/943545865204989953> the UA string > in the past, without providing an alternative mechanism. That got a lot of > pushback, which resulted in somewhat reverting that decision. Nowadays, > their UA string seems frozen, other than updates to the OS version and the > browser major version. > > > Alternative implementation suggestion for web developers > > For many (most?) uses of UA sniffing today, a better tool for the job > would be to use feature detection. Where feature detection fails > developers, UA Client Hints <https://wicg.github.io/ua-client-hints/> are > the right path forward. > > Potential deployment hurdles compared to status quo: > > - > > Third party services that rely on the UA string would need to convince > the sites that include them to delegate that information to them using > Feature Policy. > - > > The opt-in based mechanism of Client Hints currently suffers from the > fact that on the very-first view, the browser have not yet received the > opt-in. That means that requiring specific UA information (e.g. device > model, platform) on the very-first navigation request may incur a delay. > We > are exploring options to enable the opt-in to happen further down the > stack > to avoid that delay. > > > Usage information from UseCounter > <https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39> > > If we were going to remove the User-Agent string outright, the answer to > that would’ve been “a lot!!!!111”. > > Given that we are planning to freeze it, we expect the “removal” to be > mostly backwards compatible, barring cases of specific OS or device > adaptation. > > Client-side UA sniffing use counters > <https://www.chromestatus.com/metrics/feature/timeline/popularity/2663> > show it’s being used by ~90% of sites. But again, since we’re talking about > freezing, it should not break most uses. > > Entry on the feature dashboard <https://www.chromestatus.com/> > > https://www.chromestatus.com/feature/5704553745874944 > > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/dae10de8-2274-4d35-9e7a-26ce72679b3f%40chromium.org.
