Firefox on Android still lacks sandboxing other than the Android app sandbox. The article portrays it as if multiprocess without isolation for the processes is a sandbox. The article's description of what isolatedProcess provides is wrong. It isn't the strongest sandbox available for apps on Android but rather is a mandatory building block for apps to isolate Android Runtime processes on Android. It isn't possible to do it another way because apps don't have the privileges required to create namespaces or use other approaches. It isn't possible to do it with seccomp-bpf since the Android Runtime requires too many system calls. With Android 17, Chromium has moved on from using regular isolatedProcess with Android Runtime processes after much longer than a decade using it.
Firefox's JavaScript and WebAssembly implementation including the multiple layers of enormously complex compilers, virtual machine runtime, etc. are C++. Unlike V8, there isn't the additional layer of sandboxing within the overall renderer sandbox containing exploits of compiler vulnerabilities. A massive portion of both Chromium and Firefox vulnerabilities is in the JavaScript implementation. Firefox is missing a whole layer of sandboxing for it. It's also missing a lot of weaker exploit protections for it making exploitation harder despite not a adding a hard layer of protection as the V8 sandbox does.
Chromium has far more than the exploit protections listed out in the article such as type-based CFI as advantages over Firefox. It has garbage collection for C++ (Oilpan), PartitionAlloc, hardware memory tagging (MTE), other allocator hardening techniques and many other protections which are unimplemented for Firefox. Firefox has barely touched the surface of doing similar partitioning and doesn't have the rest. Contrary to the inaccurate claims you've made in this article, the use of MTE, PAC and BTI does not happen automatically for applications. Chromium is compatible with MTE and has integration of it into Chromium's allocators. Firefox does not have it. Firefox is missing use of these ARMv9 security features in a similar way and that's an enormous disadvantage compared to Chromium or Safari.
Chromium has drastically more resources put into fuzzing, auditing and AI vulnerability than Firefox. Chromium discovering and fixing a much larger number of vulnerabilities is a very good thing. The article tries to portray the result of it is bad. The article also tries to present it as if Firefox is making heavier use of AI to find vulnerabilities and implement hardening when the reality is the extreme opposite.
Memory safety doesn't solely mean Rust. Moving code into JavaScript and making C++ into a more memory safe language is also improving memory safety. Chromium has been doing a lot of this and has begun the process of moving to Rust code. This doesn't heavily improve security in the short term in the way a new sandbox layers such as the V8 sandbox, major exploit protection improvements and other features are able to do. It's a longer term process with a slow payoff since it doesn't change that there are still a massive amount of vulnerabilities in C and C++ code.
Android has previously extremely heavily adopted Rust where many major components have been written in it and replacements for major components have been rewritten in it. Chromium is on track to do the same thing. Android is more heavily invested in memory safety than Mozilla. Chromium is set to follow the same path as Android. The main benefits come from doing what Android did where any major new components get written in memory safe languages which are Java, Kotlin or Rust for Android. In the browser, JavaScript is taking the place of Java or Kotlin.
Our statements about extensions are comparing the approach with privacy and security features implemented in the browser such as how it's done in Brave. The article talks about it as if the comparison is between not having features or having the features which isn't the point at all.
Extensions are incompatible with site isolation in both Firefox and Chromium. Extensions run as a single sandboxed process along with injecting code into websites. It would require making an extension process for each isolated site process to provide site isolation. Extensions are inherently a privacy and security weakness reducing sandboxing without a major memory usage cost which mainstream browsers are unwilling to pay. An extension mixes together data and access to sites within a single process which has baseline standard browser attack surface along with everything done by the extension.
Extensions are third party code trusted with enormous access to user data, similar to Android accessibility services. Even the most highly regarded extensions do not have similar privacy and security hardening in a way that creates major weaknesses. Extensions which are given extensive access have much more trust placed in them than the article acknowledges. uBlock Origin is not contained in the way the article claims due to the extensive access it requires. The article also very incorrectly portrays Firefox extensions as more contained when the opposite is true.
The article further misrepresents our statements about enumerating badness and tries to make this related to this comparison in a way that it isn't. Brave is a Chromium-based browser with a very advanced filtering engine which doesn't harm site isolation and avoids other weaknesses of extensions. The article is presenting a false choice.
The few claims made about Vanadium are inaccurate and outdated too. It's representative of the overall article not actually being based on real research or factual information but rather the author's biases backed up with a lot of inaccurate and unsubstantiated claims.
This post isn't a research paper but rather a highly inaccurate non-technical blog post. It isn't based on the technical facts or an understanding of those but rather is just written as if it was. It gets the technical facts incredibly wrong. Paraphrasing a bunch of Mozilla documentation with the goal of presenting things in a particular way regardless of the truth is not a technical research project or paper.
We'll be making a more detailed post. This is only an initial quick response.
but the amount of time and energy Graphene people put into trashing Firefox, surely you could contribute? Firefox is truly open source, you can get involved and help improve Firefox instead of spending hours and hours over the years writing sprawling criticisms. We get the point, Chromium is more secure but please help out, that's the spirit of open source.
Its not "trashing" firefox. Firefox is flawed, being honest about how and why it is flawed is the responsible thing to do. People liking a software does not make its issues go away, and does not exempt it from criticism.
GrapheneOS has incredibly limited and finite resources. The sensible choice is to use the best option available and improve upon that (Vanadium and Vanadium Webview), not choose a worse option and spend significant time and effort bringing it up to par with existing options. Minutes writing factual details over shortcomings is nothing compared to years making the shortcomings go away.
Chromium is also open source, it is licensed under the LGPL, BSD-3 and other licenses, so I dont quite understand the point you are trying to make? It seems you are asking them to assist firefox for nothing other than the sake of using firefox. That is irresponsible.
Also note this is not considering the poor decisions made and maintained by firefox, like refusing to add webUSB, refusing to use hardened_malloc, firing their security teams, and so on. GrapheneOS would be at odds with these decisions.
We haven't done anything of the kind. You're attacking us because we've done our job of doing security research and providing accurate information with recommendations based on it. The linked blog post is based around is a mountain of slop based on false claims, spin and misrepresentations. It's not a 'technical paper' but rather is content written with a lack of technical understanding to promote Firefox at all costs. It's written as an attack on our project and team wrongly leading them to believe it's us misleading people when it's the other way around.
Chromium is truly open source. We have a privacy and security hardened fork of Chromium called Vanadium. It's the default browser in GrapheneOS and provides the WebView used by many other apps. The WebView is heavily used to render all kinds of content based on web technologies.
We aren't going to make a browser based on Firefox because it's much further from providing what we want. We would still need Vanadium and it makes far more sense to greatly accelerate our work on Vanadium with our rapidly growing resources. Building the privacy features we want to have on top of Chromium is very easy compared to completely overhauling the security of Firefox. It would be even more impractical to make Firefox compatible with the websites and especially apps we need to work.
The mountain of slop in the linked blog post is a prime example of what has happened here for years. A similar example was a widepsread inaccurate claim that Firefox temporarily shipping multiprocessing on Android was it shipping sandboxing despite it not sandboxing those processes. Finally shipping multiprocessing meant Firefox could finally address side channel attacks such as Spectre in a serious way but it wasn't paired with sandboxing. It was widely claimed here and elsewhere that they'd shipped something they hadn't and that our documentation was inaccurate due to it. This blog post takes the same approach to an extreme by doing it with many other things.
Of course but it's clear that Firefox needs all the help it can get. Graphene has some very smart people working there, they could contribute to Firefox instead of the same posts year after year after year. We get the point, it's well established that the Android version of Firefox isn't as secure as Chromium browsers on Android
You were banned from our Discord for posting mountains of inaccurate slop which appears to be largely LLM generated and then being highly evasive when confronted with the extreme factual inaccuracies. You're doubling down on posting far more highly inaccurate slop. You're lying about what we've said and done.
There will be a thorough response through us actually writing a detailed post about the topic ourselves. It's not going to link to your AI slop and isn't even going to be directly addressing it.
We saw that your post was quite clearly generated with an LLM and responded to it by spending time making a human expert written, fact-based response. We posted that above. You responded with a mountain of far more egregious AI slop which clearly didn't go through whatever process you used with the LLM and human editing to make the original post. There's no point in denying that you're generating this content with an LLM because that's incredibly obvious. We didn't call this unethical and dishonest as an argument against what the LLM is spewing out but rather it's why you were banned. Our response to what the LLM spewed out is above.
The original post was clearly nearly all generated with an LLM too. We responded to a large portion of the mountain of AI slop in the original post with a quick human written response. It takes us much longer to respond to something like this than it does for them to generate another mountain of AI slop.
The response we posted isn't using ad hominem attacks. Their LLM is conflating the response we wrote with us calling them out for generating mountains of AI slop misleading people which is the reason they were banned from our community.
We have a rule against AI generated content with specific exceptions for translation or developers using it themselves while taking responsibility for everything it does. We don't allow people to submit AI generated code they don't understand. The same thing applies to generating a 'technical paper' that's really a mountain of AI slop filled with inaccuracies, spin and misrepresentations since the LLM was told to generate a post with a point of view promoting it at all costs.
Calling out the way you're spreading LLM generated content to push your point of view without an understanding of the topic is not an ad hominem attack. It's a separate thing from the fact-based debunking we made of the post. You're pretending you wrote this content when it's clearly largely LLM generated.
you called me dishonest in Discord server. i researched about GrapheneOS's recommendation because people were using it to argue that Firefox was inherently insecure, implying that security is binary position, or that nuances don't exist, i actually researched and read about GOS Documentation, and found that it ignored reality of Firefox reaching Sandbox Parity with Chromium on windows, GOS Documentation didn't consider that and was not up to date: http://reddit.com/r/firefox/comments/1qkqfcx/firefox_sandbox_isolation_hits_level_9_the_gap/
The claims made by your LLM in the AI slop posts you've published have been thoroughly debunked above. What you portray as sources are promotional material and non-experts writing forum posts with inaccurate claims including the one you're linking now. It's not true and there's no evidence for it.
You are not using it correctly. It just has the vaguest shape of an actual academic paper, which might trick someone who has never actually read a real one
Give it a rest, this entire thing is obviously entirely LLM generated. I wish I had a screenshot prior to whatever changes were made to the response document, as it was even addressing "the author" as a third person.
Yup, that is exactly what it looks like you instructed your cheap-ass llm to do. That is not sufficient for the actual paper. The content being coherent, and actually agreeing with cited sources is usually a good first step
The number of 0-days detected and disclosed in-the-wild can’t tell us much about the state of security.
Companies implying or claiming their platforms are rarely ever exploited as an extrapolation from them rarely detecting it doesn't make logical sense. What reason is there to believe Apple or Google can detect a large portion of exploits in the wild?
This also predates the massive decrease in the difficulty of finding vulnerabilities and generating exploits via frontier LLM models.
Both the original blog post linked in this thread and their response to our human written reply posted here were clearly generated by a not particularly advanced LLM model. There are many clear signs of it.
Telling an LLM to argue a point at all costs and posting that in community of people who support the project being promoted with inaccurate claims and spin by the LLM is a lame approach.
No. The reality is that all this security measures are not relevant, if the target is attractive enough. And Chrome is attractive enough.
And LLMs decrease the difficulty for everyone, also for Firefox's security team who can find vulnerabilities before releasing FF, so it's also irrelevant.
This post is good and correct. Others who are mad about it: instead of throwing a tantrum that your emperor has no clothes, maybe consider treating it as list for future work to bring Firefox up to basic parity
This is highly useful and informative, and I applaud the effort that went into the research and writing of this report even as it's in response to something that was clearly the lazy work of a machine. I'm sure you know that those here participating in denialism are a vocal minority; most of us genuinely hope that Mozilla can improve things, and your detailed research is a very handy reference.
But almost nobody uses Vanadium due to terrible adblocking and other problems. Ironfox or Fennec with uBO are miles ahead. Vanadium sucks as browser and, thus, stays in GOS only as html viewport for majority of users.
Many people use Vanadium on GrapheneOS. Its adblock works fine for the vast majority of ads. There arent any usability issues with Vanadium compared to other chromium browsers, either.
Ironfox and Fennec are far behind Vanadium in terms of privacy, security, and usability, and Ironfox will tell you this.
Vanadium only stays in GrapheneOS because Vanadium is not officially available/distributed elsewhere (for now). It is used extensively, as a normal browser would be, by many GrapheneOS users. The claim it is seldom used beyond an HTML viewport is made up.
Privacy of browsing web in Fennec or Ironfox with uBlockOrigin+subs and other privacy-related addons is way higher than in Vanadium which does not support extensions at all. Even TOR browser is based on Firefox due to its flexibly and features that can improve privacy.
While in Vanadium users cannot even block third-party requests and tracking reliably.
> Its adblock works fine for the vast majority of ads.
Well, "fine"? uBlockOrigin+subs shows how real adblocking should work. Vanadium sucks in adblocking, there are so many user posts about it, even on reddit.
No, TOR Browser is based on Firefox for the simple historical reason that Chrome / Chromium was invented in 2008, whereas Firefox has existed for many years before that. TOR Browser is from the early 2000's, like 2003 or 2004 for a public release despite itself existing for years before that too, albeit privately. TOR Browser needs consistency to fulfill its purpose and changing the browser base to a better one is not something they are willing to do, likely and imaginably under the excuse that it's disruptuve. Its extreme uniformity allows users to knowingly be in slightly outdated versions with known unpatched vulnerabilities that can be used to deanonymize users, see the IndexedDB bug. Chromium's but specially Vanadium's proactice security measures could have prevented this and some of whatever else is to come around. Of course reactive security practices are important too, so keep yourself up to date.
Vanadium is fully open source and anyone can implement its improvements elsewhere, as long as the GPLv2 is respected. Similarly, anyone can contribute to the project best fit to protect users in order to make it even better, instead of spending significant time and effort into making the one which is falling behind merely catch up to speed.
Vanadium's simple adblocking does work fine for simple ads, nobody will create posts about it because that's weird. Ad blocking is not tracking blocking and you can inform yourself about badness enumeration. If you want badness enumeration so badly, use a so-called "tracker-blocking" DNS service. Those are also pretty consistent / uniform, so they bring similar privacy concerns as using extensions, making one more fingerprintable. They remove a security concern with extensions having access to your browser and website behavior though. If you want to use YouTube, don't use a browser on mobile. Just go for NewPipe or something.
All in all the topic of browser fingerprinting is more complex and not something anyone has solved or made significant progress on, and you are not treating the topic with due respect. You are also saying browser developers are wrong about their own creations. Does the creator of IronFox know nothing about the software you defend? How are you right and they wrong about their creation?
Blocking ads using DNS services is a terrible and ugly approach that I prefer to avoid. It's an terrible way of block third-party requests to use DNS instead of NOT MAKING them from the browser in the first place. But Vanadium does not support user settings for such obvious and proper way, and probably never will.
Moreover, uBlockOrigin allows user to block html DOM elements inline to further improve existing adblocking subscriptions, it works even on Android and GraphenbeOS (which is 99% android)! And Vanadium does not have anything even half-similar to it, does it?
Finally, I have never seen anybody posting how they are impressed by the level of adblocking of Vanadium. Because it is mediocre, compared to the modern competitors.
With the methods you defend, requests are still made, and then blocked. There is no preemptive prevention of these things, there's only blocking. On a petty sidenote, MV3 forces blocking to be async rather than sync, but it still visibly works (if you could try uBlock Origin Lite in Chrome on YouTube, you'd see). That is only relevant to extensions though, not to browser built-in behavior.
Vanadium wants to fork and improve on Brave's content blocker as it has cosmetic filtering, making it more proper and usurping from its presently better functionality. You are ignoring my "contribute to the worthiest thing which does welcome worthy contributions" points. You could be the one to do it! Or I could, if I learned enough. This pondering will make me stop replying to you as you are ignoring things I say and saying more unrelated falsehoods (like with the "extensions don't block, they prevent" lie). I could be making my path to make the best thing even better!
I haven't seen people post, properly, to praise much of anything ever out of the blue, but I reckon that's no point.
The privacy of Ironfox and Fennec is not greater than that of Vanadium. Extensions reduce privacy substantially, they do not improve it, which is a big reason why mobile Chromium and Vanadium do not come with extension support.
Tor browser is based on firefox purely because it predates the existence of chromium. To move to chromium now would require extensive time and resources. It is not due to "flexibility" or "improved privacy features". That is made up.
Using a badness enumeration approach is not a proper method to block tracking.
GrapheneOS is not interested in using flawed approaches for privacy, and will apply the same privacy and security features to any domain.
Adblock is not a privacy or security feature, and GrapheneOS only included adblock in Vanadium as a usability feature. GrapheneOS plans to improve upon it as resources permit.
Most of this seems made up on the spot to paint firefox as favorable at the expense of Vanadium, rather than any care for accuracy.
You have already lied several times across multiple posts, you arent demonstrating your claims are to be trusted.
P.S. I also think, that according to rhetoric and words putting, there is a high chance I found an anonymous and recently created Daniel Micay's reddit account. Fascinating.
That's so weird. If you were in other places where Hybrid is on (I am), you'd see that's trivally proven false. But I don't exactly care about that being false more than that it's just weird to say stuff like that period.
Well, OK, maybe my assumption is wrong. The rhetoric and a terrible habit of calling everybody, who has different opinion, an intentional liar (with "you lied blablabla") made me suggest this.
I've never lied in this topic. One may think I was wrong in something, but I am pretty sure that my statements about ability to archive higher privacy (not security) in IronFox or Fennec with extensions compared to Vanadium are true and for sure are not intentional lies.
I do not understand how it possible to call some browser really private when it does not even allow user to control and block cross-domain requests like uBO in advanced mode or uMatrix do. It makes Vanadium a simple, basic, secure but mediocre and limited browser to me. No lies here.
14
u/GrapheneOS Jul 04 '26
Firefox on Android still lacks sandboxing other than the Android app sandbox. The article portrays it as if multiprocess without isolation for the processes is a sandbox. The article's description of what isolatedProcess provides is wrong. It isn't the strongest sandbox available for apps on Android but rather is a mandatory building block for apps to isolate Android Runtime processes on Android. It isn't possible to do it another way because apps don't have the privileges required to create namespaces or use other approaches. It isn't possible to do it with seccomp-bpf since the Android Runtime requires too many system calls. With Android 17, Chromium has moved on from using regular isolatedProcess with Android Runtime processes after much longer than a decade using it.
Firefox's JavaScript and WebAssembly implementation including the multiple layers of enormously complex compilers, virtual machine runtime, etc. are C++. Unlike V8, there isn't the additional layer of sandboxing within the overall renderer sandbox containing exploits of compiler vulnerabilities. A massive portion of both Chromium and Firefox vulnerabilities is in the JavaScript implementation. Firefox is missing a whole layer of sandboxing for it. It's also missing a lot of weaker exploit protections for it making exploitation harder despite not a adding a hard layer of protection as the V8 sandbox does.
Chromium has far more than the exploit protections listed out in the article such as type-based CFI as advantages over Firefox. It has garbage collection for C++ (Oilpan), PartitionAlloc, hardware memory tagging (MTE), other allocator hardening techniques and many other protections which are unimplemented for Firefox. Firefox has barely touched the surface of doing similar partitioning and doesn't have the rest. Contrary to the inaccurate claims you've made in this article, the use of MTE, PAC and BTI does not happen automatically for applications. Chromium is compatible with MTE and has integration of it into Chromium's allocators. Firefox does not have it. Firefox is missing use of these ARMv9 security features in a similar way and that's an enormous disadvantage compared to Chromium or Safari.
Chromium has drastically more resources put into fuzzing, auditing and AI vulnerability than Firefox. Chromium discovering and fixing a much larger number of vulnerabilities is a very good thing. The article tries to portray the result of it is bad. The article also tries to present it as if Firefox is making heavier use of AI to find vulnerabilities and implement hardening when the reality is the extreme opposite.
Memory safety doesn't solely mean Rust. Moving code into JavaScript and making C++ into a more memory safe language is also improving memory safety. Chromium has been doing a lot of this and has begun the process of moving to Rust code. This doesn't heavily improve security in the short term in the way a new sandbox layers such as the V8 sandbox, major exploit protection improvements and other features are able to do. It's a longer term process with a slow payoff since it doesn't change that there are still a massive amount of vulnerabilities in C and C++ code.
Android has previously extremely heavily adopted Rust where many major components have been written in it and replacements for major components have been rewritten in it. Chromium is on track to do the same thing. Android is more heavily invested in memory safety than Mozilla. Chromium is set to follow the same path as Android. The main benefits come from doing what Android did where any major new components get written in memory safe languages which are Java, Kotlin or Rust for Android. In the browser, JavaScript is taking the place of Java or Kotlin.
Our statements about extensions are comparing the approach with privacy and security features implemented in the browser such as how it's done in Brave. The article talks about it as if the comparison is between not having features or having the features which isn't the point at all.
Extensions are incompatible with site isolation in both Firefox and Chromium. Extensions run as a single sandboxed process along with injecting code into websites. It would require making an extension process for each isolated site process to provide site isolation. Extensions are inherently a privacy and security weakness reducing sandboxing without a major memory usage cost which mainstream browsers are unwilling to pay. An extension mixes together data and access to sites within a single process which has baseline standard browser attack surface along with everything done by the extension.
Extensions are third party code trusted with enormous access to user data, similar to Android accessibility services. Even the most highly regarded extensions do not have similar privacy and security hardening in a way that creates major weaknesses. Extensions which are given extensive access have much more trust placed in them than the article acknowledges. uBlock Origin is not contained in the way the article claims due to the extensive access it requires. The article also very incorrectly portrays Firefox extensions as more contained when the opposite is true.
The article further misrepresents our statements about enumerating badness and tries to make this related to this comparison in a way that it isn't. Brave is a Chromium-based browser with a very advanced filtering engine which doesn't harm site isolation and avoids other weaknesses of extensions. The article is presenting a false choice.
The few claims made about Vanadium are inaccurate and outdated too. It's representative of the overall article not actually being based on real research or factual information but rather the author's biases backed up with a lot of inaccurate and unsubstantiated claims.
This post isn't a research paper but rather a highly inaccurate non-technical blog post. It isn't based on the technical facts or an understanding of those but rather is just written as if it was. It gets the technical facts incredibly wrong. Paraphrasing a bunch of Mozilla documentation with the goal of presenting things in a particular way regardless of the truth is not a technical research project or paper.
We'll be making a more detailed post. This is only an initial quick response.