> Even with [Firefox's] attempt at a sandbox […], sites aren't ever cleanly separated into different processes. […] There is no sandbox containing anything afterwards beyond the app sandbox. All sessions and data for other sites is compromised. […] [Compared to Chrome,] Firefox is easier to exploit, [has] lots more low-hanging vulnerabilities and a half-baked weak sandbox. On Android, it has no sandbox at all.

Not saying you are wrong. But maybe you could elaborate and put things into context for me: How does Firefox's sandboxing differ from Chrome's if it's using the Chrome sandbox?

While googling for an answer I found another comment of yours[1] from 5 years ago. Could you possibly speak to what has changed since then and what the current status is? (At least to your knowledge since I understand you no longer work at Mozilla.)

[0]: https://www.reddit.com/r/GrapheneOS/comments/bg03np/browsers...

[1]: https://www.reddit.com/r/firefox/comments/76dxzg/comment/doe...

Keep in mind that, in May of 2017, desktop Firefox did not even yet have full support for multiprocess under particular configurations. Obviously you cannot sandbox content processes that don't exist, so there were some prerequisites that needed to be dealt with first. That was pretty much wrapped up by the Firefox Quantum 57 release.

The other thing to note is that the Chromium Sandbox is more like a "sandbox construction kit." It features all kinds of knobs and dials that allow the developer to configure how strict it is. We used to compare adding multiprocess and sandboxing to Gecko to swapping out the warp drive on the Enterprise, while it was still at warp. You can't just flip a switch one day and be sandboxed; too much code existed under the assumption that it could access whatever OS resources it wanted, without restriction. It took time to modify that code to be aware of that restriction and act accordingly. Each time an iteration of modifications were completed, we were able to tighten the screws on the sandbox a little bit more.

Not only has that been very useful as Gecko has been migrated to running in a fully sandboxed environment, it is also a necessity even at the final stage. For example, modern browsers constrain their interactions with the GPU (and its driver) to a dedicated process. That process is sandboxed, but because that process needs access to graphics devices, it obviously needs a weaker sandbox than the other processes hosting web content.

IMHO the win32k lockdown is not "mission accomplished," but is a HUGE indicator of how much code has been migrated to support sandboxing. On desktop, Firefox processes are now site isolated and are disconnected from their platform GUI systems. That's huge -- I'm sure there are still deviations between the Chrome and Firefox sandbox configurations, but they're a lot closer now.

Firefox for Android still has a long way to go (I was working on that when I left Mozilla), but unfortunately it hasn't been treated with the same urgency as desktop. I know that they're still working on that and have been able to make a lot of progress now that site isolation for desktop has been released.

Finally, I should point out that sandboxing is a defense-in-depth measure, but a lot of armchair quarterbacks seem to only ever want to focus on comparing the sandbox between Chrome and Firefox, while completely ignoring how much more of Firefox is written using memory-safe languages. That's important too.

> Firefox for Android still has a long way to go (I was working on that when I left Mozilla), but unfortunately it hasn't been treated with the same urgency as desktop. I know that they're still working on that and have been able to make a lot of progress now that site isolation for desktop has been released.

This might explain Daniel Micay's perspective on Chrome vs. Firefox (on Android) then.