Intent to Implement & Ship: User-Agent Reduction Phase 6 (deviceModel and androidVersion reduction in Android)

[Victor Tan]

Contact emails

vict...@chromium.org, mike...@chromium.org 

Explainer

https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity

Specification

https://www.chromium.org/updates/ua-reduction is the closest thing that specifies Chrome’s UA Reduction plans today. As these changes land in Chromium and ship to 100% stable, the Compat Standard will be updated in the UA String section, like we did for the Phase 4 and plan to do for Phase 5 changes.

Summary

As previously detailed on the Chromium Blog, we intend to proceed with Phase 6 of the User-Agent Reduction plan. In Phase 6, we change the deviceModel token to “K” and change the androidVersion token to a static “10” string in Android User-Agent string. The navigator.platform will be a “Linux armv81” constant on the Android platform.

Blink component

Blink>Network>ClientHints

TAG review

https://github.com/w3ctag/design-reviews/issues/640

TAG review status

Closed satisfied with concerns.

Risks

Interoperability and Compatibility

Any time you modify the User-Agent string there is a risk of breaking existing patterns, like some content somewhere depending on the previous format.

We do not expect interoperability risks, as each browser sends its own User-Agent string format. However there is a risk that - on the Android platform - content may rely  on User-Agents to parse deviceModel and androidVersion information. To mitigate the risk of this change, we intend to slowly roll out the format via Finch on the Android platform and observe health metrics and bug reports. See timeline below on our slow roll out plan. This gives us the option to roll this back for the Android platform if major issues arise.

Displaying a static androidVersion and a deviceModel token for Android clients will not create a problem syntactically. But the web can get pretty weird in ways we don't anticipate. For example, sites can rely on the deviceModel in the User-Agent string to determine whether the device is a mobile, laptop or desktop. Currently, we change the deviceModel to a static string, sites need to use client hints as the alternative to determine the right behavior.  Hence the slow roll-out and incremental path towards User-Agent Reduction.

Here is our proposed rollout plan in Chrome Stable channel (Canary/Dev/Beta has been enabled 50%), with the understanding that if we discover concerning breakage or regressions via health metrics or bug reports we will pause the rollout or roll back the feature entirely (and update this thread if so):

Stage	Duration	Date
Stable 1% (M110+)	M110 stable release is shipping to 100% (a best guess)	Feb 14, 2023
Stable 10% (M110/M111)	~4 weeks after previous stage	Mar 14, 2023
Stable 50% (M110/M111)	~2 weeks	Mar 28, 2023
TOT Default (M114)	~2 weeks after previous stage	Apr 11, 2023
Stable 100% (M110=>M114)	~ Same business day as previous stage	Apr 11, 2023

Web stakeholders can still test with the user agent reduction deprecation origin trial until M113 (late May) if they need more time to adapt to the coming changes. The UA-RD OT allows web stakeholders to request the legacy user-agent string values (i.e. non-reduced values). 

Gecko: Shipped/Shipping. Firefox has frozen (or capped) much of their UA string already.

WebKit: Shipped/Shipping. Safari has already frozen everything in their desktop UA string except for Safari and WebKit versions. Also, UA reduction phase 6 will only apply to the Android platform.

Web developers: Mixed signals. Various channels have different reactions. It’s similar for the UA reduction phase 4 and phase 5.

Debuggability

No special DevTools support needed.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No (Only for Android)

Is this feature fully tested by web-platform-tests?

No, because User-Agents vary across browsers.

Flag name

#reduce-user-agent-android-version-device-model

Notes: The existing flag #reduce-user-agent will provide the same format User-Agent string on the Android platform since this is the last phase for User-Agent reduction.

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1394819 

Launch bug

https://launch.corp.google.com/launch/4225291   

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5177681979637760 

[Chris Harrelson]

LGTM1

--
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/CAJh4P7F7jKA4985JjpdzTr_XDkP%3DfS2pKaoBMStad9%3DujUzjuw%40mail.gmail.com.

[slightlyoff via Chromestatus]

LGTM2

[Torne (Richard Coles)]

I have some concerns that we won't be able to use this format for Android WebView. I realise we're not currently shipping UA reduction for WebView, but AFAIK we are still hoping to do so at some point in the future.

WebView's UA format is mandated by Android's CTS compatibility tests. I relaxed the test criteria some time ago to allow the device model and Android build ID to be omitted (though WebView currently still includes this information), but the test currently requires these fields to either be entirely absent, or to exactly match the underlying OS properties. It also does not allow the less-granular OS version to be omitted or spoofed.

It'd be good to have a long term plan for what we're going to do with the UA and with UA-CH in WebView that matches Chrome as closely as possible.

[Rick Byers]

LGTM3*. 

Thank you for your continued careful and cautious approach to this breaking change, I'm excited to see it nearing the final goal. I expect that we'll see an increase in client hints usage (eg. for important anti-fraud use cases) as a result of this change. Given all the advance warning and support you've provided the ecosystem on moving to client hints, I don't personally see that anything would be gained by delaying any further.

*slightlyoff@ LGTM2'd in chromestatus, I haven't seen the e-mail yet but I presume it's coming.

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

[Rick Byers]

Thanks Torne. I don't think it necessarily blocks this intent, but +1 to having a unified plan for WebView. I assume the format (eg. not omitting the device model completely) is being driven by web compat concerns which would matter for WebView as well, right? Do we have any data on the web compatibility of removing the model string entirely? My assumption is that it would be too breaking, but that's just an assumption. Victor, can you or your team meet with Torne and figure out whether a long-term plan for WebView would impact what we do for Chrome now?

Thanks,

   Rick

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

[Victor Tan]

Hi Torne,

Thanks for your information. We understand your concern. 

UA-CH in WebView will be shipping in Chrome M110. UA reduction in WebView is also in our future plan list, we will see how the UA-CH works in Webview. 

For now, I don't think what we did in this phase on Android will impact Webview much since we already did the UA reduction phase 4 on Android platform. 

For the future plan, we will work out a plan (if UA-CH works as expected) to do the UA reduction in Webview to match what we did in Chrome. 

Also, we are glad to discuss with Webview for all other possibilities and impacts.  Thanks. 

Best,

Victor

[Torne (Richard Coles)]

On Wed, 18 Jan 2023 at 12:29, Victor Tan <vict...@chromium.org> wrote:

Hi Torne,

Thanks for your information. We understand your concern. 

UA-CH in WebView will be shipping in Chrome M110.

UA-CH is entirely disabled in WebView at present and shipping CH persistence as covered in that bug is *not* supposed to be enabling it, because we haven't yet done any of the design work to figure out what the APIs exposed to apps for controlling it should be, how it should interact with custom UA strings, whether there should be a way to distinguish WebView from Chrome in the UA-CH values and whether that needs to be standardized, etc.

The referenced bug *should* just be about making all the non-UA client hints work properly in WebView (currently they're mostly useless as Accept-CH isn't being persisted across requests).

UA reduction in WebView is also in our future plan list, we will see how the UA-CH works in Webview. 

We need a plan for how to ship UA-CH for WebView and what it should include first :)

 

For now, I don't think what we did in this phase on Android will impact Webview much since we already did the UA reduction phase 4 on Android platform. 

For the future plan, we will work out a plan (if UA-CH works as expected) to do the UA reduction in Webview to match what we did in Chrome. 

Also, we are glad to discuss with Webview for all other possibilities and impacts.  Thanks. 

Understood, but if we ultimately want to change WebView's UA in a way that doesn't pass the current CDD/CTS requirements then the work to change those requirements needs to happen at *least* an entire Android release ahead of time, and ideally would have been done several years ago if we want it to have the most impact :(

 

Best,

Victor

On Wed, Jan 18, 2023 at 12:20 PM Rick Byers <rby...@chromium.org> wrote:

Thanks Torne. I don't think it necessarily blocks this intent, but +1 to having a unified plan for WebView. I assume the format (eg. not omitting the device model completely) is being driven by web compat concerns which would matter for WebView as well, right?

It's not really directly about web compat concerns. See https://chromium.googlesource.com/chromium/src/+/HEAD/android_webview/docs/web-platform-compatibility.md#Android_s-Compatibility-Test-Suite-tests-some-WebView-behaviours for more on this, but briefly: CTS/CDD are about *application* compatibility - they are requirements the Android OS must satisfy to be considered compatible with existing Android applications. Anything that's tested by CTS is something that app developers are expected to be able to rely on.

It's likely that *most* consideration of WebView's UA string is happening on the web side (by JS or by server side logic), but the UA string is also exposed directly to apps via Java APIs and so the actual code of the app might *also* be parsing this information (and the Java API currently does *not* provide any way to access client hints, other than loading a page and injecting JS into it to access the JS APIs). Web content that's designed only to be loaded in a specific WebView application might potentially rely much more heavily on the specific format of the UA string than content that's intended to be used by multiple browsers, and may not ever be loaded in Chrome or ever show up in web crawler data.

 

Do we have any data on the web compatibility of removing the model string entirely?

The model string is currently omitted automatically on prerelease versions of the Android OS as a basic precaution to not leak model names of unreleased devices. This doesn't get a lot of production usage, but we do regularly get bugs filed against us every single android release by device vendors or other developers complaining that the useragent is "wrong" (even though omitting the model entirely has been explicitly allowed by CTS for quite a few releases now). We've also previously discussed removing the model with various parties who had very strong objections on the grounds that they use it for targeting downloads/support info/etc to particular devices; if this information instead becomes available in UA-CH that may be an acceptable migration path but this will likely be some amount of new impact to developers/sites who are *not* affected by the changes to Chrome's UA (because their content is only loaded inside WebViews).

So, I don't have any concrete data on the impact and we've not run any experiments here, but it's likely to involve at least some new issues distinct from Chrome's.

[Mike Taylor]

Hi Torne,

Yep, I agree we should come up with a plan to understand the WebView context and how we can make progress on removing passive entropy in the future.

thanks,
Mike

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

[Victor Tan]

Hi Torne,

Thanks for the clarification. Sorry, I misread that we are going to ship the UA-CH in android webview. 

I agree we need to meet to discuss the plan for UA-CH and UA reduction on Webview sometime in the near future.  

Best,

Victor

[James Rosewell]

Resolving the issues associated with automated testing prior to commencement of deployment and 14th February should be dependency. See this link.

1212793 - Client hints not sent in headless chrome - chromium

The lack of functional parity in the test environment causes disruption and cost to the rest of the eco-system.

[Mike Taylor]

Hi James,

Thanks for letting us know that this issue has not been fixed yet. I've asked someone on my team to take over the task. Phase 6 will only affect the Android User-Agent string and headless Chrome is not supported on mobile.

--
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/24eecdaf-a59d-44f5-b370-80c4b2f52188n%40chromium.org.

[James Rosewell]

The issue is that automated testing of the web experience for Android uses this feature in automated test environments which can not be Android. As it doesn't work it is no longer possible to automatically test changes that could easily be tested with a variety of UAS values. Thus the only option is to take longer to test using human testers. This increases cost and delays to implementors that would be avoided if the related tools works or UAS were not altered further.

[Mike Taylor]

Hi all,

Due to an unrelated release blocker bug, our best-guess prediction of Feb 14th to start the 1% roll-out was incorrect (M110 on Android is currently at 50%). I'm hopeful we'll be at 100% by next Tuesday, so at the risk of being wrong again (if the timeline slips by a day or two extra, we will not shorten the rollout, but adjust the schedule accordingly), here's an updated roll-out schedule:

Stable 1%: Feb 21, 2023

Stable 5%: Mar 21, 2023 (~4 weeks after previous)

Stable 10%: Apr 4, 2023 (~2 weeks after previous)

Stable 50%: Apr 18, 2023 (~2 weeks after previous)

ToT Default: May 2, 2023 (~2 weeks after previous)
Stable 100%: May 2, 2023

As always, we'll monitor for breakage and stability, and may pause or back-out to investigate concerning feedback or data.

thanks,
Mike 

[Victor Tan]

Hi blink-dev,

Phase 6 of UA Reduction is currently ramping up to 1% of the stable release population on Android platform. 

No changes will occur between now and March 21st, 2023, pending site compatibility feedback. Thanks.

Best,

Victor

[Mike Taylor]

To be extra clear, here is the whole timeline we're considering for rollout, pending unforeseen stability or compatibility issues:

• [done] February 21: Phase 6 roll-out starts one week after the launch of Chrome 110 Stable with 1% traffic. 

• March 21: Roll-out increases to 10% traffic. 

• April 4: Roll-out increases to 50% traffic.

• April 18: Roll-out reaches full Stable population with 100% traffic.

[Mike Taylor]

Hi all,

Correcting my message on 3/3 to be consistent with the rollout timeline I posted on Feb 16. We intend to begin the ramp up to 5% of stable traffic tomorrow.

[done] Stable 1%: Feb 21, 2023

[tomorrow] Stable 5%: Mar 21, 2023 (~4 weeks after previous)

Stable 10%: Apr 4, 2023 (~2 weeks after previous)

Stable 50%: Apr 18, 2023 (~2 weeks after previous)

ToT Default: May 2, 2023 (~2 weeks after previous)
Stable 100%: May 2, 2023

thanks,
Mike

[Victor Tan]

Hi blink-dev,

UA Reduction Phase 6  is currently ramping up to 5% of the stable release population. We will keep monitor the change during the 2 week experiment. 

Thanks.

Victor

[Victor Tan]

Hi blink-dev,

UA Reduction Phase 6  is currently ramping up to 10% of the stable release population. 

Thanks.

Victor

[Victor Tan]

Hi blink-dev,

UA Reduction Phase 6  is ramping up to 50% of the stable release population today. 

Thanks.

Victor

[Mike Taylor]

[Mike Taylor]

Hi all,

UA Reduction Phase 6 is ramping up to 100% of the stable release population as of today.

thanks,
Mike