Intent to Prototype and Ship: New UA platform version source on Windows for User-Agent Client Hints

176 views
Skip to first unread message

Erik Anderson

unread,
Jul 13, 2021, 2:25:44 PMJul 13
to blin...@chromium.org, Eric Lawrence, mike...@chromium.org

Contact emails

elaw...@chromium.org, Erik.A...@microsoft.com

 

Explainer

WICG/ua-client-hints@5c1be87

 

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

Privacy

 

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

https://crbug.com/1226130

 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5080939765956608

Mike West

unread,
Jul 15, 2021, 4:44:46 AMJul 15
to Erik Anderson, blin...@chromium.org, Eric Lawrence, mike...@chromium.org
This doesn't fundamentally change the web-facing behavior, insofar as the version information must still be requested, and is in the same numerical format as it was before. With that in mind, I agree that a TAG review is unlikely to be useful on this point in particular, nor will other vendors' signals for this particular change likely differ from their signals on the underlying feature itself. I'm not sure I buy the "Positive" web developer response that you're asserting for this particular feature for the same reasons. But, it seems reasonable to me that Microsoft is going to do a pretty good job representing the way Windows expects its version to be represented, and it seems that the spec's editors agree.

LGTM1.

-mike


--
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

unread,
Jul 15, 2021, 5:48:59 AMJul 15
to blink-dev, Erik Anderson, Eric Lawrence, Mike Taylor
On Tuesday, July 13, 2021 at 8:25:44 PM UTC+2 Erik Anderson wrote:

Looking at https://wicg.github.io/ua-client-hints/#sec-ch-ua-platform-version, I read it as saying that for Windows 8, Sec-CH-UA-Platform-Version would be "0.0.0". Is that correct?

 

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

Privacy

 

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.

Looking at the mapping, I suspect this is something that developers may find surprising. 

 

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.


Do we have use counters related to current usage of Platform-Version?
 

 

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


Link? 

Erik Anderson

unread,
Jul 15, 2021, 12:59:46 PMJul 15
to yoav...@chromium.org, blin...@chromium.org, Eric Lawrence, mike...@chromium.org

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

unread,
Jul 15, 2021, 2:50:13 PMJul 15
to abe...@chromium.org, blin...@chromium.org, Eric Lawrence, mike...@chromium.org

> 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

unread,
Jul 16, 2021, 2:27:38 PMJul 16
to blink-dev, Erik Anderson, Eric Lawrence, mike...@chromium.org
I'm a bit confused on what exactly is being changed here.  The linked spec change seems to go from no specified behavior on any platform to some specified behavior on all platforms, while the summary claims just the version being returned by Windows is changed.  Am I missing something?

Erik Anderson

unread,
Jul 16, 2021, 2:47:14 PMJul 16
to mme...@google.com, blin...@chromium.org, Eric Lawrence, mike...@chromium.org

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

unread,
Jul 16, 2021, 2:49:40 PMJul 16
to Erik Anderson, blin...@chromium.org, Eric Lawrence, mike...@chromium.org
Thanks for the link!  That makes it much clearer what's going on.

Chris Harrelson

unread,
Jul 19, 2021, 4:10:36 PMJul 19
to Matt Menke, Erik Anderson, blin...@chromium.org, Eric Lawrence, mike...@chromium.org
LGTM2

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

Daniel Bratell

unread,
Jul 22, 2021, 2:28:21 PMJul 22
to Chris Harrelson, Matt Menke, Erik Anderson, blin...@chromium.org, Eric Lawrence, mike...@chromium.org
Reply all
Reply to author
Forward
0 new messages