Intent to Deprecate and Freeze: The User-Agent string

[Yoav Weiss]

Contact emails

yoav...@chromium.org, aaro...@chromium.org

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 or to specific sites), and sites (including Google properties) being broken 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 (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).

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

Firefox: Public support 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 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 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

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 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/feature/5704553745874944

[Alex Russell]

Hey Yoav, Aaron:

Glad to see the CH-UA intent to out to ensure that similar information is provided no matter where this intent lands. Can you confirm that, if given approval for this, you will not take action to change UA behavior until CH-UA is shipped?

Presumably, in the context of privacy budgets, a model has been developed that discusses the bits of entropy reduction by default that are gained and the performance tradeoffs of requiring Accept-CH redirectors on nearly all top-level entrypoints for major services that wish to avoid overpolyfilling. Can you publish that analysis?

What work has gone into discussing this change with latency-sensitive properties and services? I'm aware that other UAs have implemented similar changes, but they have also been UAs that tend to benefit from high-end devices and networks by dint of their users being wealthy. If this change had been made 2 years ago, what would the polyfill bloat impact be on our user-base for those serving optimally (e.g., using polyfill.io)?

Regards

[Yoav Weiss]

On Tue, Jan 14, 2020 at 4:25 PM 'Alex Russell' via blink-dev <blin...@chromium.org> wrote:

Hey Yoav, Aaron:

Glad to see the CH-UA intent to out to ensure that similar information is provided no matter where this intent lands. Can you confirm that, if given approval for this, you will not take action to change UA behavior until CH-UA is shipped?

This change is indeed dependent on UA-CH shipping before the first freezing milestone.

 

Presumably, in the context of privacy budgets, a model has been developed that discusses the bits of entropy reduction by default that are gained and the performance tradeoffs of requiring Accept-CH redirectors on nearly all top-level entrypoints for major services that wish to avoid overpolyfilling. Can you publish that analysis?

The assumption is that polyfill avoidance (and most other use-cases for UA string content negotiation) can get by with `Sec-CH-UA` values of brand and major version that will continue to be sent to servers by default.

Is that not the case? If not, can you elaborate on the need to polyfill based on minor versions?

What work has gone into discussing this change with latency-sensitive properties and services? I'm aware that other UAs have implemented similar changes, but they have also been UAs that tend to benefit from high-end devices and networks by dint of their users being wealthy. If this change had been made 2 years ago, what would the polyfill bloat impact be on our user-base for those serving optimally (e.g., using polyfill.io)?

Again, the assumption is that the major version is sufficient for polyfilling.

Even if we assume that it is somehow insufficient, then when polyfill.io is integrated on the client side (e.g. as a `<script>` tag), the requesting site can opt-in for receiving the minor version as well (using `Accept-CH`).

For server side integration, the very-first hit will indeed lack that information at the moment.

We've been discussing various designs to resolve that problem (e.g. by providing the opt-in through lower layers), and hope to solve it in the future. However, we didn't consider this blocking for going ahead with this change.

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fbfd9b0b-97a4-4775-b4e2-a4da9f87660f%40chromium.org.

[Aaron Tagliaboschi]

On Tue, Jan 14, 2020 at 11:05 AM <josh.d...@realtruck.com> wrote:

a) If the server doesn't get the info on first hit isn't there a performance penalty in that it has to respond with what it wants, then wait for the response just to give the optimal experience?

 

This is indeed something we're looking at, both in terms of handling in the browser and lower levels. It should also be noted that this only happens on navigation requests, as the accept-ch preferences are passed down to 1p subresources. We're also collecting use-cases and feedback about it, so if you have concrete examples of the issue we'd love to know!

 b) I'm a little unclear on mobileness, what values should be given for a phone, tablet, desktop?

 

If you're asking about the content of the header itself, it's based on the Structured Headers proposal here. As for how to choose which value, we're going on what Chrome currently uses, which is to say that desktops send false ("?0") and Android-based devices send true ("?1"), unless "Request Desktop" is enabled, in which case it sends false. This is the current implicit definition of "mobileness", used for whether or not "Mobile" is put in the UA header string. 

c) Depending on b), it would be nice to at least have resolution buckets so we can return the most appropriate experience. Right now the experience for universal applications having to leverage UA sniffing (server) and resolution (client) is really bad.

FYI, there is also the "viewport-width" client hint, which will tell you the CSS px width of the viewport. If you want to go even crazier, you can request the "model" client hint, get the device model, and look up the width, height, and any other information based on that. That's not as recommended though unless you need very fine-grained information, as it's always better to get the least amount of entropy needed.

On Tuesday, January 14, 2020 at 5:22:00 AM UTC-6, Yoav Weiss wrote:

Contact emails

yoav...@chromium.org, aaro...@chromium.org

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 or to specific sites), and sites (including Google properties) being broken 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 Clicsscssent 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. 

[Domenic Denicola]

From: blin...@chromium.org <blin...@chromium.org> On Behalf Of Yoav Weiss

> The assumption is that polyfill avoidance (and most other use-cases for UA string content negotiation) can get by with `Sec-CH-UA` values of brand and major version that will continue to be sent to servers by default.
> Is that not the case? If not, can you elaborate on the need to polyfill based on minor versions?

Safari generally adds significant features in minor versions, so I'm not sure it would suffice for their use case.

[con...@superhuman.com]

Thanks for sharing this. Maybe I missed this in reading through the spec, but is the same information as sent via the Sec-CH- headers going to be available to JavaScript running on the page?

I ask because at Superhuman we parse the userAgent string client side for several things:

1. If the operating system is Linux or Windows we increase the contrast of the CSS to better fit with user expectations.
2. Depending on the device (e.g. iPhone vs Android) we display a different error message to users, and to direct them to the appropriate App Store.
3. We use the minor version number of the browser to block known ‘bad’ versions of Chrome Canary and explain the situation (in the rare cases it contains bugs that break Superhuman fundamentally)

Currently we load the HTML and JavaScript from Google Cloud Storage, and so this logic could not live on the server for us.

[Rowan Merewood]

Hey Conrad,

I think it's a little clearer in the explainer: https://github.com/WICG/ua-client-hints#a-proposal proposes exposing a NavigatorUAData interface via navigator.getUserAgent()

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e5bd3db-0662-4de7-8bbb-004091b780f9%40chromium.org.

[Yoav Weiss]

Indeed. I wouldn't consider Safari's mid-year releases a "minor version" though. We need to clarify that in the spec. 

[fer...@gmail.com]

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

This drawback seems significant and ought to block the release of this feature until it is solved.

Moving fast and breaking things is not the way of the web.

[Conrad Irwin]

Thanks Rowan!

Out of interest, is there a public timeline for client hints shipping without a flag? I would have thought that this would block on that, but it sounds like they're happening independently.

(Beyond https://bugs.chromium.org/p/chromium/issues/detail?id=928669 and https://www.chromestatus.com/feature/5995832180473856, is there anywhere else I can subscribe to updates?)

Conrad

P.S. Superhuman is hiring — referral bonus for Full Stack Engineers: $1,947.

On Tue, Jan 14, 2020 at 9:41 AM, Rowan Merewood <mere...@chromium.org> wrote:

Hey Conrad,

I think it's a little clearer in the explainer: https://github.com/WICG/ua-client-hints#a-proposal proposes exposing a NavigatorUAData interface via navigator.getUserAgent()

On Tue, 14 Jan 2020 at 17:08, conrad via blink-dev <blink-dev@chromium.org> wrote:

Thanks for sharing this. Maybe I missed this in reading through the spec, but is the same information as sent via the Sec-CH- headers going to be available to JavaScript running on the page?

I ask because at Superhuman we parse the userAgent string client side for several things:

1. If the operating system is Linux or Windows we increase the contrast of the CSS to better fit with user expectations.
2. Depending on the device (e.g. iPhone vs Android) we display a different error message to users, and to direct them to the appropriate App Store.
3. We use the minor version number of the browser to block known ‘bad’ versions of Chrome Canary and explain the situation (in the rare cases it contains bugs that break Superhuman fundamentally)

Currently we load the HTML and JavaScript from Google Cloud Storage, and so this logic could not live on the server for us.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[aaro...@chromium.org]

The I2S for the UA client hints is here: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/A4wxFpvqUfA

TL;DR: M81

[Shimi Zhang]

How does this affect Android WebView? WebView allows app developers to set user agent string, will that still work after the freeze and deprecation? Cc'ing people who might be interested in this Intent to Deprecate and Freeze.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e5bd3db-0662-4de7-8bbb-004091b780f9%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8a0dbd52-2793-4398-ac15-bb9afe64769b%40chromium.org.

[Aaron Tagliaboschi]

Can you point where the API meets the //content code for this path? I'm fairly sure that this would overwrite the frozen string, but I can make sure for you. I'm just not as familiar with the webview part of the codebase.

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/-2JIRNMWJ7s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BjkKumWa7az2jgGLNbyXAkLyeAffLwdh0gOeN80boRZMc4yCA%40mail.gmail.com.

[Shimi Zhang]

On Tue, Jan 14, 2020 at 12:41 PM Aaron Tagliaboschi <aaro...@chromium.org> wrote:

Can you point where the API meets the //content code for this path? I'm fairly sure that this would overwrite the frozen string, but I can make sure for you. I'm just not as familiar with the webview part of the codebase.

The meet point is AwSettings::UpdateUserAgentLocked(), it calls WebContents::SetUserAgentOverride() and NavigationEntry::SetIsOverridingUserAgent()

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJwB4XarrBWCMpAPEkD3PCL29bwnzCQ2Ah%3DJK7JHwssRL5FQJQ%40mail.gmail.com.

[Changwan Ryu]

Just wanted to note that WPT results for client hint on Android WebView is not on par with Chrome on Android:

https://docs.google.com/spreadsheets/d/1_UkaHp7Y5Qus_ASBXlGMOLKsrgBPSrCkVhDkUBYBFr0/edit#gid=1642632070

which may or may not related to https://crbug.com/921655.

Do we need to fix these?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BjkKukk_NJbJZz7W-yrm3wUCkXfxEj6Mioe9Yxr94U_3%3DmFww%40mail.gmail.com.

[Aaron Tagliaboschi]

There's some flakiness in one of the tests. I've just put out a CL for it. Would it be possible to get a report for the tests after the merge so we can see where any failures are?

[Michaela Merz]

I am trying to understand that: The data about the browser is still available, but we have to send an additional request (for Sec-CH) to the user-agent? Or can the (Accept-CH) header be sent right away during the initial server response? How and why is this preventing finger printing?

m.

On Tuesday, January 14, 2020 at 5:22:00 AM UTC-6, Yoav Weiss wrote:

[thorsten...@sap.com]

A  second roundtrip to get more information is definitely a performance issue especially with high latency times. From our perspective the platform e.g. win or macos would be helpful as default information as certain things behaves differently on the platform. Just to make a very simple example tooltips/menu entries for hotkeys (like ctrl+s) are differently on a mac or win (ctrl vs. cmd key) and already part from server in the first roundtrip.

Depending whether the frozen UserAgent string and JS interface remains it is highly incompatible and would result especially for enterprise customer to upgrade the complete landscape. 3 months are maybe enough to implement but not to update a large onprem landscape with hundreds of mission critical servers. We currently have this issue with the dismissal of syncXHR.

Enough time between releasing the new interface and deprecation of the old behavior would be necessary to give enterprise customers enough time to upgrade their systems or like in the syncXHR a possibility to opt-in the user-agent via flag and group policy

[jj]

Summary

We want to freeze and unify (but not remove) the User Agent string in HTTP requests as well as in `navigator.userAgent`

Just to state the obvious: This includes changes to navigator.appVersion and navigator.platform, yes?

 

[Philip Jägenstedt]

That's right, Safari currently has two releases per year. Between
Safari 12.0 and 12.1 there are significant changes both in WPT results
and API surface:
https://wpt.fyi/results/?label=master&label=stable&product=safari-12.0&product=safari-12.1&aligned&diff&filter=ADC
https://web-confluence.appspot.com/#!/catalog?releases=%5B%22Safari_12.0_OSX_10.13.6%22,%22Safari_12.1_OSX_10.13.6%22%5D&q=%22count:1%22

[Philip Jägenstedt]

I'm glad to see an effort towards freezing the UA string and finding alternatives. UA sniffing is at the root of countless web compat issues and these disproportionately affect browsers the developer didn't test in or think about.

At the same time, this header has been evolving and mutating since Mosaic, and freezing it is bound to have effects all across the ecosystem and cause a lot of frustration. I'd like to see some of the risks explored more. Some concrete concerns:

This depends on Intent to Ship: Client Hints infrastructure and UA Client Hints, but even if that ships first I don't think we can be confident that this alternative will be sufficient. Would it not be more prudent to ship that first, and work with a number of real sites to see what kind of issues come up? That's not going to shake out some of the long tail issues, but would reveal any common problems. Seeing other vendors adopt UA Client Hints would also help a lot.

The timeline for this seems a fair bit too short given that it's a non-trivial change and can span multiple layers of software, and so need trickle through multiple planning and release cycles. What are the tradeoff of letting this bake 6 months vs. 1 year, say? (Chrome 99 around mid-2022 seems like an upper bound because Chrome 100 will very likely break some sniffing code, just like how Opera's UA string got stuck at 9.)

Showing a deprecation message on 90% of page views is a lot. Sites will likely keep accessing navigator.userAgent if they've determined nothing will break, or they'd have to use another form of sniffing to avoid it. (I have found UA sniffing to avoid triggering deprecate messages in past httparchive digging.) How essential is it to have this message? It looks like Safari doesn't have a console warning.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjpz2AZ4x5nVm8X5%2BHrjdzH1-7f5y7qf6CmGMLTFVU4CQ%40mail.gmail.com.

[Yoav Weiss]

On Wed, Jan 15, 2020 at 11:45 AM Philip Jägenstedt <foo...@chromium.org> wrote:

I'm glad to see an effort towards freezing the UA string and finding alternatives. UA sniffing is at the root of countless web compat issues and these disproportionately affect browsers the developer didn't test in or think about.

At the same time, this header has been evolving and mutating since Mosaic, and freezing it is bound to have effects all across the ecosystem and cause a lot of frustration. I'd like to see some of the risks explored more. Some concrete concerns:

This depends on Intent to Ship: Client Hints infrastructure and UA Client Hints, but even if that ships first I don't think we can be confident that this alternative will be sufficient. Would it not be more prudent to ship that first, and work with a number of real sites to see what kind of issues come up?

It certainly would be more prudent. The urgency comes from the fact that right now, we are broadcasting a lot of information about our users, in clear text, to all servers. We would like to stop doing that.

Our assumption was that 4 releases (between shipping UA CH and unifying the UA string) would be enough time for us to make sure the replacement is sufficient before pulling the plug on the legacy string.

That's not going to shake out some of the long tail issues, but would reveal any common problems. Seeing other vendors adopt UA Client Hints would also help a lot.

I agree that other vendors adopting would help. Unfortunately, Mozilla don't seem to be interested in implementing the CH part. I've asked Apple to re-review, so one can remain hopeful.

The timeline for this seems a fair bit too short given that it's a non-trivial change and can span multiple layers of software, and so need trickle through multiple planning and release cycles. What are the tradeoff of letting this bake 6 months vs. 1 year, say? (Chrome 99 around mid-2022 seems like an upper bound because Chrome 100 will very likely break some sniffing code, just like how Opera's UA string got stuck at 9.)

Letting this bake for a year would mean continuing to send user information, in the clear, to all servers, for 6 more months.

Showing a deprecation message on 90% of page views is a lot. Sites will likely keep accessing navigator.userAgent if they've determined nothing will break, or they'd have to use another form of sniffing to avoid it. (I have found UA sniffing to avoid triggering deprecate messages in past httparchive digging.)

If they'd use `getUserAgent()` for that, that's a win, no? :D

 

How essential is it to have this message? It looks like Safari doesn't have a console warning.

We want to let developers know that the API they are using is about to become useless and move them to the new API. Are there other tools that fit that purpose other than console warnings?

[Torne (Richard Coles)]

Some additional issues with WebView here:

1) I don't think that client hints are fully implemented in WebView right now (I don't think it is wired up to store the requests for hints from servers anywhere), so we might need to deal with that before shipping?

2) WebView apps which override the user agent string might be doing so in order to *conceal* information that's present by default, which might mean that they would also want to control what's exposed via client hints - we might need to consider exposing APIs for that.

3) In general many WebView apps aren't prepared for potentially-breaking changes to web-facing behaviour like this one, and the developers of those apps might not be participating in the larger web ecosystem in a way that would give them any visibility into these kinds of upcoming changes. This is not to say that we shouldn't make this change for WebView, but it may be riskier.

4) WebView's useragent string format is prescribed by Android's Compatibility Definition Document (CDD) and Compatibility Test Suite (CTS). We can't ship changes to WebView that would violate the rules set out in CDD/CTS unless we first update them, which in almost all cases is only permitted for *future* versions of Android not yet released, and can't be changed retroactively unless it's to fix actual errors in the definitions/tests. Freezing most aspects of the UA at their current values without changing the format would not violate the current implementation of CDD/CTS, with one exception: the Android version is expected to be the same value that's exposed to Android apps in general (i.e. something like "Android 5.1" - not a specific build ID or anything, just the "marketing" version number of the OS).

5) There's been past discussion about removing the Android device model name from the UA for either/both of WebView and Chrome on Android, but last I checked this hasn't been resolved. Will the freezing proposal have any impact on this?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJwB4XaR92xCbfp3emxkfRHG7y2Ns%3DCLYJcvL1eXv3oCw7-_KA%40mail.gmail.com.

[jj]

Showing a deprecation message on 90% of page views is a lot. Sites will likely keep accessing navigator.userAgent if they've determined nothing will break, or they'd have to use another form of sniffing to avoid it. (I have found UA sniffing to avoid triggering deprecate messages in past httparchive digging.)

If they'd use `getUserAgent()` for that, that's a win, no? :D

 A lot of UA sniffing code will be happy with the frozen String for years.

Think on things like that, not written by the "sophisticated developers" mentioned in the spec:

if(/Mobi/.test(navigator.userAgent) && !/^iPad/.test(navigator.platform) || window.operamini) {
  /* linkify phone numbers */
}
No need to change this code, no reason for a spammy warning.

[Aaron Tagliaboschi]

That is correct. Interestingly, "appVersion" is based on the UA string itself, so if it's overridden it will be based on that. "platform" is not, but will send the equivalent frozen platform.

[Mike Sherov]

Apologies if this is the wrong place to post feedback, please point me to somewhere more appropriate if it exists.

I have a few points of feedback:

1. It seems here as if there are still unanswered questions about how to achieve parity with the features provided by the UA like how to get browser version on the first pageload, which seems like a very important use case.
2. The use case of preventing fine grained fingerprinting via CH is a good goal, but can't that be addressed by freezing the UA except for vendor, OS, and version, similar to Safari?
3. The public consensus section seems to indicate that FF and Safari have possibly different approaches in play or in mind, that would be compatible with partial UA freeze but not with CH.
4. The fact that freezing the UA is BC is good, but there's tons of existing material and libraries for parsing UA. Switching browser detection mechanism is a significant piece of churn for the Platform, and thus should come with a big benefit that can't be achieved otherwise.

Taking these points all together, it seems the main benefit of switching to CH over partial UA freeze is "drops legacy bits of text from the string" and "provides better ergonomics for sniffing". Neither of these IMO seem like a high enough bar to introduce a second system here and invalidate all of the existing libraries and documentation on the web. Secondly, it would seem you should solve the "first pageload" problem first.

Thanks for considering these points, and I'm happy to hear counterpoints and be convinced this feature is worth the churn.

[john...@google.com]

From a light reading, this seem detrimental to the "Chromium forks". There are many rebrandings of "Chromium" (Edge and Opera being some of the more prominent examples) that we simply ignore and use the Chromium versioning. It seems, as I've read it, to force browsers forks to masquerade as Chrome if they can't be recognized as part of the Chromium family. Did I miss something that would allow this grouping of "families"? Generally, server side rendering requires a reasonable user-agents identification.

I'm also concerned that "freezing" the UA prevents folks from getting the feedback that you need to validate that you have solved the right problems (as nothing is broken "today").

[she...@sher.pl]

How do you plan to support feature detection for Server Side Rendering? Client Hints are available only on second request

[abe...@fastly.com]

FYI polyfill.io currently serves 38 billion requests per month, which depend on accurately identifying browsers (including minot version) via the UA string.

[josh.d...@realtruck.com]

a) If the server doesn't get the info on first hit isn't there a performance penalty in that it has to respond with what it wants, then wait for the response just to give the optimal experience?

b) I'm a little unclear on mobileness, what values should be given for a phone, tablet, desktop?

c) Depending on b), it would be nice to at least have resolution buckets so we can return the most appropriate experience. Right now the experience for universal applications having to leverage UA sniffing (server) and resolution (client) is really bad.

On Tuesday, January 14, 2020 at 5:22:00 AM UTC-6, Yoav Weiss wrote:

Contact emails

yoav...@chromium.org, aaro...@chromium.org

Summary

We want to freeze and unify (but not remove) the User Agent string in HTTP requests as well as in `navigator.userAgent`

[josh.d...@realtruck.com]

On Tuesday, January 14, 2020 at 11:02:34 AM UTC-6, Aaron Tagliaboschi wrote:

FYI, there is also the "viewport-width" client hint, which will tell you the CSS px width of the viewport. If you want to go even crazier, you can request the "model" client hint, get the device model, and look up the width, height, and any other information based on that. That's not as recommended though unless you need very fine-grained information, as it's always better to get the least amount of entropy needed.

I'm confused.  I don't see anything about viewport in the User Agent Client Hints proposal https://wicg.github.io/ua-client-hints/ 

[Aaron Tagliaboschi]

Taking a look around, this should definitely overwrite the frozen string.

Aaron Tagliaboschi | Software Engineer | aaro...@google.com

[she...@sher.pl]

How do you plan to support feature detection for Server Side Rendering? Client Hints as currently designed won't work because they are available only on second request

[Aaron Tagliaboschi]

Aaron Tagliaboschi | Software Engineer | aaro...@google.com

On Tue, Jan 14, 2020 at 4:48 PM Michaela Merz <misc...@googlemail.com> wrote:

I am trying to understand that: The data about the browser is still available, but we have to send an additional request (for Sec-CH) to the user-agent? Or can the (Accept-CH) header be sent right away during the initial server response?

This can be requested in the initial response 

How and why is this preventing finger printing?

 

First off, it's not being sent unless it's asked for, which is nice. But more importantly it gives the opportunity for browsers and users to choose not to send the information for whatever reason (e.g. user-settings, lists, Privacy Budget), as well as being aware of what data is being requested.

See also: Intent to Ship: Client Hints infrastructure and UA Client Hints

[Josh Deltener]

Hmm, nevermind I see what you mean

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/client-hints

The problem i see with this is, it doesn't really allow universal apps to return the best initial payload from the server for new users.

---

From: josh.d...@realtruck.com <josh.d...@realtruck.com>
Sent: Tuesday, January 14, 2020 11:21 AM
To: blink-dev <blin...@chromium.org>
Cc: Josh Deltener <Josh.D...@realtruck.com>; yoav...@chromium.org <yoav...@chromium.org>
Subject: Re: Intent to Deprecate and Freeze: The User-Agent string

 

[James Rosewell - 51Degrees]

Hi Yoav,

Whilst the change may be sensible from an engineering perspective - the User-Agent string is not efficient - it's going to be a breaking change for many industries and services that don't operate to browser provider "dog year" timescales.

Any technology being "retired" or regulatory change would typically be acompanied with a consultaiton period and two years notice. Consider GDPR or mobile networks.

Here's some examples:

1. Programmatic advertising. It's many players - including Google - have spent years developing message formats that have the User-Agent embedded in them. Upgrading them to client hints will require a major version change. The last major version change to AdCom / OpenRTB was released in November 2019 after many years consultation.

2. Analytics solutions will need to rush through changes to support client hints. Their users will need to migrate their deployments otherwise false assumptions will be formed wasting effort and causing confusion.

3. Performance improvements that require instant knowledge of the user agent to minimise data and improve render time for certain devices would be compromised due to the handshake. Consider people living in India where average device profiles are very different to western europe or north america.

4. Any implementation that removes the informaiton provided from the majority, whilst enabling Google due to it's size, influence or breadth of services (play store, android, search), to become the defacto single source of information about browser, operating system and device model usage globally risks being anti competitive. The implementaiton details don't appear to be clear enough to form a conclusion on this.

If the core problem is "we are broadcasting a lot of information about our users, in clear text, to all servers" then a staged approach might be to strengthen the warning around non SSL secure web sites and thrid parties to increase users control and awareness. Such a change could be accompanied with user experience monitoring (I opt in) and the severity of the problem better understood. Adding an SSL certificate is a change many web site operators have already made or are planning to make.

I'm interested in the subject as my business (51Degrees) provides device detection services utilising User-Agent for web traffic. TAC and app keys are used for non web. We've come a long way from "sniffing" using machine learning and other techniques to support analytics, optimisation and problem diagnosis. Switching to client hints helps us from an engineering perspective. Rolling out the change to client hints - in parallel with User-Agent - to gather the extra evidence fields is a substantial change.

Regards,

James

[ad...@gamerperfection.com]

Yoav,

Would the freezing of the UA and introduction of Client Hints assist in anyway of combating the fraudulent use of stolen fingerprints? I am assuming that the server requests to the browser for more detailed information which the "illicit" browser would provide would therefore not go towards helping prevent such fraudulent use?

If this is the case, are there any plans to help prevent this type of activity?

On Tuesday, 14 January 2020 11:22:00 UTC, Yoav Weiss wrote:

Contact emails

yoav...@chromium.org, aaro...@chromium.org

[Philip Jägenstedt]

On Wed, Jan 15, 2020 at 9:42 PM Yoav Weiss <yo...@yoav.ws> wrote:

On Wed, Jan 15, 2020 at 11:45 AM Philip Jägenstedt <foo...@chromium.org> wrote:

I'm glad to see an effort towards freezing the UA string and finding alternatives. UA sniffing is at the root of countless web compat issues and these disproportionately affect browsers the developer didn't test in or think about.

At the same time, this header has been evolving and mutating since Mosaic, and freezing it is bound to have effects all across the ecosystem and cause a lot of frustration. I'd like to see some of the risks explored more. Some concrete concerns:

This depends on Intent to Ship: Client Hints infrastructure and UA Client Hints, but even if that ships first I don't think we can be confident that this alternative will be sufficient. Would it not be more prudent to ship that first, and work with a number of real sites to see what kind of issues come up?

It certainly would be more prudent. The urgency comes from the fact that right now, we are broadcasting a lot of information about our users, in clear text, to all servers. We would like to stop doing that.

Our assumption was that 4 releases (between shipping UA CH and unifying the UA string) would be enough time for us to make sure the replacement is sufficient before pulling the plug on the legacy string.

It could be enough time to show that migrating is possible in most scenarios before the UA string freezes, but it would also be unsurprising if trying to migrate a real-world complex case will reveal a number of issues that need to be resolved. Before we have confidence in CH as a replacement, I don't think we should be deciding on a timeline or communicating dates for UA freezing to web developers.

That's not going to shake out some of the long tail issues, but would reveal any common problems. Seeing other vendors adopt UA Client Hints would also help a lot.

I agree that other vendors adopting would help. Unfortunately, Mozilla don't seem to be interested in implementing the CH part. I've asked Apple to re-review, so one can remain hopeful.

Paging +Michael Taylor to clarify the linked issue. Would Mozilla consider freezing the UA string and only provide the same information via JS APIs? That seems pretty risky to me...

The timeline for this seems a fair bit too short given that it's a non-trivial change and can span multiple layers of software, and so need trickle through multiple planning and release cycles. What are the tradeoff of letting this bake 6 months vs. 1 year, say? (Chrome 99 around mid-2022 seems like an upper bound because Chrome 100 will very likely break some sniffing code, just like how Opera's UA string got stuck at 9.)

Letting this bake for a year would mean continuing to send user information, in the clear, to all servers, for 6 more months.

Yes, it's 6 more months, but what is the tradeoff? How bad for users is the UA string vs. how many sad developers and broken sites? I get there's no exact answer, but the impact on the ecosystem looks like the more concrete risk. It should also give us pause if other vendors aren't planning to freeze their UA strings, it calls the urgency into question.

Showing a deprecation message on 90% of page views is a lot. Sites will likely keep accessing navigator.userAgent if they've determined nothing will break, or they'd have to use another form of sniffing to avoid it. (I have found UA sniffing to avoid triggering deprecate messages in past httparchive digging.)

If they'd use `getUserAgent()` for that, that's a win, no? :D

 

How essential is it to have this message? It looks like Safari doesn't have a console warning.

We want to let developers know that the API they are using is about to become useless and move them to the new API. Are there other tools that fit that purpose other than console warnings?

To spell out the concern, it is about warning fatigue. However, I have to agree that if we commit to a timeline, then we'll have to broadcast this very widely. A lot of the usage won't be practical to remove, however, so it would have to be for a limited time.

[Rik Cabanier]

Can you give some more specific examples what this freezing and unifying of the UA string will look like?

You imply that ALL desktop and mobile versions of Chrome will return the exact same desktop or mobile string regardless of platform (ie windows vs mac). Is that the case?

[Yoav Weiss]

On Wed, Jan 15, 2020 at 4:51 PM Torne (Richard Coles) <to...@chromium.org> wrote:

Some additional issues with WebView here:

1) I don't think that client hints are fully implemented in WebView right now (I don't think it is wired up to store the requests for hints from servers anywhere), so we might need to deal with that before shipping?

That's a good point, and indeed something we need to make sure happens before freezing, at least in WebViews.

 

2) WebView apps which override the user agent string might be doing so in order to *conceal* information that's present by default, which might mean that they would also want to control what's exposed via client hints - we might need to consider exposing APIs for that.

Interesting. What would exposing such an API entail?

 

3) In general many WebView apps aren't prepared for potentially-breaking changes to web-facing behaviour like this one, and the developers of those apps might not be participating in the larger web ecosystem in a way that would give them any visibility into these kinds of upcoming changes. This is not to say that we shouldn't make this change for WebView, but it may be riskier.

What would be a good way to increase awareness to this?

4) WebView's useragent string format is prescribed by Android's Compatibility Definition Document (CDD) and Compatibility Test Suite (CTS). We can't ship changes to WebView that would violate the rules set out in CDD/CTS unless we first update them, which in almost all cases is only permitted for *future* versions of Android not yet released, and can't be changed retroactively unless it's to fix actual errors in the definitions/tests. Freezing most aspects of the UA at their current values without changing the format would not violate the current implementation of CDD/CTS, with one exception: the Android version is expected to be the same value that's exposed to Android apps in general (i.e. something like "Android 5.1" - not a specific build ID or anything, just the "marketing" version number of the OS).

OK, so this may be somewhere where the WebView's UA string and Chrome's would have to diverge...

 

5) There's been past discussion about removing the Android device model name from the UA for either/both of WebView and Chrome on Android, but last I checked this hasn't been resolved. Will the freezing proposal have any impact on this?

This proposal intends to unify Android devices under a single common UA string, so under a single "model". Maybe we can get away (compatibility-wise) with removing the model entirely.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEV-rjf-bMK9sUqYgZ8PQ1V2GH8EeFChMEJ7w_JnUnoJqgfFng%40mail.gmail.com.

[Yoav Weiss]

On Wed, Jan 15, 2020 at 8:34 PM johnlenz via blink-dev <blin...@chromium.org> wrote:

From a light reading, this seem detrimental to the "Chromium forks". There are many rebrandings of "Chromium" (Edge and Opera being some of the more prominent examples) that we simply ignore and use the Chromium versioning.  It seems, as I've read it, to force browsers forks to masquerade as Chrome if they can't be recognized as part of the Chromium family.  Did I miss something that would allow this grouping of "families"?   Generally, server side rendering requires a reasonable user-agents identification. 

See https://github.com/WICG/ua-client-hints#should-the-ua-string-be-a-set and https://github.com/WICG/ua-client-hints/issues/22 

I'm also concerned that "freezing" the UA prevents folks from getting the feedback that you need to validate that you have solved the right problems (as nothing is broken "today").

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7b2fd069-ab61-4257-bc8c-0b5d73a6bb1e%40chromium.org.

[Yoav Weiss]

While I'd have preferred such uses to move to getUserAgent() (cheaper and more accurate), I see your point.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/62082d91-ce30-4455-806a-0b68eee531ab%40chromium.org.

[Yoav Weiss]

On Tue, Jan 14, 2020 at 10:51 PM <thorsten...@sap.com> wrote:

A  second roundtrip to get more information is definitely a performance issue especially with high latency times. From our perspective the platform e.g. win or macos would be helpful as default information as certain things behaves differently on the platform. Just to make a very simple example tooltips/menu entries for hotkeys (like ctrl+s) are differently on a mac or win (ctrl vs. cmd key) and already part from server in the first roundtrip.

Sending different code to each platform just to handle different keys sounds like an overkill. Do you have a real-life example where OS related changes can't be reasonably done on the client-side?

 

Depending whether the frozen UserAgent string and JS interface remains it is highly incompatible and would result especially for enterprise customer to upgrade the complete landscape. 3 months are maybe enough to implement but not to update a large onprem landscape with hundreds of mission critical servers. We currently have this issue with the dismissal of syncXHR.

Enough time between releasing the new interface and deprecation of the old behavior would be necessary to give enterprise customers enough time to upgrade their systems or like in the syncXHR a possibility to opt-in the user-agent via flag and group policy

Adding an enterprise policy flag sounds reasonable. 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/98bb9c26-91c5-47b6-8165-dea0b2b4c7aa%40chromium.org.

[Yoav Weiss]

On Tue, Jan 14, 2020 at 7:26 PM <fer...@gmail.com> wrote:

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

This drawback seems significant and ought to block the release of this feature until it is solved.

The thought is that the parts that are sent by default (UA brand and meaningful version, as well as most-probably the mobileness bit) would be sufficient for most cases of UA based content negotiation to not require any delays.

Do you have common use-cases where this information will not be sufficient?

 

Moving fast and breaking things is not the way of the web.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d7deba3b-2075-4759-81b5-e0c41b944539%40chromium.org.

[Yoav Weiss]

On Wed, Jan 15, 2020 at 8:34 PM Mike Sherov <mike....@gmail.com> wrote:

Apologies if this is the wrong place to post feedback, please point me to somewhere more appropriate if it exists.

I have a few points of feedback:

1. It seems here as if there are still unanswered questions about how to achieve parity with the features provided by the UA like how to get browser version on the first pageload, which seems like a very important use case.

For the meaningful part of the browser version, it will be sent by default without requiring an opt-in.

For the full version, you are correct at the moment. If you referred to the latter, what would be the use-case? Why do you need that information for HTML content adaptation?

 

2. The use case of preventing fine grained fingerprinting via CH is a good goal, but can't that be addressed by freezing the UA except for vendor, OS, and version, similar to Safari?

The OS adds significant entropy. For vendor and version, you've successfully convinced me that we can leave them unfrozen for now, and potentially tackle them (in case we'd see a compatibility need) in the future.

3. The public consensus section seems to indicate that FF and Safari have possibly different approaches in play or in mind, that would be compatible with partial UA freeze but not with CH.
4. The fact that freezing the UA is BC is good, but there's tons of existing material and libraries for parsing UA. Switching browser detection mechanism is a significant piece of churn for the Platform, and thus should come with a big benefit that can't be achieved otherwise.

Taking these points all together, it seems the main benefit of switching to CH over partial UA freeze is "drops legacy bits of text from the string" and "provides better ergonomics for sniffing". Neither of these IMO seem like a high enough bar to introduce a second system here and invalidate all of the existing libraries and documentation on the web. Secondly, it would seem you should solve the "first pageload" problem first.

The main benefit is to provide developers that require more bits of entropy with an alternative mechanism that enables them to request it.

 

Thanks for considering these points, and I'm happy to hear counterpoints and be convinced this feature is worth the churn.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/927e2f0a-bbc1-4a2c-9cbe-ea05f59afb78%40chromium.org.

[Yoav Weiss]

On Wed, Jan 15, 2020 at 8:34 PM abetts via blink-dev <blin...@chromium.org> wrote:

FYI polyfill.io currently serves 38 billion requests per month, which depend on accurately identifying browsers (including minot version) via the UA string.

Note that the polyfill.io use case is well covered by the fact that UA brand and meaningful version are sent by default, without requiring an opt-in.

Regarding minor version, I believe there's some confusion around the term: https://github.com/WICG/ua-client-hints/issues/23

We will modify the spec to clarify that Safari's mid-year releases (which include new features) are not considered "minor".

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d5087dcc-aa14-4907-85c2-085a5ca3b5b5%40chromium.org.

[Yoav Weiss]

On Wed, Jan 15, 2020 at 8:35 PM <ad...@gamerperfection.com> wrote:

Yoav,

Would the freezing of the UA and introduction of Client Hints assist in anyway of combating the fraudulent use of stolen fingerprints? I am assuming that the server requests to the browser for more detailed information which the "illicit" browser would provide would therefore not go towards helping prevent such fraudulent use?

If this is the case, are there any plans to help prevent this type of activity?

Once we turn the information from being passively sent out to one that's actively asked for by the server, the browser could keep track of who is asking for it. Then a mechanism like the Privacy Budget could be used to restrict access to that information in cases where the browser suspects that the access to the information is for nefarious purposes.

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4733a289-7417-4c96-8758-ef1578ca2142%40chromium.org.

[Philip Jägenstedt]

On Fri, Jan 17, 2020 at 11:56 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Tue, Jan 14, 2020 at 7:26 PM <fer...@gmail.com> wrote:

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

This drawback seems significant and ought to block the release of this feature until it is solved.

The thought is that the parts that are sent by default (UA brand and meaningful version, as well as most-probably the mobileness bit) would be sufficient for most cases of UA based content negotiation to not require any delays.

Do you have common use-cases where this information will not be sufficient?

Learning about such use cases would be valuable, but I don't think we can assume the change to be safe in the absence of such examples. And at the scale we're talking about, usage doesn't need to be common to pose a serious compat problem.

Given that use counters will fail us here, some different form of compat analysis is needed. https://gist.github.com/foolip/38e3ea6f060bad4638c2aea6fac63e80 is an example of what this might look like, there varying the Accept-Language header and looking at how the result varies. Rough sketch of what it might look like for the UA header, in line with Blink principles of web compatibility:

• Crawl the same sites with multiple forms of the UA header
• Identify the sites where some of the responses vary (could also compare code paths taken and rendering)
• Confirm the differences by re-crawling to reduce noise
• Look at a sample of the candidate sites, assessing the severity to users and the difficulty to fix for users

This is time consuming, but it's what it will take to understand the risk.

[Yoav Weiss]

On Thu, Jan 16, 2020 at 4:22 PM Philip Jägenstedt <foo...@chromium.org> wrote:

On Wed, Jan 15, 2020 at 9:42 PM Yoav Weiss <yo...@yoav.ws> wrote:

On Wed, Jan 15, 2020 at 11:45 AM Philip Jägenstedt <foo...@chromium.org> wrote:

I'm glad to see an effort towards freezing the UA string and finding alternatives. UA sniffing is at the root of countless web compat issues and these disproportionately affect browsers the developer didn't test in or think about.

At the same time, this header has been evolving and mutating since Mosaic, and freezing it is bound to have effects all across the ecosystem and cause a lot of frustration. I'd like to see some of the risks explored more. Some concrete concerns:

This depends on Intent to Ship: Client Hints infrastructure and UA Client Hints, but even if that ships first I don't think we can be confident that this alternative will be sufficient. Would it not be more prudent to ship that first, and work with a number of real sites to see what kind of issues come up?

It certainly would be more prudent. The urgency comes from the fact that right now, we are broadcasting a lot of information about our users, in clear text, to all servers. We would like to stop doing that.

Our assumption was that 4 releases (between shipping UA CH and unifying the UA string) would be enough time for us to make sure the replacement is sufficient before pulling the plug on the legacy string.

It could be enough time to show that migrating is possible in most scenarios before the UA string freezes, but it would also be unsurprising if trying to migrate a real-world complex case will reveal a number of issues that need to be resolved. Before we have confidence in CH as a replacement, I don't think we should be deciding on a timeline or communicating dates for UA freezing to web developers.

That's not going to shake out some of the long tail issues, but would reveal any common problems. Seeing other vendors adopt UA Client Hints would also help a lot.

I agree that other vendors adopting would help. Unfortunately, Mozilla don't seem to be interested in implementing the CH part. I've asked Apple to re-review, so one can remain hopeful.

Paging +Michael Taylor to clarify the linked issue. Would Mozilla consider freezing the UA string and only provide the same information via JS APIs? That seems pretty risky to me...

The timeline for this seems a fair bit too short given that it's a non-trivial change and can span multiple layers of software, and so need trickle through multiple planning and release cycles. What are the tradeoff of letting this bake 6 months vs. 1 year, say? (Chrome 99 around mid-2022 seems like an upper bound because Chrome 100 will very likely break some sniffing code, just like how Opera's UA string got stuck at 9.)

Letting this bake for a year would mean continuing to send user information, in the clear, to all servers, for 6 more months.

Yes, it's 6 more months, but what is the tradeoff? How bad for users is the UA string vs. how many sad developers and broken sites? I get there's no exact answer, but the impact on the ecosystem looks like the more concrete risk.

IMO, the main risk for breakage is from the OS and device unification. 

The former seems less risky for server side detection, but maybe carries some risk on the client side (e.g. the wrong keyboard shortcuts picked)

For the latter, my assumption was that folks that are tailoring their layouts to specific devices have to remain on their toes and update that constantly, as new devices arrive to market all the time. 

It should also give us pause if other vendors aren't planning to freeze their UA strings, it calls the urgency into question.

Safari has already partially frozen their UA. Let's wait to see what Mike Taylor says, but my reading of Mozilla's position is that they're considering the same.

 

Showing a deprecation message on 90% of page views is a lot. Sites will likely keep accessing navigator.userAgent if they've determined nothing will break, or they'd have to use another form of sniffing to avoid it. (I have found UA sniffing to avoid triggering deprecate messages in past httparchive digging.)

If they'd use `getUserAgent()` for that, that's a win, no? :D

 

How essential is it to have this message? It looks like Safari doesn't have a console warning.

We want to let developers know that the API they are using is about to become useless and move them to the new API. Are there other tools that fit that purpose other than console warnings?

To spell out the concern, it is about warning fatigue. However, I have to agree that if we commit to a timeline, then we'll have to broadcast this very widely. A lot of the usage won't be practical to remove, however, so it would have to be for a limited time.

Limited time warnings sound reasonable.

[Yoav Weiss]

That's indeed the intention.

[Yoav Weiss]

On Fri, Jan 17, 2020 at 6:22 AM Philip Jägenstedt <foo...@chromium.org> wrote:

On Fri, Jan 17, 2020 at 11:56 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Tue, Jan 14, 2020 at 7:26 PM <fer...@gmail.com> wrote:

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

This drawback seems significant and ought to block the release of this feature until it is solved.

The thought is that the parts that are sent by default (UA brand and meaningful version, as well as most-probably the mobileness bit) would be sufficient for most cases of UA based content negotiation to not require any delays.

Do you have common use-cases where this information will not be sufficient?

Learning about such use cases would be valuable, but I don't think we can assume the change to be safe in the absence of such examples. And at the scale we're talking about, usage doesn't need to be common to pose a serious compat problem.

As a side note, I believe the concerns raised were not about compat, but about missing/lacking capability in the alternative.

With that said... 

Given that use counters will fail us here, some different form of compat analysis is needed. https://gist.github.com/foolip/38e3ea6f060bad4638c2aea6fac63e80 is an example of what this might look like, there varying the Accept-Language header and looking at how the result varies.

That's great research! Seems relevant for https://github.com/WICG/lang-client-hint

 

Rough sketch of what it might look like for the UA header, in line with Blink principles of web compatibility:

• Crawl the same sites with multiple forms of the UA header
• Identify the sites where some of the responses vary (could also compare code paths taken and rendering)
• Confirm the differences by re-crawling to reduce noise
• Look at a sample of the candidate sites, assessing the severity to users and the difficulty to fix for users

This is time consuming, but it's what it will take to understand the risk.

That sounds reasonable to me. 

[Philip Jägenstedt]

On Fri, Jan 17, 2020 at 12:24 PM Yoav Weiss <yo...@yoav.ws> wrote:

On Thu, Jan 16, 2020 at 4:22 PM Philip Jägenstedt <foo...@chromium.org> wrote:

On Wed, Jan 15, 2020 at 9:42 PM Yoav Weiss <yo...@yoav.ws> wrote: