Chrome's sandbox is far superior to Firefox's from a security standpoint. I think the best bet is to run Ungoogled Chromium on Linux; it's got even less telemetry than Firefox and is more secure.
I personally don't even care whether or how much feature parity Firefox has or whether its GPU rendering is 20% slower. Not supporting Firefox comes at our own loss.
Also, there is no such thing as an "ungoogled chromium". Google controls chrome/ium, and as long as people use it, those people remain subject to Google's control.
In that article there's something I disagree with having tried:
> Most of the functionality of the patches are either in the best case minimally beneficial or can be reproduced with either a setting, a flag, or a switch,
Some years ago, on Linux, I tried finding all the command line flags necessary to use Chrome without having it talk back to Google. Unfortunately despite hunting for every option I could find (and there are a surprisingly large number of undocumented options), including with "strings", nothing I tried completely suppressed traffic to Google while using Chrome on sites not connected with Google.
My motivation at the time was to run my own local applications using Chrome as the UI, the way Electron is used now. It didn't work out because I failed to find a way to confidently suppress traffic to Google.
That experience is why I run Ungoogled Chromium now when I need Chrome functionality.
For me Google _is_ a third party. And taken into account its behavior it receives 0 (null) trust from me. What i really don't understand is this blind trust in everything google does.
That said, the "binaries built by anyone" thing is pretty suspect.
Perhaps there are just as many escapes being found each quarter in Chrome as the other browsers and they are just being hoarded privately but I don't find that super plausible.
FWIW I think it is probable that the IPC APIs into and out of the sandbox have been more thoroughly fuzzed and otherwise tested in Chrome than in Firefox. I don't know how that translates into actual security though.
And here's Theo de Raadt's opinion of Firefox from back in 2018: https://marc.info/?l=openbsd-misc&m=152872551609819&w=2
> Firefox's sandboxing lacks any site isolation. Site isolation runs every website inside its own sandbox so that an exploit in one website cannot access the data from another.
It does seem that Firefox's site isolation is becoming more ready. From a Mozilla blog post two days ago, with instructions how to manually enable it on Firefox stable, beta, or nightly: https://blog.mozilla.org/security/2021/05/18/introducing-sit...
Also, from the same link, they mention X11:
> One example of such sandbox escape flaws is X11 — X11 doesn't implement any GUI isolation which makes it very easy to escape sandboxes with it.
Definitely true that X11 sucks (sorry NVIDIA users). So we have Wayland becoming more mainstream now. I've been using it for several years already, on GNOME and Sway. Working great... even Electron is native now (Signal, VS Code, etc).
And lastly, they rightly mention Pulseaudio:
> PulseAudio is a common sound server on Linux however, it was not written with isolation in mind, making it possible to escape sandboxes with it.
In the last few months PipeWire became a mature drop-in substitute for Pulseaudio in my experience. It was designed with isolation in mind, and a whole bunch of other things.
Hoping Firefox can bridge the gap in security with Chrome so we can wholeheartedly recommend it to people without caveats! We deserve a fast, full-featured, secure, and open source alternative to proprietary web browsers.
A slightly tangential issue is that the mitigations section is not super compelling to me because I think many mitigations are low-value. Evaluation of mitigations typically does not ask the right questions: How much work is it for an attacker to bypass the mitigation, assuming they're aware of it? Can that work be packaged and reused in multiple exploits? And how many bugs become completely non-exploitable due to the mitigation?