Chrome is also not immune, very recently had a serious flaw "actively exploited" https://www.bleepingcomputer.com/news/security/google-chrome...
- How expensive is it to discover a new vulnerability in a given app? (This may depend on code base maturity but also on choice of programming language, its inherent memory safety, and supply chain.)
- What privileges does a typical installation of the app grant once RCE is achieved?
- How hard is it to write a working exploit for a newly-discovered vulnerability, taking into account the security architecture that protects the app?
- Given a zero-day exploit, how many times will you have the opportunity to use it? How quickly will other parties discover it, is the vendor willing to provide patches, how long it is going to take, how much do the updates cost, and how difficult is it to upgrade the software in the field?
- Apps and computers tend to come in packs, and attackers love to move laterally. What opportunities would an attacker gain from lateral movement after gaining persistence in a given system?
- Market share and adoption may be skewed, as attackers may be interested in specific targets such as journalists or politicians, who may form a specific demographic with particular adoption rates, which can differ from those of the general population.
if you believe those numbers... 64% vs 3% market share. of course something that impacts 64% of the internet will be more valuable.
that's another sampling of actual web visits. though it skews more tech oriented of course so that's going to be away from safari/ie and more toward firefox and chrome.
/s
In general my recollection is that Chrome splits up more of its components. It sounds like, based on this post, the gpu process is now separated and there's sandboxing efforts going into that, but I'm pretty sure Chrome has had that for years now.
The current mitigations seem to be doubling-down on getting rid of C++ memory safety errors (still the main source of security holes), with Mozilla pulling the Rust and WebAssembly card. So there's some divergence here, rather than parallel paths with one ahead.
It does require one if your system doesn't support user namespaces. Some distros used to disable it, but they're getting rare these days.
But the setuid helper and user namespaces are used for other mitigations that can't be done through bpf. The guys who wrote the bpf sandbox have some nice articles about the distinction which you can probably Google.
I don't know much about the specifics of the implementations, but that seems like a significant difference for such a crucial security feature, especially post meltdown/spectre.
(You mentioned site isolation, which is a different feature, but the dates you have look right for that.)
I think you're confusing the general "sandbox that restricts access to the kernel" with the specific mitigation here. Firefox also had the generic kernel mitigations long ago: https://news.ycombinator.com/item?id=31362935
But it's true Chrome had them first. The same thread points out that Firefox reuses Chrome's sandbox, so like in the first sentence, there are causality constraints that would make it hard for Firefox to support it before Chrome did :-)