On Wed, 18 Jan 2023 at 12:29, Victor Tan <victor...@chromium.org> wrote:
> Hi Torne, > Thanks for your information. We understand your concern. > UA-CH in WebView will be shipping in Chrome M110 > <https://chromestatus.com/feature/4936247663919104>. > 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. > 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 >> >> On Wed, Jan 18, 2023 at 12:06 PM Torne (Richard Coles) < >> to...@chromium.org> wrote: >> >>> 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. >>> >>> On Tue, 17 Jan 2023 at 11:02, Victor Tan <victor...@chromium.org> wrote: >>> >>>> Contact emails >>>> >>>> victor...@chromium.org, miketa...@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 >>>> <https://compat.spec.whatwg.org/> will be updated in the UA String >>>> section <https://compat.spec.whatwg.org/#ua-string-pattern-chrome>, >>>> like we did for the Phase 4 and plan to do for Phase 5 changes. >>>> >>>> Summary >>>> >>>> As previously detailed on the Chromium Blog >>>> <https://blog.chromium.org/2021/09/user-agent-reduction-origin-trial-and-dates.html>, >>>> we intend to proceed with Phase 6 of the User-Agent Reduction plan >>>> <https://www.chromium.org/updates/ua-reduction/#sample-ua-strings-phase-6>. >>>> 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 >>>> <https://developer.chrome.com/origintrials/#/view_trial/2608710084154359809> >>>> 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 >>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>> ? >>>> >>>> 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 >>>> >>>> -- >>>> 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+unsubscr...@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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh4P7F7jKA4985JjpdzTr_XDkP%3DfS2pKaoBMStad9%3DujUzjuw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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+unsubscr...@chromium.org. >>> 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEV-rjcX%3D1sj8bO%2BUdNRjgMwaRHm7ytB24oH4S1GvU0QrYKTzg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEV-rjeofjeyPcKTFNjkrP4sYjh3-WmZqwmdX2QzCJr0kKLJow%40mail.gmail.com.
