You can probably also use it on regular Firefox.

Which you absolutely shouldn't use, because just like Tor Browser before, a vulnerability in the browser can be immediately escalated into decloaking your real IP. Ideally the proxying doesn't even happen on the same machine.

"Absolutely shouldn't" is silly.

- Browser vulnerabilities are non-trivial.

- Mullvad browser's proxy feature only works if you're connected at the OS level, which helps mitigate browser level exploits.

Compared to any other off the shelf solution, Mullvad browser provides a good balance of usability & privacy.

Compared to something like you're describing, I agree it's worse.

One possible mitigation might be to run your system (or just the browser/certain apps) sandboxed to only communicate with the IP/ports mullvad uses for VPNs.

You absolutely shouldn't do that because a vulnerability in the kernel can be immediately escalated into decloaking your real IP. /s

(TBF this is presumably why parent specified that proxying ought to happen on separate hardware.)

> a vulnerability in the kernel can be immediately escalated into decloaking your real IP

Not necessarily IMO... if you create a network namespace that can only communicate with mullvad, and then run the VM inside that... even owning the entire VM and escaping it doesn't help you... you would now have to exploit the host kernel as well, which to me is basically just as good as it being separate hardware in the first place.

By the time someone has pulled off a VM escape I think it's safe to assume they're akin to a state level actor and a network namespace isn't going to stop them.

That said, did you perhaps miss the /s tag?

My threat model does not include state level actors, I don't think it's feasible for people to adequately protect themselves from most of them.

What threat model should you use Mullvad browser in? What threat model should you avoid Firefox-based browsers?

Please talk in terms of specific threats instead of fearmongering. For people wanting to avoid surveillance capitalism, which is a very common threat, I think Mullvad Browser is a fantastic choice.

For journalists targetted by nation states, perhaps it would be better to use Brave or Chrome inside of Qubes.

> For journalists targetted by nation states, perhaps it would be better to use Brave or Chrome inside of Qubes.

Curious why Chrome/Brave is recommended? I don't think any modern browser is better for anti-fingerprinting like the Firefox-based ones, including TOR and Mullvad Browser? Don't install random extensions outside the defaults and you're doing a lot better than a Brave/Chrome install if you want a usable internet.

I mentioned those because they are more focused on security than privacy/anonymity.

Chrome takes security a lot more seriously than Firefox, but Firefox does more for privacy. It would depend on the specific person, whether they are more worried about zero days or more worried about being identified.

Zero days for chrome will cost more than zero days for Firefox because Chrome takes security more seriously, there are more exploit preventions.

Brave is based on chromium and has a good update schedule, but it has some regressions like allowing manifest v2. Chrome is going to have the best update schedule.

Vanadium is the only browser that improves on Chrome's security.

(Don't get your opsec advice from HN)

(I learned this from GrapheneOS)

> Zero days for chrome will cost more than zero days for Firefox because Chrome takes security more seriously

They may cost more for Chrome, but it needn’t be because Chrome takes security more seriously; Chrome’s greater market share alone would be enough to account for this.

Not that I’m denying the overall conclusion. Just this bit of reasoning.

Well with qubes your security comes from VM isolation, so wouldn't that make using a gecko browser safer? If a browser exploit gets through the browser its stuck in a disposable VM with nothing else on it. Also the mullvad client is on another proxy netVM

It's not going to be an issue for most things which have been properly thought out as they will have proper isolation between servers which should have separate identities. Reusing the same VPN for all servers and relying on an eventual expiry before the IP changes is fundamentally not a great approach to rely on for isolation.