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 On Wed, Jan 18, 2023 at 12:49 PM Torne (Richard Coles) <to...@chromium.org> wrote: > 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/CAJh4P7ErwXsDMjpAUS66Eyn-kWm_Gnx3saOwm8e12K9XCv-Pcg%40mail.gmail.com.
