Unfortunately, as long as Firefox security infrastructure does not match Chrome, I can not use it. Note that errors like use-after-free and buffer overflows are marked as Critical (run arbitrary code on computer) for Firefox, but marked as High (execute code in the context of, or otherwise impersonate other origins.) for Chrome because of sandboxing.
Firefox sandboxing does not use Rust. Servo sandboxing (work in progress) does.
It's not accurate to say that Firefox has no sandbox. Sandboxing work has been rolling out for many months now, and later versions have increasingly restrictive sandboxes. You can see the current status per version here: https://wiki.mozilla.org/Security/Sandbox#Current_Status
Hardening the sandbox is a constant work in progress, but it's not as simple as "compromise of browser engine automatically means arbitrary code execution as running user" any longer.
Sorry I didn't mean Sandboxing used Rust, It was a separate thing (That Rust is less susceptible to such class of errors, so the more code written in Rust the better)
Also didn't mean it has no sandboxing (I knew about efforts), my point was its security is not a match for Chrome yet, as seen from the amount and type of critical errors.
When it is there I would definitely use it along with Chrome.
In case it wasn't clear, it is now the case that content process compromise is no longer critical unless combined with sandbox escape.
Looking at historical vulnerability reports can be misleading in this regard, as the sandboxing features are rather recent (pre-stable-version in some cases).
If I wasn't clear as well, As far as I can see from the link you gave It still does not match the level of security Chrome offers, it is getting there, but not yet.
As Mr. Patrick Walton over there said, Mozilla is still building up the exact, minimal file-system permissions. So, yes, in that way it is still not yet on quite the same level as Chrome.
In terms of security architecture, there is to my knowledge only one bigger difference left and you can change that, if you want.
The difference is that Chrome will spawn a new process for every new tab (unless the webpage in it is from the same domain as another tab). Firefox instead will always round-robin the tabs across a fixed number of processes to achieve lower RAM usage and as result of that also somewhat better performance.
But you can tell Firefox to round-robin across up to 1000 processes or what have you, so that it then does spawn a new process for every new tab (and therefore sandboxes each tab individually).
To do so, go into about:config and set "dom.ipc.processCount" to a high number, like 1000.
I guess as long as it is not default behavior it will stay as a weakness then? I am not sure if it is worth to exchange it for memory or performance gain.
Also is using thread per tab approach more susceptible to memory leaks, resource sharing issues or OS scheduling shenanigans than process per tab approach? You close the tab, the process is dead and resources are mostly guaranteed to returned. My knowledge of modern browsers is limited, maybe this was considered an acceptable compromise though.
Though the Firefox developers aren't going to skimp on sandboxing (or other exploit mitigation techniques) just because of Rust. Defense-in-depth is the name of the game; Rust just provides a layer of language-level defense that C++ previously didn't offer.
Firefox: https://www.mozilla.org/en-US/security/known-vulnerabilities...
Chrome: https://chromereleases.googleblog.com/search/label/Stable%20...
Hopefully with their sandboxing project done (Also with Rust) will make Firefox much better in the security department, but until then, no.