Chrome Conditional UI: isConditional MediationAvailable() Returns True on Windows 10

1. Introduction#

At Corbado, we continuously try to provide the best passkey-first solution for every device and browser. One of the significant hurdles for wide passkey adoption has been navigating the heterogeneous system of Windows 10 versions and features. Windows 10 presents unique challenges for passkey implementation, mainly due to its lack of a Trusted Platform Module (TPM) requirement and missing upgrades for Windows Hello that Windows 11 got. This diversity in the operating system's architecture and capabilities means that not all Windows 10 devices are passkey-ready or do not support all passkey features, particularly Conditional UI. In fact, as of March 2024, Windows in general only supports single-device passkeys (which are not synced e.g. via a Windows / Microsoft account).

When testing on a Windows 10 device, we recently made a suprising discovery. Unlike our previous experiences, this particular device, equipped with Chrome 123, indicated through the PublicKeyCredential. isConditionalMediationAvailable() check that it was, surprisingly, Conditional-UI-ready. This unexpected finding sparked our interest and led us into a deeper investigation.

After reaching out to a developer from the Chromium team, we gained new insights that we want to share with others in this blog post.

2. Discovery: All Windows 10 Devices with Chrome Show Conditional UI Readiness#

Our test device:

• Was running on Windows 10
• Has no Bluetooth support
• Could create passkeys (single-device passkeys) before but did not support conditional UI
• Now, it displayed Conditional UI support

Our interest deepened upon noticing this behavior was not isolated to Chrome. When we extended our observations to Firefox, the same unexpected readiness for Conditional UI was apparent, suggesting a pattern that noticeable across browsers. This broader consistency hinted at an underlying change in the Windows 10 operating system itself, rather than browser-specific updates or modifications.

To uncover the root of this change, we started to review the recent changelogs for both Windows and the browsers in question. Despite our examination, we found no direct references to significant changes that could explain the newfound Conditional UI support.

We then started to analyze the webauthn.dll file, the library for WebAuthn in Windows 10. An update to this file in mid- February caught our eye, which was a cumulative update for the .NET framework. The webauthn.dll is important for developers working on integrating secure user authentication methods, as it provides the necessary functions to interact with authenticators and manage credentials. The update to this file was a potential reason in understanding the sudden emergence of Conditional UI support on Windows 10. A change in the webauthn.dll would have been very surprising due to Windows 10 getting only security updates and is not receiving new feature updates.

3. WebAuthn API Versions in Windows Have not Changed#

The webauthn.dll contain the WebAuthNGetPlatformCredentialList entry. Moreover, various WebAuthn API versions (WEBAUTHN_API_VERSION_X, where X stands for the version number) are defined, each version introducing new data structures, their subversions and extensions. Specifically, WEBAUTHN_API_VERSION_7 marks a significant leap forward, introducing new data structures such as WEBAUTHN_AUTHENTICATOR_MAKE_ CREDENTIAL_OPTIONS and WEBAUTHN_AUTHENTICATOR_GET_ ASSERTION_OPTION S, both introduced in version 7, alongside WEBAUTHN_CREDENTIAL_ATTESTATION (version 6) and WEBAUTHN_ASSERTION (version 5). These structures are foundational for the conditional UI capabilities.

Moreover, as of WEBAUTHN_API_VERSION_4 , the API provided essential functions like WebAuthNGetPlatformCredentialList , WebAuthNFreePlatformCredentialList , and WebAuthNDeletePlatformCredential , which are integral for managing credentials on the platform and, by extension, critical for enabling or enhancing conditional UI support as they allowed to silently discover credentials on the authenticator.

Chrome's approach to determining conditional UI availability is tied to the WebAuthn API version supported by the underlying operating system. The browser conducts a silent check for a specific WebAuthn API version, using this information to decide whether conditional UI features can be enabled. This process, however, revealed an anomaly: our testing showed that Chrome was indicating conditional UI readiness on Windows 10 devices that, according to their WebAuthn API version, should not support these features.

This discrepancy led us to reach out to the Chromium developer team for insights. The team's response revealed something interesting, as in one of the latest Chromium version passkey metadata from Android phones is synced to Chrome desktops. This functionality allows Chrome to autofill passkeys for websites if the user has enabled sync on their desktop and has a corresponding passkey on their Android phone:

To protect user privacy and prevent websites from detecting whether this sync is enabled, Chrome now always returns true for the PublicKeyCredential. isConditionalMediationAvailable() call, regardless of the actual WebAuthn API version on the device.

4. Implications of Chromiums New Behavior#

The revelation from the Chromium team has implications for developers and product managers. As the UX might be improved due to the synchronization of passkey metadata between mobile and desktop environments, the usage of PublicKeyCredential. isConditionalMediationAvailable() does not provide valid results anymore (for now). Determining the true conditional UI readiness of a device based solely on its WebAuthn API version number is not possible anymore.

5. Conclusion#

In summary, the technical exploration into the updated webauthn.dll file and the interactions with the Chromium developer team shed light on the evolving landscape of web authentication. It highlights the innovative approaches being adopted to streamline user experiences across platforms while also pointing to the need for developers to stay informed about these changes to effectively implement and leverage the full potential of passkeys and conditional UI.

Frequently Asked Questions#

Why does Chrome's isConditionalMediationAvailable() return true on Windows 10 devices that don't actually support Conditional UI?#

Chrome always returns true for isConditionalMediationAvailable() to prevent websites from detecting whether a user has Android passkey metadata sync enabled on their desktop. This is a deliberate privacy protection introduced alongside Chrome's new feature that syncs passkey metadata from Android phones to Chrome desktops. The return value no longer reflects the device's actual WebAuthn API version or native Conditional UI capability.

How does Chrome's Android-to-desktop passkey metadata sync work and what does it enable?#

In recent Chromium versions, passkey metadata from a user's Android phone is synced to their Chrome desktop when Chrome sync is enabled. This allows Chrome to autofill passkeys for websites where the user has a corresponding passkey stored on their Android device. This sync operates independently of the Windows platform's WebAuthn API version or native Conditional UI support.

Can I still use isConditionalMediationAvailable() to determine whether a Windows device natively supports Conditional UI?#

No. Following Chromium's change, isConditionalMediationAvailable() always returns true and can no longer be used to verify a device's native Conditional UI readiness based on its underlying WebAuthn API version. Developers need alternative approaches to determine true platform-level Conditional UI support on Windows 10 devices.

What is the difference between Windows 10 and Windows 11 in terms of passkey feature support?#

Windows 10 lacks a Trusted Platform Module (TPM) requirement and did not receive the Windows Hello upgrades that Windows 11 introduced, meaning not all Windows 10 devices support all passkey features including Conditional UI. As of March 2024, Windows in general only supports single-device passkeys that are not synced via a Windows or Microsoft account. Windows 11 received additional platform-level updates that improve overall passkey readiness.