How secure is the Mullvad Browser, because Privacy ≠ Security

Yes, but they don’t know when.

GrapheneOS posted on Mastodon regarding (also) Mullvad Browser:

“These do not have robust solutions for fingerprinting with JS enabled at all and have very poor security.”

Source: GrapheneOS: "@Life_is_Beautiful@infosec.exchange > They have…" - GrapheneOS Mastodon

I said it before and I’ll say it again: You can have good security with bad privacy, but you can’t have good privacy with bad security.

1 Like

The poor security mainly stems from being based on firefox (an inheriting their issues), being dependent of tor network (with anonymous tor nodes that nation states can infiltrate), and breaking the user group into parts with their safe, safer, safest settings (and being a monoculture of interesting targets).

GrapheneOS criticisms stem from foundational issues with tor network and browsers, not something specific to MB or TB. The project account has also often clarified (another example) that TB is the only browser that comes close to actual fingerprinting resistance, with Brave being a decent second (excluding vanadium).

Tor browser is still the best option currently for anything close to resembling anonymity, with the caveat of being way worse in security than chromium. Unfortunately, GOS currently does not have a better solution, neither does Brave.

3 Likes

Vanadium doesn’t have any specific fingerprinting protection yet. They don’t want to implement fingerprinting protections which ultimately don’t work.

2 Likes

There are plans to have fingerprinting mitigations in Vanadium but it’s not being worked on at the moment.

Yes I know, thus the:

Even without fingerprinting resistance they still recommend Vanadium for most users over Brave. I’m not sure if I personally agree with that recommendation, but for each their own I guess.

1 Like

Just wanted to clarify for anyone reading because the part after that made it seem like they weren’t interested in fingerprinting protections.

1 Like

I am aware. Excluded it because its not a generally available browser, unlike Tor and Brave which are available.

Vanadium in its present state does have some fingerprint mitigation, but its not explicitly tied to the software itself and more to the OS as a whole. Every vanadium install on GOS appears the same on same device lines. So vanadium on GOS on Pixel 6 looks similar to another vanadium user on GOS on Pixel 6 (exception being some static data like timezone, IP, etc. This, along with less trivial stuff like cookie partitioning, is what GOS is working on to improve vanadium).

This is unlike most firefox hardened systems where values are randomized, and unlike Brave where some values are static and others randomised.

But yes, I get your point.

3 Likes

Too bad they state this without actually going into any sort of details.

1 Like

Implying Daniel Micay tweets every single tweet is both ridiculous and irrelevant to the criticism, ignoring the obvious ad hominem.

Is Mullvad Browser team not aware of firefox security situation? For a start, are the issues listed here all solved: Firefox and Chromium | Madaidan's Insecurities ?

On checking, it seems the first 3-4 issues itself are still unresolved. No point checking the rest, firefox security posture seems demonstrably bad. Some examples:

Search - mozsearch (this one shows pulse audio usage, not a direct bugzilla tracker here)

No need to elaborate on issues when they are well known and previously elaborated by the project account.

Again, the issue is the base browser not MB or TB work itself.

And the project account has also clarified the above.

4 Likes

@Anon47486929 I now realize I didn’t make clear at all I was referring to the fingerprinting with js statement, and not the security aspect as we entirely rely on Firefox upstream advance for that part.

Looking at the conversations, I have no idea what is lacking from their point of view, which is why I feel it’s a lost opportunity.

4 Likes

Ah my apologies then. I was focusing on the highlighted text in the quote.

I agree, it is unfortunate GOS didn’t state what specifically is wrong, TB could have worked on improving it. I don’t see a lot of open issues on TB issue tracker that relate with any new fingerprint mitigations, so it also doesn’t seem like something that should be obvious.

For those using immutable / Atomic distributions (such as the ublue ones), would it then be better to layer browser packages via rpm-ostree? Usually they take a Flatpack, brew, and distrobox / containers first approach, and suggest layering packages is a last resort.

Is there any drawbacks to using it in a distrobox?

Also fun fact: SecureBlue actually have a preconfigured hardened Chromium inspired by Vanadium so if you’re using that then probably use that

Layering is mostly discouraged because it inflates the image size and makes updates cumbersome, plus crowds the filesystem. But layering a browser is fine, and so is using distrobox compared to flatpaks.

The best approach imo is using bluebuild and making it a system component. Bluebuild is also not difficult to use, plus it allows you to add software stuff you need in the base image itself instead of layering it (which is helpful when core software you need is not running well/at all in a flatpak).

Just try to leave the browser’s sandboxing intact. Don’t use the Flatpak version. Which other method of installation you choose is up to you.

@ruihildt Regarding to the privacy of Mullvad Browser, do you know whether enabling Mozilla Account via about:config (i.e. identity.fxaccounts.enabled set to Ture) would make the browser stand out from others, or would increase its attack surface?

Thanks.

Bluebuild is interesting. I gather you just “roll your own” packages into it as desired, using the same build system as the ublue folks.

I’m considering replacing Aurora-Dx with SecureBlue, and have been watching that thread closely. Not sure what the official PG status of that project is yet.

Off topic, blue build

Yup. Bluebuild is actually how I think everyone should build their distros if they wish to use fedora atomic. Very flexible with what you wish to add, and doesn’t require you to manually do anything once it is setup (it updates with the base image you choose). It also saves you from the opinions of the distro dev since you can pretty much customize how you want it.

You can use secureblue as the base image for blue build too. As for the status, last I saw PG team member was testing secureblue, so hopefully there is some resolution soon.

1 Like