On Windows, platform version string should be sufficient to differentiate between the various Win10+ releases

[erik-anderson]

Windows historically updated the major or minor version number with each significant OS release. As a result, the "Windows NT ." component of the UA string was sufficient for sites to know how to send appropriate installers targeting each OS release.

As of Windows 10, though, Windows has essentially frozen the major and minor build number. As a result, this logic is no longer able to work across different Win10 releases even as we approach the 6th anniversary of the first Win10 release.

For OS X, we're already exposing a similar level of detail in terms of version numbers across releases.

With the UA string, it would have been unsafe from a compat perspective to add a third version component since it would have broken many existing UA string parsers. With UA Client Hints, we have an opportunity to add this functionality back.

There's obviously a bit more entropy here, but this version component has only been changing about twice a year and with the Windows install base it's not particularly unique. Since this isn't a header included by default, we can also consider it as an input into any future "privacy budget" schemes.

So, in short: I think we should have browsers expose major.minor.build in Sec-CH-UA-Platform-Version on Windows clients. e.g. instead of "10.0" it would say something like "10.0.19042" (for "20H2").

This is possibly not really an issue to resolve here on the spec, but if we have general agreement we could at have at least one of the examples demonstrate this.

[erik-anderson]

I should also note that there are concerns along the lines of #209 where we know Win32 developers have gotten these version checks wrong all the time.

Perhaps we should be trying to solve the "comparing version numbers" challenges for both the browser and version the UA platform version hints as part of this.

[miketaylr]

So, in short: I think we should have browsers expose major.minor.build in Sec-CH-UA-Platform-Version on Windows clients. e.g. instead of "10.0" it would say something like "10.0.19042" (for "20H2").

I think as written, this is already a valid value (but I guess Chromium's implementation doesn't do it?). Adding some clarifying examples to https://wicg.github.io/ua-client-hints/#examples makes sense -- would you like to send in a PR for that @erik-anderson? Otherwise I should be able to get to it eventually. :)

[erik-anderson]

Right, Chromium currently does "10.0". I can create PRs for both UA Client Hints and Chromium if we have general agreement.

Talking with some Windows folks, they're apprehensive about all of the ways folks can mess up version checks (e.g. the issue described in #209), so I'd like to talk through that a little bit more before proceeding with something here.

[miketaylr]

SGTM, I agree we need to figure out #209 and #196 (hoping to be able to dedicate time to that soon).

[miketaylr]

Just ran into https://bugs.chromium.org/p/chromium/issues/detail?id=664622, where Chromium tried to add build info to the Windows UA string but it was backed out due to site compat concerns. Something to consider if we think sites are going to try to re-use their parsing code in a UA-CH world. Or perhaps it's safer now given the new API surface.

[erik-anderson]

The challenge with that Chromium issue was that the Windows OS version was exposed as two components for many, many years and folks had brittle checks based on it, e.g. a regex that checks for a leading space, a number, a period, a number, and a trailing semicolon).

We don't (yet) carry that legacy baggage with the new value. Even an existing regex like that wouldn't work as-is, so we presumably have some window of time where no one significant has moved over to the client hints variant yet and would test before using it. But I do agree there is more risk the later we make changes of this nature.

[erik-anderson]

@miketaylr I've been consulting with Windows OS app compat and platform owners about how to design this in the most resilient way possible on Windows.

The feedback I've received is that the multi-part version handling has traditionally led to compat issues on Win32 apps in cases where their logic didn't actually handle a different version part changing (e.g. someone wanting "at least 6.1" might code it as "major at least 6 and minor at least 1" and then break when it goes to 10.0).

As of Windows 10, the now-recommended way of checking that the platform will be able to support the application's API needs is based on API contracts. Every significant release of Windows increases the Windows.Foundation.UniversalApiContract version (see https://blogs.windows.com/windowsdeveloper/2015/09/15/dynamically-detecting-features-with-api-contracts-10-by-10/). Having version checks be based on this UInt32-based version will be the most resilient approach.

As a result, my revised proposal is:

• Change the Sec-CH-Platform-Version on Windows to report the Universal API Contract version instead of the major.minor version.
• The first release of Windows 10 (a.k.a. 1507 a.k.a. "Threshold 1") was API contract version 1. Since we need to do something meaningful for Win7 and Win8/8.1, I propose we report 0 on pre-Win10 OSes and sites can continue to look at the major.minor version in the UA string itself. The UA freeze effort would ideally not touch the major/minor version on Win7/8/8.1 but could be frozen moving forward.

This will make parsing and comparisons on Windows super simple and straightforward.

Also note that with Windows 11, it does not currently increase the Windows major version number (similar to Win7 which was still major version 6). As a result, there's a bit more urgency here to get a solution in for sites hosting app installers that may want to target Windows 11 specifically.

[miketaylr]

• Change the Sec-CH-Platform-Version on Windows to report the Universal API Contract version instead of the major.minor version.

I think it makes sense to follow current Windows idioms.

Do I follow correctly that the versions would be: 0 (for Win 7/8),1 (Win 10), 2 (some version of Win 11), etc.?
(Side note: when I try to follow the links from the blog post, it takes me to a parked domain -- seems like a URL shortener expired: http://wndw.ms/qmvoUY)

[erik-anderson]

• Change the Sec-CH-Platform-Version on Windows to report the Universal API Contract version instead of the major.minor version.

I think it makes sense to follow current Windows idioms.

Do I follow correctly that the versions would be: 0 (for Win 7/8),1 (Win 10), 2 (some version of Win 11), etc.?

Yes, we'd report 0 for Win7/8/8.1.

If we look at Wikipedia's Windows 10 version history page, I believe this should be what will get reported on each version (note that some of the releases of Win10 did not revise the UniversalApiContract version and from an app installer perspective we would not expect them to have a specific API dependency on those releases beyond the earlier version with that Windows.Foundation.UniversalApiContract version:

Version	UniversalAPIContract version
Win7/8/8.1	0
Win10 1507	1
Win10 1511	2
Win10 1607	3
Win10 1703	4
Win10 1709	5
Win10 1803	6
Win10 1809	7
Win10 1903	8
Win10 1909	8
Win10 2004	10
Win10 20H2	10
Win10 21H1	10
Win11	13+

Windows 11 is 13+ because, as Windows modifies the API surface, the contract version will continue to get incremented. The general availability (GA) version of Windows 11, for instance, is a value higher than the pre-GA versions which were version 13.

[miketaylr]

Got it -- this proposal sounds good to me. Would you like to send in a PR for the spec changes related to this? Right now it's a pretty hand wavey "information about the platform version on which a given user agent is executing."

[erik-anderson]

Sure. See the PR I just created. I went ahead and more fully specified things for other platforms as well.