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