Enable WebAuthn Support

[jonaharagon]

I think this issue is being tracked upstream at https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/26614, but I want to make sure this is being tracked here to see if Mullvad Browser can diverge from Tor Browser in this regard. I think this is a really strange reason for Tor Project to hold back WebAuthn support anyways, unless they have some secret reason WebAuthn isn't good that I can't find in any of their discussions.

Enabling security.webauth.webauthn seems to be the only thing needed to get this feature working, but I don't know what the fingerprinting implications are of enabling it by default? (obviously enabling it manually on the user-level would make the browser unique and would therefore be discouraged).

I think this is a pretty major usability issue, especially given how heavily hardware keys are encouraged for what I think is the primary demographic of this browser.

I also think the lack of Passkey (CTAP 2.0) support is an even bigger usability issue, but there might be less you can do about that until Firefox adds support for it.

[ruihildt]

I think this is a really strange reason for Tor Project to hold back WebAuthn support anyways, unless they have some secret reason WebAuthn isn't good that I can't find in any of their discussions.

Any browser API needs to be reviewed before getting added to Tor (Mullvad) Browser. Now I haven't checked (and I will), but I assume this is just the case of it not being a priority, due to the time/resources available to the Tor Browser developer's team.

This is a very boring and unfortunate reason, hopefully we can fix it sooner than later.

[ruihildt]

I have been trying out your new browser, but have encountered an issue where I'm unable to use my Yubikey with WebAuth for any service that I have enabled it with. I don't have this issue with any other browser, so I assume that you have disabled the feature on purpose. This seems like an odd decision when considering how important security feature we are talking about, and the fact that you have yourself just launched your own security key, so it doesn't really make any sense to me. However, as I really need this feature to work, is there some setting that I could go change in about:config or is that not possible?

[jswinner]

Yes, @jonaharagon gave it: Enabling security.webauth.webauthn seems to be the only thing needed to get this feature working, but I don't know what the fingerprinting implications are of enabling it by default? (obviously enabling it manually on the user-level would make the browser unique and would therefore be discouraged)._

[mattdale77]

Could it be enabled on an exception basis by domain? Giving the default as tight as possible bit allowing users to relax this for specific sites in the browser so they can maintain high security on their accounts.

[jonaharagon]

Not that I'm aware of, and even if there was it sounds like Mullvad Browser is having issues with saving per-site exceptions where that is normally supported #29.

Maybe we'll eventually get this in the ESR 115 release, or when Tillitis actually supports FIDO2 🙃

[felschr]

Just to make this entirely clear: Enabling security.webauth.webauthn manually is indeed fingerprintable: If it's enabled navigator.credentials (and some classes on window) will be set which are otherwise undefined.

The 2 main WebAuthn API functions are navigator.credentials.create() & navigator.credentials.get(). It appears that both functions return null if no credential was created/retrieved, which should be the case if the user cancels or closes the WebAuthn popup or if the action otherwise fails: https://developer.mozilla.org/en-US/docs/Web/API/CredentialsContainer/create#return_value_2 https://developer.mozilla.org/en-US/docs/Web/API/CredentialsContainer/get#return_value

As long as the user doesn't actually use security key on a website, I think WebAuthn would not make them fingerprintable if Mullvad Browser were to enable WebAuthn by default. Website which the user uses WebAuthn with are likely more trusted. Still, the WebAuthn popups should be adjusted to include a warning to make that clear (similar to the Canvas warning).

I guess it's too late to potentially get this into Mullvad Browser 13.0?

[Thorin-Oakenpants]

I guess it's too late to potentially get this into Mullvad Browser 13.0

for the watershed .. but the 13 (and 13.5) cycle lasts a whole year :)

[ruihildt]

I guess it's too late to potentially get this into Mullvad Browser 13.0?

Indeed it has been pushed back to a later version, as the migration to Firefox 115 ESR was prioritized.

[felschr]

Apparently Passkeys are now the default sign-in method for Google accounts: https://blog.google/technology/safety-security/passkeys-default-google-accounts/

[kennedy]

I like mullvad browser, gave it a solid full-time 2-3 weeks between my mac and windows machine. I've enabled passkeys on pretty much all supported web services I have an account with. Having passkeys/WebAuth fully supported would be a great quality of life experience.

[felschr]

The latest update of the Bitwarden browser extension introduces support for Passkeys, which does not seem to properly work in Mullvad Browser, though. It's probably related to the lack of WebAuthn support, since it works fine for me on Firefox (with arkenfox settings). Most (all?) websites I've tested will show the option to log in with a Passkey and Bitwarden's popup also opens up and shows matching Passkeys for the website. When selecting a Passkey, though, the website will usually show an error or just won't log you in. On GitHub I'm seeing the following error in the developer console:

Uncaught (in promise) ReferenceError: AuthenticatorAssertionResponse is not defined

On ebay & Nintento I don't see an error in the console at all, but they show an error in the UI.

Also, using the new extension version will change the browser fingerprint, as I've mentioned in https://github.com/mullvad/mullvad-browser/issues/74#issuecomment-1806442479.