Open ruihildt opened 1 year ago
Would you consider implementing the Bitwarden password manager, natively into your browser? I know you can install it manually.
Bitwarden or KeepassXC would be good idea. +1 for this.
I'm using the Bitwarden extension (Linux) without any issue, but it would be preferable from the point of fingerprinting if this was included with the browser, or that Mullvad worked with the Bitwarden App (This is a Bitwarden issue I would assume). Not a big deal but it would be a nice addition.
Proton Pass will be open-source, work completely stand-alone in the browser as extension, and is European like Mullvad. But instead of bundling something from one specific company it might be better to just give some examples or link to an informative blog post about the topic.
I can confirm as a Windows 10 user, that Bitwarden has no problems running (installed from Firefox extensions site).
EDIT: No longer an issue on macOS, but still for windows.
1Password has not vetted the mullvad browser, blocking the browser extension from connecting to host 1password app.
To temporarily override the restriction, in the 1Password App -> Settings -> Labs, enable "Enable custom browser support". Then go to 1Password App -> Settings -> Browser, add mullvad browser.
This will allow the extension to communicate.
bump. I would like to petition further research for 1password support.
Compared to firefox, 1password's extension establishes communication with the host computer's 1password application. On macOS/windows, it would allow users to unlock the extension with onboard bio-metrics.
Currently, 1password's extension on mullvad can not communicate with host computer's 1password application. Not being able to unlock my password manager easily with bio-metrics with the browsing session oftenly resetting, makes using mullvad fatiguing.
I can definitely appreciate the security stance, but I have enabled allowed remember browsing history to reduce the amount of re-logging in I have to do. But purely allowing bio-metric unlocking would provide great quality of life improvement.
The latest update of the Bitwarden browser extension introduces support for Passkeys.
The way it's implemented is basically a polyfill for WebAuthn. Specifically it sets navigator.credentials
, which otherwise doesn't exist in Mullvad Browser due to it's lack of WebAuthn support (see #53).
I haven't looked much into other areas of the Bitwarden extension. It might've already been fingerprintable, but my guess is that it would only be fingerprintable when it render some UI elements on the website, e.g. the bar on the top that asks whether the user wants to save/update the password they just used to register/login somewhere. If that's the case, that would be less of a concern since these websites are more trusted. The new passkey support changes the fingerprint even without actively using Bitwarden in some manner, though, so it's a bigger concern.
Anyway, Bitwarden's Passkey support doesn't even properly work in Mullvad Browser, likely due to missing WebAuthn support (#53), and there doesn't seem to be a way to disable Passkey support in the extension.
@felschr I don't have a bitwarden account (and not going to set one up), but I added the ext (and allowed in pb mode) in MB and AFAICT it doesn't modify the fingerprint (edit: on all sites)
You can also test the navigator object: anything reported after constructor
is a dead giveaway - e.g. in the console you can type
console.log(Object.keys(Object.getOwnPropertyDescriptors(Navigator.prototype)))
So even if the API was enabled for all MB users, navigator.credentials would still be revealed as tampered with
If this is only exposed on sites with saved passwords, then it's not a super viable tracking feature - that's not to say it can't be used to link accounts
Anyway, Bitwarden's Passkey support doesn't even properly work in Mullvad Browser, likely due to missing WebAuthn support
passkeys aren't supported in ESR115
rui: so to check navigator.credentials
is altered on all sites or only on those which you have a saved password, and maybe it is only on the login page (IDK) you would just type navigator.credentials
into the console and hit enter
TB.MB should be undefined
If it's modified you will get (something) like
TB.MB should be undefined
It is not undefined with the extensions being just installed, without even login in.
Next question is, is it the same navigator.credentials
as the default one when the Firefox integrated password manager is enabled?
IDK. If the API is enabled, bitwarden might use that and then it should/could be the same - but if it's a polyfill then no
try
All
cred
(uncheck whole words)I see 4 in FF with the API
Credential: 18fc7e88 (3)
[
id, type, constructor
] CredentialsContainer: b4c4ab89 (5)
[
get, create, store, preventSilentAccess, constructor
]
IdentityCredential: 6e5ee7aa (2)
[
token, constructor
]
PublicKeyCredential: d98065ba (6)
[
getClientExtensionResults, toJSON, rawId, response, authenticatorAttachment, constructor
]
on MB without the API I see
Credential: 18fc7e88 (3)
CredentialsContainer: b4c4ab89 (5)
so I think the last two IdentityCredential
and PublicKeyCredentia
are what matters
of course this isn't a super deep dive. If you use TZP you could do a summary or full FP compare (copy the JSONs in the popup overlays and do a diff) to see what pops out (and TZP is a WiP, there's a lot more that we could do to expose prototype lies from extensions)
I am not able to use the 1Password extension with Mullvad Browser on macOS, even with the "Enable custom browser support" setting enabled. It shows the following error:
Can’t store local data
You'll need to turn off "Never remember history" and "Always use private browsing mode" to use 1Password."
However, the passff extension works as expected, so as a workaround I've been mirroring select items from 1Password locally using pass
:
op read://Personal/<itemid>/password' | pass insert -e mullvad/site/username
Note: The system wide autofill feature with 1Password (Command-\) does work with the above setting enabled, just not the browser extension.
Hi everyone!
I'd like to add that, when it comes to Passkeys and Bitwarden, the fingerprinting is actually quite straightforward on the current version. This is because the fido2 script gets injected into every page using the unique UUID of the extension's install. For example:
<script src="moz-extension://89a2c3a2-eea9-413c-802a-7b07f764aa2a/content/fido2-page-script.js" type="text/plain">
The only way to avoid this would be to disable Passkey support manually, which can be done by going to Settings > Notifications > Ask to save and use passkeys
and unchecking the option.
unless I'm missing something ... the extension id exposed to web-content in gecko is randomized per profile (technically per install)
Yes, as far as I saw too, the extension's UUID is unique per install and hence my concern. Rather than (or on top of) the usual fingerptinting techniques, the websites could just grab the Bitwarden's UUID and recognize the visits of that specific user. I see it like browsing the Internet by advertising to each page an identifier that is unique to you.
Sorry, not with it today. So right ... a listener should be able to grab this info? (my brain is overheated from too much work)
Where's the issues at these extension's repos/sites? Where is the uproar, because it's very serious if true? By that I mean it's sooooo bad (and amateur and these perps have been build web extensions for a long time, around security/privacy) it surely can't be right. IDK, just asking
I can confirm Bitwarden extension Internal UUID is injected in the DOM to load the script.