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
>
> yoavwe...@chromium.org <javascript:>, aaron...@chromium.org <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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
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.
