Intent to Prototype and Ship: New UA platform version source on Windows for User-Agent Client Hints
Erik Anderson
Contact emails
elaw...@chromium.org, Erik.A...@microsoft.com
Explainer
Specification
https://github.com/WICG/ua-client-hints
Summary
Updates the version provided via the Sec-CH-UA-Platform-Version on Windows to provide a reasonable level of fidelity to allow sites to identify meaningful Windows platform changes. This aligns with the current definition in the proposal in the UA Client Hints WICG repo.
This enables sites to deliver appropriate binary executables and help content specific to that OS version.
Blink component
Motivation
This enables sites to deliver appropriate binary executables and help content specific to that OS version. The current UA string and existing Sec-CH-UA-Platform-Version implementation provides the "major" and "minor" version Windows components. However, as of Windows 10, Windows generally doesn't increase either of these numbers across significant releases. Notably, Windows 11 does not increase either of these numbers.
The updated UA Client Hints proposal text specifies that the value on Windows should instead be derived based on the Windows.Foundation.UniversalApiContract version. This version revises when the set of APIs exposed on Windows changes in a significant way while not being particularly identifying (e.g. a typical security update will not revise it).
A table of value mappings to Windows releases can be seen in the UA Client Hints' repo issue 220.
TAG review
Recent updates to the proposal are being discussed in w3ctag/design-reviews#640. This doesn't change the fundamental contract, so an additional, separate TAG review is likely unnecessary. Feedback welcome.
TAG review status
Pending
Risks
Interoperability and Compatibility
Sites may already be depending on the existing version being returned. Sites moving from the UA string to the header may also erroneously assume the version scheme will be the same as what is in the UA string today.
However, the UA string has not yet been frozen and it's unlikely sites have hard dependencies on the current value since it has to this point been exposing the same Windows OS version info as the UA string.
Gecko: No signal for this specific change. A broader signal on UA Client Hints in general is tracked via other intents.
WebKit: No signal for this specific change. A broader signal on UA Client Hints in general is tracked via other intents.
Web developers: Positive
Is this feature fully tested by web-platform-tests?
No. There is a test that checks that the UA platform Client Hint is available, but it does not assert that it should be a certain value. Given there isn’t a second mechanism to determine what an expected value should be, we do not plan to have an updated WPT test.
Flag name
None planned given limited compat concerns. Feedback welcome.
Tracking bug
Link to entry on the Chrome Platform Status
Mike West
--
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/DM5PR00MB0423AC2E11235DC743952FEFF4149%40DM5PR00MB0423.namprd00.prod.outlook.com.
Yoav Weiss
Summary
Updates the version provided via the Sec-CH-UA-Platform-Version on Windows to provide a reasonable level of fidelity to allow sites to identify meaningful Windows platform changes. This aligns with the current definition in the proposal in the UA Client Hints WICG repo.
This enables sites to deliver appropriate binary executables and help content specific to that OS version.
Blink component
Motivation
This enables sites to deliver appropriate binary executables and help content specific to that OS version. The current UA string and existing Sec-CH-UA-Platform-Version implementation provides the "major" and "minor" version Windows components. However, as of Windows 10, Windows generally doesn't increase either of these numbers across significant releases. Notably, Windows 11 does not increase either of these numbers.
The updated UA Client Hints proposal text specifies that the value on Windows should instead be derived based on the Windows.Foundation.UniversalApiContract version. This version revises when the set of APIs exposed on Windows changes in a significant way while not being particularly identifying (e.g. a typical security update will not revise it).
A table of value mappings to Windows releases can be seen in the UA Client Hints' repo issue 220.
TAG review
Recent updates to the proposal are being discussed in w3ctag/design-reviews#640. This doesn't change the fundamental contract, so an additional, separate TAG review is likely unnecessary. Feedback welcome.
TAG review status
Pending
Risks
Interoperability and Compatibility
Sites may already be depending on the existing version being returned. Sites moving from the UA string to the header may also erroneously assume the version scheme will be the same as what is in the UA string today.
However, the UA string has not yet been frozen and it's unlikely sites have hard dependencies on the current value since it has to this point been exposing the same Windows OS version info as the UA string.
Gecko: No signal for this specific change. A broader signal on UA Client Hints in general is tracked via other intents.
WebKit: No signal for this specific change. A broader signal on UA Client Hints in general is tracked via other intents.
Web developers: Positive
Erik Anderson
Re: Windows 8—
Yes, it would report "0.0.0" (as would Win7). When discussing this in the WICG repo, my thinking was that it would be reasonable to say that the NT version prior to Win10 should not be frozen in the UA string for folks that need to detect on that. After support is dropped for those older versions, then it would be effectively frozen.
We could consider using the second version part to encode Win7 vs. Win8 vs. Win8.1 if desired (e.g., 0.1.0, 0.2.0, 0.3.0 respectively), but general feedback from the Windows team has been that they have seen too much pain and suffering from multi-part version checks and would like to stick with a single value moving forward.
Re: the “Positive” web developer sentiment—
This is based primarily on talking to Microsoft developers focused on lighting up help content and installer logic to target Windows 11. Anything that solves that use case was seen as a positive to them. I’m sure many would be fine with exposing the third version part of the Windows version instead as well, but we felt that has two downsides: (1) it’s harder to write version checks correctly and (2) it exposes more entropy than the less-frequently-increasing UniversalApiContract version (this is most impactful to users of Windows Insider builds). I agree there will be a learning curve for developers if they want a human-readable mapping of version values to Windows marketing names.
Re: a Use Counter—
I believe https://www.chromestatus.com/metrics/feature/timeline/popularity/3273 is tracking this. It currently shows 0.115% starting in May (before that it was ~0%). I’ve seen some evidence of sites starting to request various Client Hints values in bulk, so it’s unclear how much of the new usage is currently doing anything that maps to a server- or -client-side decision vs. speculatively starting to collect in preparation for if/when the UA string freeze goes through.
The Edge team will closely watch for any reports of issues that appear to be tied to this (if any breakage is to be found, it would likely be on pre-Win10 and older Win10 releases where the value would become lower than what’s currently reported).
Erik Anderson
> Is there a way to quantify how identifying the proposed change is? For example, a histogram or distribution of counters for the various values of Windows.Foundation.UniversalApiContract?
https://github.com/WICG/ua-client-hints/issues/220#issuecomment-870858413 has a table calling that describes how the versions map to existing Windows OS versions. The relative uniqueness of each value depends on the current population for each OS+browser combination. Either way, this approach is less identifying than exposing the third version component “build” since the UniversalApiContract version changes less frequently.
Per https://chromium-review.googlesource.com/c/chromium/src/+/2458328, Chrome has a “Windows.WindowsVersion” histogram. I don’t know what the distribution looks like for Chrome nor do I know of any information to that effect that Microsoft shares publicly. Windows 10 releases typically have a reasonably fast uptake, but users can choose to remain on older ones until at least the retirement date (dates are available for the various releases via https://docs.microsoft.com/en-us/lifecycle/products/?products=windows).
Matt Menke
Erik Anderson
The primary goal of the spec update was to make the desired behavior on Windows (as discussed in issue 220) be clearly specified.
However, since the existing spec didn’t document the expected version sources for any platform, I went broader and further defined the behavior based on Chromium’s current implementation (except for Windows, where it’s now defined differently than Chromium’s current implementation). The goal is that future implementers can achieve interop across all of the relevant platforms.
It would have been clearer to land two different commits (“define version source and format for all platforms based on Chromium’s implementation” and a second “change version source for Windows”), but since the starting point was “version source not explicitly specified,” I opted for landing a single change for the desired end state. I understand how looking at the one commit can be confusing—sorry about that!
Matt Menke
Chris Harrelson
--
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/CAEK7mvorWX1LU6CexH-y%3DxYH8PYXuPPgKz3xQ41UFfAiNvhVRQ%40mail.gmail.com.
Daniel Bratell
LGTM3
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-e-cd%3DN354stMq6yb5uy2nHUjrek7_e8p8vEtTpuHOfg%40mail.gmail.com.