User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18324

Steps to reproduce:

We(Microsoft) released a feature(webuathn) in latest windows release. That is not applicable to older windows 10 releases or earlier windows releases for that matter.

We worked with Firefox to integrate webauthn feature with firefox which works for all the scenarios on latest windows builds.

However, for an RP who wants to enable the feature on firefox, there is no way to distinguish between older windows 10 releases and newer windows 10 releases.

We were looking at user agent string to figure this out.

Issue is that the minor version of windows 10 is the same for all the windows 10 releases for many years now. So every windows 10 release has the same major version and minor version.

One way to solve this is to add build number to the user agent string. Otherwise there is no way we can enable firefox for this feature from the RP's side.

Actual results:

Not able to distinguish between various windows 10 releases which is required to figure out where webauthn feature works with windows native APIs and where it doesn't.

Expected results:

Hoping that user agent can include build number also.

https://bugzilla.mozilla.org/show_bug.cgi?id=1508115 is where firefox integrated with native windows webauthn APIs.

This would be a change to https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsHttpHandler.cpp#1039 so marking for Core::Networking::HTTP.

There's obviously a fingerprinting issue here, but we already increment for OSX and Linux versions. Exact build numbers for Windows will be a strong identifier for Windows Insider builds, but that's pretty much unavoidable.

Perhaps we could take info.dwBuildNumber and take it modulus 100?

(In reply to J.C. Jones [:jcj] (he/him) from comment #2)

Perhaps we could take info.dwBuildNumber and take it modulus 100?

Upon further reflection[1], it'd be better to take info.dwBuildNumber / 1000 * 1000 and have build numbers like 16000, 17000, and 18000. That makes the UA for Windows 10 broadly similar to that of macOS.

An alternative to this would be to add a new fragmentation surface to PublicKeyCredential like PublicKeyCredential.isMicrosoftHelloEnabled. I don't like that because :

1. UA is already a known fingerprinting surface, and there exist tools for privacy-focused users to fudge it. A new attribute would be new surface, without tools.
2. UA is used by websites to differentiate experiences already.
3. Something like PublicKeyCredential.isMicrosoftHelloEnabled really should be standardized between browsers, and the WebAuthn WG rejected such platform-inspection fingerprinting.

[1] https://en.wikipedia.org/wiki/Windows_10_version_history

Issue is not really with whether windows hello is enabled or not. RP can distinguish that with PublicKeyCredential.IsUserVerifyingPlatformAuthenticatorAvailable API. Issue is that with external security keys FIDO2 support. With this integration, FIDO2 security keys with all PIN/built in user verification support is enabled on latest 19H1 builds but same functionality is not there for non 19H1 builds on Windows.

Alternatively, if we have an API which says PublicKeyCredential.IsExternalFIDO2SecurityKeysSupported, we may have a solution. For 19H1, it will return true and for older 19H1 it will return false for now (till firefox has support for external FIDO2 keys and then you can turn that to true).

Having said that support for FIDO2 keys is a broad definition and probably a Boolean is not the right detail. Build numbers is the best solution, IMO, at the moment.

Also, getting new capabilities support approved in newer version of webauthn will take years. Hence, I would request to allow getting us build numbers (in some obfuscated manner).

Moving to Core:DOM based on comment 3. I don't think we want to add more stuff to UA, but that is definitely for a broader discussion. Some more folks added.

Note that putting the information in the UA string is a source of passive fingerprinting data, whereas having it available via a Web API is only a source of active fingerprinting data, which is not as big a deal.

We normally try to expose what capabilities are available through web APIs, whereas we tend to try avoiding adding new information to the UA string. So if it's sufficient, it seems preferable in this case to expose the information through an API available via JavaScript rather than in the UA string. (If it's needed at the HTTP level, Client-Hints might be a better longer-run solution to that.)

So the preference would be a non-standard PublicKeyCredential.IsExternalFIDO2SecurityKeySupported attribute?

We support CTAP2 devices on one specific platform, making it hard for RPs to
decide whether or not Firefox will support the tokens they're asking for. This
adds a non-standard method to divine that information while Firefox moves toward
CTAP2 support.

https://hg.mozilla.org/mozilla-central/rev/d805110bf631

Comment on attachment 9043959 [details]
Bug 1526023 - Web Authentication - add isExternalCTAP2SecurityKeySupported

Beta/Release Uplift Approval Request

• Feature/Bug causing the regression: Bug 1508115
• User impact if declined: WebAuthn in Firefox 66 won't be usable with Microsoft Accounts, requiring a wait for 67.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce: From a console, ensure
  await PublicKeyCredential.isExternalCTAP2SecurityKeySupported()
  returns false on all platforms except Windows 10 Insider builds.

It's low risk, I don't think we need to verify that with QE.

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This adds a small function that has almost no coupling to anything else, and it has a test.
• String changes made/needed: None

Comment on attachment 9043959 [details]
Bug 1526023 - Web Authentication - add isExternalCTAP2SecurityKeySupported

Fix for auth issues with new Windows versions.
Adds new tests. OK for beta 13 uplift.

Akshay, can you verify this works for you some time mid-next week (once we release beta 13?) Thanks!

https://hg.mozilla.org/releases/mozilla-beta/rev/ff2c3fd26b15

It also seems like it's worth bringing this use case to the working group to get a solution standardized.

Working group closed it no-action, saying that Firefox's implementation of this solves the problem. Other user agents expect to roll-out FIDO2 support across all platforms simultaneously, rather than piecemeal like we must.

https://github.com/w3c/webauthn/issues/1173

Yes, this works for me.