Revise statements on Gecko browsers (Android) to make security shortcomings clear


Drop recommendations for all Gecko-based browsers on Android, except Tor Browser (lacks alternatives), due to very lacking security and add statement of reasons.

Alternative proposal

If above proposal does not succeed, at least change statements below to make the security shortcomings very clear, and that they apply to all users, not just high-risk. Add statement that Chromium browsers are generally preferred for security reasons.

Affected section

Statements to revisit

Firefox (Gecko)-based browsers on Android lack per-site process isolation, a powerful security feature that offers additional protection against a malicious website exploiting a security vulnerability.

Gecko-based browsers don’t just lack site-isolation. They lack internal sandboxing in general, have no automatic variable initialisation, are behind in exploit mitigations, their memory allocator is worse then Chromium’s and more. See further reading below.

Missing this feature likely won’t pose an issue for low-risk web browsers who keep their browser up-to-date,

Would you bet your authentication cookies and passwords on it? Because that’s effectively what you do, if you use it as your main browser.

but those visiting higher-risk sites or at risk of targeted/0-day attacks should strongly consider a Chromium-based browser like Brave instead.

People can get hit by 0-days for many reasons, not just targeted attacks. Also many people hit by targeted attacks didn’t even consider themselves worth the effort beforehand, so this advice wouldn’t have helped them. Per-usage cost of professional spyware software is not as high as people think, especially considering the financial power of some adversaries.

[Mull section]

Even though Mull does it’s best to configure Firefox and keep it up-to-date, it is a Gecko-based browser and thus should not be recommended due to the inherent security concerns.

Further reading

Edit 2: Reworked for more clarity, added structure, concrete proposal and further reading, changed title. Hopefully left general statement intact.

I was able to find some reference to that there but not much else.

I did find this article which briefly talks about the application sandbox. The two latter paragraphs you quoted were not written by me. Not quite sure I entirely agree with them either. I do like references to or any relevant bugs if we can If you think you can explain it better, happy to take a contribution.

1 Like

The Android Security Model with regards to sandboxing

Since there seem to be a bit of misunderstanding about the different sandboxes on Android, let me give a quick and high-level overview of the Android Security Model.


On a high level, there are four kinds of applications on Android (from high privilege to low privilege):

  1. System
  2. Privileged
  3. Untrusted
  4. Isolated

1 and 2 need vendor signing, so we are not interested in them. All third-party apps fall under category 3 and can optionally use category 4 for more security.

Untrusted (mandatory for third-party apps, per app):

  • One different UID per app (and user profile, will omit this in the next sentences) given at installation time
  • Selinux untrusted_app domain with a different MCS category per app
  • Lax Seccomp-filter
  • Protects the system and other apps, but not its own data from itself, because the sandbox is per app, not per process

Isolated (optional, stricter, per process):

  • One UID per process
  • Selinux isolatedProcess domain with a different MCS category per process
  • Apps can use stricter seccomp filter (Chromium uses strict and fine-grained filtering)
  • Very limited access to file system, only access to two or three services, no permissions
  • Can protect its own app data from its processes running as isolatedProcess, because the sandbox is per process
  • Chromium makes use of it e.g. for renderer processes, Firefox does not. Check ps -Z via ADB or see FF’s issue tracker


IPC is done through Binder. Apps (untrusted) can talk to each other but only with mutual consent and only within the same user profile.

Permission management

Permissions are declared in the app manifest, which is part of the App’s APK. They are granted either through Unix group assignment or runtime checks. In case of runtime checks, the app asks the corresponding provider/manager and the provider checks against the App database containing the permissions of apps. The app database reports permission status back to the provider and, if allowed, the provider grants access to the information.



In addition to my comment directly above about sandboxing in the Android Security Model:

GrapheneOS has mentioned the shortcomings of Gecko-browsers quite a few times on social media and the chatrooms and they consider it severe enough, to mention it in the offical documentation you linked, which means something.

Madaidan lists sources (mainly to Firefox’s issue tracker) in his comparison of FF and Chromium, so while it is not up-to-date in some parts, anyone can look up in the sources which issues have been resolved and which aren’t.

The second link talks about the general application sandbox (untrusted above), not about the sandbox for untrusted web content (and other applications with high security needs, isolated) which should be used for e.g. renderer processes. Without a dedicated sandbox for untrusted web content, cookies and other in-browser app data is not enough protected. The first link is not really useful, because it mixes things up and is written by someone who doesn’t know how to distinguish between the two.

Feel free to move this and the other comments about it into a separate thread for discussion.


I read the part where GOS talks about it, and for them it’s a serious security flaw to use a Gecko-based browser.
To the point where it would even weaken GOS itself. GOS really points the finger at Gecko in general.

So, is Mull really recommended, and Tor too?

1 Like

And yet you signed off on it? Not sure why you’d even mention this then.

Anyways, I have now read through or watched every link posted in this thread, and I could not find a single instance of any real-world problems this has caused.

Let’s take a look at cybersecurity problems like this from a very high level. If nobody can point to an example of this problem affecting members of the public, then it is not something which is worth stressing about for the general public.

Focusing too much on details like this which cause unnecessary anxiety and inconvenience for people is distracting us from the real problems and bigger threats. This is not a Privacy Guides-specific problem, but a major problem with the cybersecurity sector as a whole.

Most people reuse weak passwords on every site, most people upload all their data unencrypted to the 3 major OS developers, most people communicate on heavily monitored messengers, etc. We don’t even have a Windows guide yet, and we’ve spent months discussing whether Brave is the only good Android browser. What is the end goal here, to utterly convince people who would otherwise be using Google Chrome and Microsoft Edge that Firefox is the epitome of all evil and using it will destroy their cyber-lives? :confused:

People who are at risk of being targeted should have better defenses than a warning on a website, they should have direct security consultations. That is simply not the target audience of general advice published on the internet.

Feel free to let me know about a real-world example of this problem, otherwise from my point of view it is pretty much just an interesting thing for Firefox developers and high-risk users (who we specifically mention already) to think about.

Our recommendations are of course as they say on the website.

There is no need to “revisit” this criteria, as it was added 2 weeks ago following discussions which took place since October 2023. Everything here was already discussed and considered.


Yes I did, but I am have been thinking about it more in light of what @sha123 wrote.

but those visiting higher-risk sites or at risk of targeted/0-day attacks should strongly consider a Chromium-based browser like Brave instead.

There’s always a first, but yes, there are also things Firefox does which Chromium does not very well, eg Reader Mode. About the only thing I feel a little uncomfortable about is suggesting that it only applies to people who might be the subject of targeted/0-day attacks.

That is true, and obviously things like this get immensely complex very fast, so I’m not even sure where we would begin to explain it, without going in to depth, because one thing leads to another.

Sad but true.

I wasn’t suggesting revisiting the criteria, just those above paragraphs maybe if we could elaborate a little more/explain it better.


These sources are about security models, not about pointing out individual cases of exploitation. Neglecting what I said with a simple “I could not find a single real-world problem” does not work. Good security models try to prevent future exploitation, make it more expensive and limit damage. Sandboxing is a big part of it and neglecting it does not help.

Not having an internal sandbox in browsers hasn’t been adequate for many years. You should know perfectly well that browsers with 10s of millions of lines of code have immensely many bugs and some are exploitable. Or exploitability is unclear and they might just not get fixed. These are just the known vulnerabilites for Firefox: Security Advisories for Firefox — Mozilla

Do you want to be vulnerable to most of the exploitable bugs or only be affected within the renderer of one website and only need to really care about the much much smaller subset of RCE+SBX chains?

Do you know Manfred Paul who exploited all four major browsers at Pwn2own 2024 and won the contest? FF (desktop) was the only browser with a sandbox escape. Guess, what he said about exploiting all of them: “To be fair, browser sandboxes are a huge part of these mitigations - and for that I only did the Firefox one (the other stuff was Renderer-Only)”

Aside from sandboxing you are more effected by more bugs than on Chromium, because of weaker exploit mitigations and other weaker mechanisms.

Most people use their browsers to visit many websites a day, when searching for something often land on new and previously unknown websites with unclear reputation, and many of them with a lot of third-party code. So you basically run untrusted code from 100s or 1,000s of parties every day. Which requires different protections than the app sandbox, because nobody installs 1,000s of apps from untrusted sources every day. And the app sandbox does not protect the highly sensitive data inside the browser like cookies, passwords and history.

Has nothing to do with the security of browsers.

You make it sound like there is only the choice between Chrome, Edge and Firefox.

Many people did not know in advance, that they were targeted. You don’t need to be targeted to get hit by a browser exploit, especially if it’s not that difficult, because the attacker does not even need a sandbox escape to profit, which reduces cost of exploitation immensely.

I can understand, that because it has been recently added, and some work has gone into it, it is not the most liked topic to discuss. But just because it was recently added, does not make it the right decision.

I think the Mull section gives users a false sense of security. It makes it wrongly seem, like it’s no big deal and you basically have to be a high-level target (whatever that means) to be affected.

And while @SkewedZeppelin does an amazing job at keeping all of his projects up-to-date and makes quite some configuration improvements to Firefox, I would not recommend a Gecko-based browser at all for regular browsing, considering there are alternatives with better security.


Both @jonah and @sha123 have very valid points.
What if we add a box warning about Firefox sandbox weakness?
I feel we shouldn’t drop Firefox, being more exploitable in targeted attacks and being an insecure browser is not the same thing.
Also leaving monopoly to chromium browsers only feels wrong.

Also off topic but related, I find the vast majority of people using EOL phones dating back android 7 or worse and still not seeing they being targeted with massive attacks that should be trivial now.
To me is alarming but in real life situations maybe it’s not so dramatic? I don’t know but probably for the average user the real problem is more tracking and profiling than be powned (not avocating for something insecure though).

tangentially related, but man i hate that i check every year or so on bugzilla and there hasnt really been any indication much of this is going to be worked on anytime soon. really disappoints me because i generally do like firefox on android more than any of the chromium options


Well, the question is where you draw the line of being “insecure”. Fact is, it is way less secure than Chromium and in a browser this should not be taken lightly. I would not call it secure enough for the average user who clicks on every link without thinking twice. And I agree with Job Choice:
“I really believe that if your infrastructure can’t survive a user clicking a link, you are doomed. I’m the director of cybersecurity at NSA and you can definitely craft an email link I will click…” and “Clicking is what links are FOR.”

Browsers have a different threat model than OSes protecting against malicious apps respectively RCE+SBX of apps. It is more likely to visit a website containing something malicious than installing a malicious app from the Play Store.


I think we should warn about the risks, and perhaps elaborate, because people will assume it is good enough, without considering the wider implications to what actually provides security on the Android platform.

You’re not the only one. Certificate Transparency I guess will come soon?

Popular misconception that Firefox on Android is also as healthy as Firefox on Desktop. Even with Tor Browser, there really are things you can’t spoof about your fingerprint on a mobile device, meaning it is certainly less anonymous on a handset than desktop.


That’s true, Firefox on desktop and on mobile are two very different things.
While I prefer using Firefox on my laptop, I use Brave on android.


While I don’t agree with the decision to add Mull, I can understand it. However, I can’t understand the description. There is no such a thing as “low-risk web browsing”. @jonah what is evidence of it ?

My proposal is to change the description warning to just keep the first sentence.

1 Like

Guys :fist:t5:
I’m on the side of adding Mull to the site. There a people who will not use Chromium Browsers.
So which Geko to trust? I “fully” trust Skewedzeppelin with Mull.
I will post the sources I have for pro Chromium and then write a few more lines:

I think this is enough info’s. The links include further links :slight_smile:
Thing is, to come back to what I was saying… There are people who will not use a Chromium Browser. Also there are people who don’t like Brave (the only real good (Chromium) Browser on standard Android.
Mull on the other hand has a skilled Dev, has the Arkenfox user.js, JIT disabled.
There is also a guide on how to set it up:
In addition I would recommend using medium mode and blocking 3rd party iFrames:
Home · gorhill/uBlock Wiki · GitHub…
Edit: Keep extensions to a minimum, prefer uBlock Origin:
4.1 Extensions · arkenfox/user.js Wiki · GitHub
I see no reason not to recommend it to users who refuse to use Chromium. Better than Fennec and vannila Firefox.
On the other hand, and that’s just my personal opinion, and on GrapheneOS I see no reason not to use Vanadium.
Cheers Guys, before you fight each other have a beer. Or a hike :space_invader:


I think it’s just better to recommend using it with No-Script and in incognito mode.


I don’t trust Chromium based browsers. For example no addons available (Google evil corp have paranoia about adblocking extensions).

Topic about this

I like Mull and Fennec for example. Both on F-Droid

P.S: ?rdt=58179 such things should be removed before adding link to post

I completely agree with @jonah on this. We are talking about fringe issues for days. For an average citizen, what is at stake with regard to this feature?
I am not a security expert, but what I know is that the likelihood, possibility and impact are the part of cybersecurity risk assessment.
Even if it’s a significant vulnerability, when the likelihood and possibility is low, it considered medium or low risk. That’s the basic idea in the assessments.

Edit: Half sentence is completed.


Evil corp have all the popular AdBlock extensions on their store. If they wanted them gone they would be.

Before you reply with “But Manifest v3 deadline!” , go and confirm there’s no MV3 AdBlock extensions on evil corp’s store.

Post deleted by author