# Mull (Android Browser) + Criteria Change

**URL:** https://discuss.privacyguides.net/t/mull-android-browser-criteria-change/14460
**Category:** Tool Suggestions
**Tags:** completed
**Created:** 2023-10-15T23:22:14Z
**Posts:** 55

## Post 1 by @jonah — 2023-10-15T23:22:14Z

Opening a thread to discuss two things:

First: Recommending **Mull** , available from [F-Droid](https://f-droid.org/en/packages/us.spotco.fennec_dos/). Obviously there is not a lot of diversity in our mobile browser recommendations, and Brave heading down the [bloatware](https://discuss.privacyguides.net/t/brave-browser-installing-vpn-services-on-windows/14450) route they’re annoying me more and more lately.

* * *

Secondly, Mull is obviously a Gecko browser, so to recommend it we would have to remove the “Chromium engine only” requirement for Android browsers. My proposal would be to do so and add a warning to Gecko-engine-based listings similar to our [warning about non-PFS messengers](https://www.privacyguides.org/en/real-time-communication/#additional-options), along the lines of:

> :warning: 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. Missing this feature likely won’t pose an issue for low-risk web browsers who keep their browser up-to-date, but those visiting higher-risk sites or at risk of targeted/0-day attacks should strongly consider a Chromium-based browser instead.

(Shamelessly mostly plagiarized from [https://divestos.org/pages/browsers](https://divestos.org/pages/browsers))

* * *

The reason for this change is that many of our community members **will** be using a Gecko-based Android browser anyways for one reason or another, so recommending one specific Gecko-based browser—which has the most desirable traits to our community in my testing—while also clearly outlining the potential danger is a harm reduction strategy that should be better than just telling people “Gecko bad” and leaving Gecko users to fend for themselves.

---

## Post 2 by @freddy — 2023-10-15T23:27:09Z

All of this makes a lot of sense to me, and seems like a pretty good idea.

---

## Post 3 by @anon28734771 — 2023-10-16T06:06:40Z

Do it in the same way as it was done with F-Droid. State that PG doesn’t recommend Gecko browsers, then explain the reasons and, at the end, recommend Mull for those who will still use a Gecko based browser, like we recommend F-Droid Basic for those who still use F-Droid.

---

## Post 4 by @Regime6045 — 2023-10-16T16:23:27Z

100% agree. There should be a Gecko browser in the Android recommendations, even if it’s with a caveat that it might be slightly less secure - because let’s be honest: if you think you’re targeted by 0-day exploits and per-site process isolation would help you, your threat level is way beyond that of the average user.

Also, Gecko browsers are the only ones supporting uBlock Origin on Android. I mean the Brave Shields are also quite good, but then you also get the whole “bloat” as you mention.

Lastly, some people (like me) don’t want to support the Chromium dominance and Gecko is the only useable alternative. That’s more a “healthy web” rather than “privacy” argument, but it might become one in the future, when Google forces more and more anti-features into Chromium (e.g. WEI API or Topics API recently).

---

## Post 5 by @anon66890361 — 2023-10-16T16:52:54Z

Please deduct some points for their awful looking monet logo

 ![Screenshot_20231016-221858~2](//forum-uploads.privacyguidesusercontent.com/original/2X/0/02ee0ca2c930d6a2976fe02e095633695481c03b.png)

---

## Post 6 by @ProgrammAbel — 2023-10-16T17:19:19Z

The design itself is bad enough, but the fact that it’s _off-centred_…

---

## Post 7 by @anon63378630 — 2023-10-16T17:23:36Z

@anon66890361@ProgrammAbel  
you’re both welcome to either fix it or design one yourself and contribute it to the project.

---

## Post 8 by @jonah — 2023-10-16T18:17:33Z

I didn’t mind the logo at first, but I hate that you pointed out it’s off-center :laughing:

---

## Post 9 by @TGS — 2023-10-16T22:18:43Z

I love Gecko-based/Firefox fork browsers on Android becuase of the great extension support and they’re not using a base made by a monopoler, Mull is a great browser in my opinion having used it (and many others, including Mulch) for over 2 years, Mull is always the one that I come back to! :slight_smile:

---

## Post 10 by @bee — 2023-10-17T06:27:34Z

Sort of on-topic, but @anon63378630, how large is the threat posed by disabling RFP in Mull? The capping of refresh rate to 60 made it hard for me to use the browser, so I wonder if it’s still worth using Mull with it disabled for the other benefits of hardening?

Of course you would be more vulnerable to fingerprinting, but if that isn’t too big a concern, is there anything else to consider?

---

## Post 11 by @Dkama — 2023-10-17T13:40:56Z

Wouldn’t it make more sense to recommend Mulch instead? No criteria change needed.

---

## Post 12 by @Regime6045 — 2023-10-17T15:09:36Z

But Mulch doesn’t have any adblocker. This alone disqualifies it as a browser recommendation in my opinion. (Yes you can use DNS-based filtering on your device but it’s quite toothless.) It’s mainly meant to be a webview provider in DivestOS.

Also Mulch is Chromium-based again. Many people don’t want to support the Google/Chrome monopoly. So knowing what’s the “best Gecko browser on Android” would be valuable.

---

## Post 13 by @iustitia — 2023-10-17T17:03:09Z

I don’t agree with the proposal in its exact form, but I do think including Mull in some form would have a positive effect – if done right. I will untangle some of what imo needs to be considered, and then adjust the initial proposal accordingly.

## Recommending Brave only

As @jonah correctly pointed out, Brave being the only option for Android isn’t optimal. However, that’s really only where the problems begin. Just by its nature as a Chromium browser, Brave fundamentally has and will have a problematic status in large parts of PGs target audience. The scandals from years ago made an already non-ideal situation worse. Be it Brave’s cryptocurrencies, its advertising strategies or that people would really like Firefox to be the obviously better option and are frustrated that it isn’t – Brave is a controversial topic.

In my experience, this has resulted in lots of hate against Brave, and people often quite mindlessly recommending worse alternatives. To be clear: I don’t mean Mull, I mean literally any Gecko-based browser, no matter their issues or state of decay after at times years without maintenance. The criticism Brave (definitely!) deserves for some things is overshadowed by the amount of criticism it regularly gets. Or at least that’s the case for arguments about immediate security and privacy, as well as basic usability. To be honest, I think the main difficulty here is that many of the most outspoken critics of Brave refuse to use it for non-privacy and -security reasons.

And this is just fine, there are lots of perfectly understandable reasons to use something else instead. Not every decision has to be laser-focused on security and privacy. It just has to be honest, should be grounded in _some_ understanding of security differences and fit the users’ personal requirements and subjective priorities. PG makes a recommendation based on factors that don’t always apply, people are allowed to not always come to the same conclusion, especially if they are just not that concerned about security.

## Simply recommend Mull?

But there’s yet another layer to this. We’re all fully aware that many people, no matter their reasons, will not use Brave, irrespective of it being the recommended option. Morally, this might fall under their responsibility, but that doesn’t make it that much better. PG exists to help people in this regard, and ignoring all the harm that will come out of this on a long enough timeline doesn’t feel right. For this reason, Mull should be included as best Chromium-alternative. Why not simply recommend it?

I think under no circumstances should PG start taking the convenient route on topics like this. Nobody here has really argued that Brave doesn’t currently provide better security, so this assessment should remain as it is. I also don’t think just placing Mull behind Brave in the article makes this clear enough. Changing the criteria to open a loophole just to be able to recommend something besides Brave would be outright worrying. This heavily creates the impression that the requirements and criteria are mostly there to place a professionally sounding framework around a decision that’s already been made based on personal preference. That’s exactly **not** what I hope PG is. People can decide based on personal preferences without any help. What PG should (and imo largely does) focus on is providing the privacy/security evaluations that can then serve as a base for readers to make a well-informed decision.

## Proposed Solution

Luckily, there is a solution that doesn’t require the criteria to be changed, doesn’t just abandon anyone not going with Brave and is even already well implemented elsewhere for somewhat similar reasons. @Lukas summarized it very well:

> [@Lukas](#):
>
> Do it in the same way as it was done with F-Droid. State that PG doesn’t recommend Gecko browsers, then explain the reasons and, at the end, recommend Mull for those who will still use a Gecko-based browser, like we recommend F-Droid Basic for those who still use F-Droid.

This would provide a great basis for people to make an informed decision. It would likely do quite a bit of harm-reduction by causing more people to go with **the next best thing** instead of whatever alternative they first run into. It would still be honest and encourage them to use Brave if they want to put security and privacy considerations first. Including something like

> **We do not currently recommend** Gecko-based browsers like Mull for anyone that wants the best security available.

leaves no doubts, but plenty of room for a “However, …”

## Also: Recommend Vanadium!

Finally, I’ll repeat a proposal that’s already been made [here](https://discuss.privacyguides.net/t/vanadium-grapheneos-web-browser/12828).

If there is indeed a need for something besides Brave, it makes very little sense to me to exclude a possibly more secure option because it’s “only” usable on the primarily recommended mobile OS – _while at the same time including a less secure option from a non-recommended source_. Vanadium coming from the same devs that make its OS gives it unique opportunities in comparison with most browsers. I won’t go into further detail here, but I hope we can agree that Vanadium is at the very least a perfectly good alternative to Brave security-wise.

## TLDR

- **Brave** should remain recommendation **#1**
- **Vanadium** should be recommendation **#2**
- Additional Chromium-based browsers fitting the criteria, if available (idk much about Mulch)
- **Mull** should explicitly be **not** recommended, but still be mentioned as **the best chromium alternative**
- Both the **security risk Mull brings** and some **reasons in favor of Mull** should be explained to provide readers with great conditions to make an informed decision fitting their individual priorities.
- The **criteria** should remain **untouched**.

This is far from an easy decision. I hope that whatever PG chooses in the end, it will be well thought-out and adhere to PGs values, even in spite of what many of its readers might want to hear.

---

## Post 14 by @anon63378630 — 2023-10-17T17:30:51Z

@iustitia  
I don’t think Vanadium (or Mulch) should be recommended until they have a working content blocker.

Vanadium does have a full-time developer working on it from what Micay has told me.  
So if it does come around, then yes it could be a solid recommendation.

@bee  
Please do not disable RFP.

---

## Post 15 by @jonah — 2023-10-17T17:34:04Z

I’ll share my perspective on why I prefer the Session/Matrix approach over the F-Droid approach in this instance, for your consideration.

These two cases are the only instances where we make these “half-recommendations” for security-related reasons, if I recall correctly:

1. F-Droid’s has a **major** flaw (IMO), namely that packages are signed by F-Droid rather than the developer. This has _significant real-world impact_ on regular users: it actively prevents the developer from delivering updates directly if need be, and it stops you from easily switching away from F-Droid’s repos. These usability+security concerns warrants F-Droid’s default repos being _actively discouraged._

2. Element and Session have a **minor** flaw (IMO), which is that they don’t support Forward Secrecy. Admittedly, the threats that this actually protects against are relatively rare and advanced, because the attack requires two things: an adversary collecting past conversations, and the later compromise of long-term keys. These events being the _only_ compromising factors are basically unheard of in the real world, but because FS is basically trivial to implement and the threat is still practical, there’s basically no excuse for a messenger not to use it.

_With that out of the way_, what’s not immediately clear to me is the real-world threat that the lack of per-site process isolation actually has to most people. In fact I would argue that this security flaw is a smaller _real-world_ problem than **both** of the security flaws detailed above. Thus, a full **anti-** recommendation feels disproportionally biased against Gecko-based browsers here.

This is why I would prefer to make an affirmative recommendation _alongside_ a warning that provides the context of this discussion, instead of a full anti-recommendation.

---

## Post 16 by @iustitia — 2023-10-17T18:52:37Z

> [@jonah](#):
>
> I’ll share my perspective on why I prefer the Session/Matrix approach over the F-Droid approach in this instance, for your consideration.

That’s solid reasoning, thank you for sharing it. Sorry if I’m a bit harsh sometimes. Still, ofc I can only refer to what’s written here.

I think it’s safe to say that whether an F-Droid- or Element-like approach makes more sense depends on how big the risk increase from using Mull instead of Brave actually is, and how that compares to the flaws of F-Droid and Element. I haven’t done enough research into this to be fully confident assessing this precisely, so I won’t.

Partly it also depends on what kind of user, experience, usage and threat model PG wants to assume here. I suspect that my personal circumstances warrant a bigger focus on taking any free & easy security increase available, than who you want this to be addressed towards requires. There’s no issue with that.

For me, it’s most important that readers will easily recognize that by using Mull, they’re willingly giving up a little security. Both approaches would suffice for that, so I’m not too worried anymore. Initially, I thought the idea was to simply recommend it as just another option, or at least not with a somewhat obvious visual clue.

> [@anon63378630](#):
>
> I don’t think Vanadium (or Mulch) should be recommended until they have a working content blocker.

I take it that means you consider not having a built-in content blocker to be worse than using Gecko instead of Chromium? Is that based on security or usability concerns?

> [@anon63378630](#):
>
> Vanadium does have a full-time developer working on it from what Micay has told me.  
> So if it does come around, then yes it could be a solid recommendation.

Uuuh, I’m definitely looking forward to finding out what a full-time dev will do with Vanadium:)

---

## Post 17 by @jonah — 2023-10-17T18:57:32Z

> [@iustitia](#):
>
> I take it that means you consider not having a built-in content blocker to be worse than using Gecko instead of Chromium? Is that based on security or usability concerns?

Well, the ability to control which scripts are running on your device and who they’re delivered by has _privacy_ advantages that are _related_ to both security and usability, but wouldn’t really fall into either category.

> [@iustitia](#):
>
> I think it’s safe to say that whether an F-Droid- or Element-like approach makes more sense depends on how big the risk increase from using Mull instead of Brave actually is, and how that compares to the flaws of F-Droid and Element. I haven’t done enough research into this to be fully confident assessing this precisely, so I won’t.

Cool :+1: As a team we’ll research this topic further, because yes I agree that an approach like our F-Droid anti-recommendation could possibly make more sense depending on this factor, it’s just my _current_ understanding that the loss in security here _doesn’t_ warrant the strongest possible warning on the site.

If anyone else has resources to suggest otherwise, definitely share them here too!

---

## Post 18 by @iustitia — 2023-10-17T19:11:26Z

> [@jonah](#):
>
> Well, the ability to control which scripts are running on your device and who they’re delivered by has _privacy_ advantages that are _related_ to both security and usability, but wouldn’t really fall into either category.

Agreed, but I was mainly wondering specifically about what having a content blocker that’s built into the browser would provide that’s important enough to be the deciding factor in a potential recommendation.

My personal experience using the existing built-in adblocking, disabled JavaScript JIT and other adjustments in conjunction with DNS blocking or a VPN that provides such functionality isn’t noticeably different than when I was using Brave.

This also assumes an approach of badness enumeration instead of goodness enumeration, which I’ve switched to since. I think Vanadiums design is well suited for that as is.

> [@jonah](#):
>
> As a team we’ll research this topic further

Great! Will the results of this be shared somewhere?^^

---

## Post 19 by @Sharply — 2023-10-17T19:40:12Z

FWIW I think [Cromite](https://github.com/uazo/cromite) being recommended would make much more sense than Vanadium or Mulch, I’m surprised it hasn’t been mentioned or brought up already in these discussions.

There’s been a lot of good points in this entire discussion and I don’t have much to add, overall I’m for recommending Mull (as long as there’s the disclaimer about Gecko), and I do think its silly to recommend Vanadium or Mulch in their current state (Despite them having very good security, they’re just missing crucial privacy features atm, and this is **Privacy** Guides after all). I personally think Cromite would serve much better as a non-Brave Chromium option since it has a strong privacy focus, I feel like its a good middle-ground, and its inclusion should probably be discussed if it hasn’t already been.

---

## Post 20 by @jonah — 2023-10-17T19:42:50Z

> [@Sharply](#):
>
> I’m surprised it hasn’t been mentioned or brought up already in these discussions.

Well, each discussion is specific to the individual tool being suggested, so they’re _mostly-ish_ independent of other tool suggestions. You can vote for and provide feedback about Cromite here:

> [@Cromite (Bromite fork)](https://discuss.privacyguides.net/t/cromite-bromite-fork/13274):
>
> One of the main contributors to Bromite has now officially forked it and created Cromite. [https://github.com/uazo/cromite](https://github.com/uazo/cromite) Uazo has been maintaining a Bromite dev/test build for a while now over at [https://github.com/uazo/bromite-buildtools](https://github.com/uazo/bromite-buildtools). In the latest release there’s an announcement that new releases will be in the new Cromite repository linked above. Note: there aren’t any binaries released in the Cromite “releases” page yet.

---

## Post 21 by @jonah — 2023-10-17T20:11:30Z

2 posts were merged into an existing topic: [Cromite (Bromite fork)](/t/cromite-bromite-fork/13274/14)

---

## Post 22 by @Pragmatic — 2023-10-17T21:07:11Z

Personally, I’m already frustrated that Brave is recommended before Firefox, whether on PCs or smartphones, especially in view of the various scandals that have occurred in the past. Firefox is the ‘only’ browser that isn’t based on Chronium and that’s doing more and more to improve security and privacy.

Yes, it would be interesting to add other browsers and Mull is one of them.

---

## Post 23 by @anon54160479 — 2023-10-18T04:42:35Z

> [@Pragmatic](#):
>
> especially in view of the various scandals that have occurred in the past.

What scandals exactly?  
How does this impact the security and privacy of brave?

Honestly, I can’t listen to this old nonsense anymore…

---

## Post 24 by @Regime6045 — 2023-10-18T09:47:18Z

> badness enumeration

Isn’t it the same with DNS blocking or VPNs with such functionality? They’re also based on blacklists.

In my opinion: Mulch and Vanadium may have some extra security benefits, but without a built-in content blocker, it just doesn’t make sense to recommend them as a _privacy_ browser. Yes, you can use DNS-based blocking but it won’t ever be as good (e.g. impossibility of blocking first-party ads/trackers; also in my experience you’ll end up seeing lots of “disable your adblocker” banners which doesn’t happen with uBlock Origin).

---

## Post 25 by @anon28734771 — 2023-10-18T10:55:24Z

> [@jonah](#):
>
> F-Droid’s has a **major** flaw (IMO), namely that packages are signed by F-Droid rather than the developer. This has _significant real-world impact_ on regular users: it actively prevents the developer from delivering updates directly if need be, and it stops you from easily switching away from F-Droid’s repos. These usability+security concerns warrants F-Droid’s default repos being _actively discouraged._

Major flaw that affected **who**? Everyone used and highly recommended F-Droid for years, and everyone was happy until that one article came up and everyone did a 180°, and instead of recommending F-Droid, they started to recommend avoiding it.

Last time I checked, F-Droid still has an excellent track record. The only major issue is delayed updates, but most sensitive apps have their own F-Droid repositories. Examples of those apps are Cake Wallet, Monerujo, Bitwarden, SimpleX, Bromite, Mull, and Mulch, all of which have their own repositories.

There are also almost 200 reproducible builds, and that number will probably increase faster and faster. Everyone can find a list of apps that have reproducible builds on the F-Droid Git repository.

How many people who downloaded apps that didn’t have their own F-Droid repository, didn’t have a reproducible build, etc. were seriously affected by the fact that F-Droid signs apps and provides delayed updates? How many people were compromised because of this? I will wait for a number and an example.

---

## Post 26 by @anon28734771 — 2023-10-18T11:39:31Z

> [@jonah](#):
>
> _With that out of the way_, what’s not immediately clear to me is the real-world threat that the lack of per-site process isolation actually has to most people. In fact I would argue that this security flaw is a smaller _real-world_ problem than **both** of the security flaws detailed above. Thus, a full \*\*anti-\*\*recommendation feels disproportionally biased against Gecko-based browsers here.

What are the chances of someone getting compromised because of F-Droid signing apps or having slightly delayed updates? Pretty slim.

What are the chances of someone being compromised by a zero-day or zero-click vulnerability? Pretty slim.

Now, what are the chances of someone visiting a malicious or infected website when browsing the web? I personally browse a lot, so for me, the chances are pretty high.

Why would I pick a browser that is generally less secure, lacks per-site process isolation, doesn’t have a WebView implementation, and also bypasses or cripples a fair bit of the AOSP and GrapheneOS hardening work for apps? I would rather pick a browser that comes bundled with the most secure mobile operating system whose developers have security as their top priority and also has extra hardening and security features on top of chromium which is already pretty secure.

Now about Vanadium not being recommended because of a lack of built-in content filtering:

If built-in content filtering makes that much of a difference vs. just using something like NextDNS, then why do Google or GrapheneOS developers not have built-in content filtering in their browsers?

(Before someone says, “Google doesn’t have built-in content filtering because it would hurt their advertising business,” I want to point out that Google could whitelist themselves and only filter out malware or malicious ads.)

---

## Post 27 by @anon28734771 — 2023-10-18T12:05:09Z

> [@iustitia](#):
>
> Changing the criteria to open a loophole just to be able to recommend something besides Brave would be outright worrying. This heavily creates the impression that the requirements and criteria are mostly there to place a professionally sounding framework around a decision that’s already been made based on personal preference. That’s exactly **not** what I hope PG is. People can decide based on personal preferences without any help. What PG should (and imo largely does) focus on is providing the privacy/security evaluations that can then serve as a base for readers to make a well-informed decision

> [@iustitia](#):
>
> The **criteria** should remain **untouched**.

I completely agree.

Criteria shouldn’t be changed out of desperation for more options. Projects should adapt to PG’s criteria, not vice versa.

The best example is how many changes and improvements @amilich and his team made to fit PG’s criteria to be recommended in the email providers section.

---

## Post 28 by @Sharply — 2023-10-18T20:56:06Z

> [@anon28734771](#):
>
> If built-in content filtering makes that much of a difference vs. just using something like NextDNS, then why do Google or GrapheneOS developers not have built-in content filtering in their browsers?

GrapheneOS has claimed they plan to add content blocking support to Vanadium in the future, see [here](https://grapheneos.org/usage#web-browsing).

---

## Post 29 by @anon28734771 — 2023-10-19T08:51:20Z

I know. There is also an [GitHub issue](https://github.com/GrapheneOS/Vanadium/issues/10) opened on Dec 31, 2018.

If built-in content filtering made that much of a difference compared to DNS-based filtering in terms of security, I think they would have implemented it in 5+ years.

(Also, while built-in content filtering can block more types of ads, it is limited to the browser, and it takes more CPU and battery to do the same thing.)

---

## Post 30 by @privacyyy — 2023-10-27T12:18:20Z

Mull logo is ugly asf. I saw someone made a damn cool logo and contributed to the project but the founder didn’t get it tho

---

## Post 31 by @anon21489307 — 2023-10-27T13:39:27Z

> [@jonah](#):
>
> :warning: 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. Missing this feature likely won’t pose an issue for low-risk web browsers who keep their browser up-to-date, but those visiting higher-risk sites or at risk of targeted/0-day attacks should strongly consider a Chromium-based browser instead.

This reason alone should make Firefox or any Gecko browser a not recommend browser on Android, as it’s insecure by design.

I have nothing much to add here. I didn’t know before that Firefox lacks this very important feature on Android that has been implemented like forever everywhere. I’m glad I read this thread, thanks.

---

## Post 32 by @anon63378630 — 2023-10-27T16:48:44Z

@privacyyy  
Please link where they posted the actual raw files and licensed its use.  
Two designers have made _proposals_, they haven’t contributed them.

I’m not a company nor have I received million dollar grants like GrapheneOS or CalyxOS to pay for such proposals.

---

## Post 33 by @anon86237473 — 2023-10-27T18:41:13Z

I know I’m contributing to the derailing, but I like the current logo. It’s groovy.

---

## Post 34 by @anon80779245 — 2023-12-28T05:17:22Z

I will like to say that Brave fixed the VPN enabled by default issue .Brave seems to always fix the privacy issues. I understand people don’t want to support the Chromium monopoly but

1. This isn’t FOSS privacy guides, so it is irrelevant.
2. If Mozilla just matched Brave’s privacy protection by default, we wouldn’t be talking about this. Millions more will be using it, =\> more revenue =\> money to improve Gecko.  
3)If Mozilla foccused on making Gecko a match for Chromium performance-wise we wouldn’t be here. Why hasn’t there be a single novel browser built on Gecko in the last decade ? There is a reason Edge, Brave, Arc are all built on Chromium.

---

## Post 35 by @Reset0609 — 2023-12-28T06:51:19Z

> [@anon80779245](#):
>
> Brave seems to always fix the privacy issues.

Which they themselves created to begin with

> [@anon80779245](#):
>
> If Mozilla just matched Brave’s privacy protection by default, we wouldn’t be talking about this. Millions more will be using it, =\> more revenue =\> money to improve Gecko.

Your point? Those who are worried about a Chromium monopoly arent generally concerned with Mozilla’s wellbeing but rather about the consequences of that for the open web/open standards

> [@anon80779245](#):
>
> Why hasn’t there be a single novel browser built on Gecko in the last decade ?

Librewolf, Floorp, Ghostery, Thorium (android), Midori, Mullvad Browser, Mull…

> [@anon80779245](#):
>
> This isn’t FOSS privacy guides, so it is irrelevant.

Its thinking long term as opposed to immediate term. I suppose long term thinking is irrelevant if you dont plan to inhabit this planet much longer and dont care about everyone else who will :upside_down_face:

---

## Post 36 by @anon80779245 — 2023-12-28T07:43:48Z

> [@Reset0609](#):
>
> Which they themselves created to begin with

True.

> [@Reset0609](#):
>
> Your point? Those who are worried about a Chromium monopoly arent generally concerned with Mozilla’s wellbeing but rather about the consequences of that for the open web/open standards

Can Gecko really survive without Mozilla ?

> [@Reset0609](#):
>
> Librewolf, Floorp, Ghostery, Thorium (android), Midori, Mullvad Browser, Mull…

Most aren’t novel and are just forks. (Librewolf, Ghostery, Mull, etc.)  
Mullvad is essentially a Tor fork. But I can agree it is novel as it brings fingerprint resistance browser to TOR level.  
Midori seem to not be reliable yet : their website display their phone number as (123) 456-7890. Floorp doesn’t even blocks mixed content by default so aslo dubious support.

So one novel browser in 10 years versus dozens of Chromium browsers.

I understand the point that FF Gecko might be inherently better privacy wise, but the fact is that Chromium has been chosen by the industry. No one forced Microsoft, Graphene OS, … to choose Chromium over Gecko. The fact is that it is better.

---

## Post 37 by @Reset0609 — 2023-12-28T07:57:03Z

> [@anon80779245](#):
>
> Can Gecko really survive without Mozilla ?

Probably not. The point is that you made it seem as if those who worry about a Chromium monopoly perceive saving Mozilla/FF as the end goal and not the means. It doesn’t otherwise make sense to point to Mozilla’s obvious mistakes in order to declare it unworthy of being saved.

> [@anon80779245](#):
>
> Most aren’t novel and are just forks.

Sure, now we somehow went from three, of which only one actually started out being Chromium based, to dozens of “novel” browsers based on Chromium. Care to enumerate?

> [@anon80779245](#):
>
> No one forced Microsoft, Graphene OS, … to choose Chromium over Gecko. The fact is that it is better.

Correlation does not mean causation, being a better avenue to be quickly profitable or having a viable product is not the same as being technically superior

---

## Post 38 by @anon58717436 — 2023-12-28T08:13:12Z

I don’t like Firefox but why not proposing Mull on Android with a warning as long as the [GeckoView sandboxing](https://bugzilla.mozilla.org/show_bug.cgi?id=1565196) is not implemented.

However it should be a **danger** (red color) and not just a **warning** (amber color).  
In my opinion, this is not just a little privacy problem but a well-known for years big security issue.

---

## Post 39 by @anon80779245 — 2023-12-28T08:17:31Z

There is no Mullvad Browser on Android.

---

## Post 41 by @anon58717436 — 2023-12-28T08:29:21Z

Thank you I made a mistake on the browser name.

---

## Post 42 by @Viper — 2023-12-28T09:05:35Z

I’m not a fan of forks or projects. I say nay. Leave it as is. Look at how bromite died.

---

## Post 43 by @FlipSid — 2023-12-28T15:29:08Z

> [@anon80779245](#):
>
> If Mozilla just matched Brave’s privacy protection by default, we wouldn’t be talking about this. Millions more will be using it, =\> more revenue =\> money to improve Gecko.

This is not correct.

Privacy is not the same as security, while one can argue that having to install an extra extension (ublock origin) is extra work and brave blocks out of the box (if you don’t use the guide here) I would argue privacy wise Firefox (or Mull) has the to hand privacy wise with a good set up ublock.  
Now security nothing beats Chromium because of the per-site process isolation.  
If it is needed? This level of security? Dunno…

And honestly starting to care less.

And then there is this:

> **[“Expert” hackers used 11 0-days to infect Windows, iOS, and Android users](https://arstechnica.com/information-technology/2021/03/expert-hackers-used-11-zerodays-to-infect-windows-ios-and-android-users/)**
>
> The breadth and abundance of exploits for unknown vulnerabilities sets group apart.

From

> **[Dynamic filtering: Benefits of blocking 3rd party iframe tags](https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-Benefits-of-blocking-3rd-party-iframe-tags)**
>
> uBlock Origin - An efficient blocker for Chromium and Firefox. Fast and lean. - gorhill/uBlock

Yes I’m starting to set up ublock for Mull :sweat_smile:

---

## Post 44 by @anon63378630 — 2023-12-28T19:03:50Z

> [@Viper](#):
>
> I’m not a fan of forks or projects. I say nay. Leave it as is. Look at how bromite died.

I have an extensive track record of monthly updates for DivestOS and updates within two days for Mull and Mulch:

- [https://divestos.org/misc/a-dates.txt](https://divestos.org/misc/a-dates.txt)
- [https://divestos.org/misc/ch-dates.txt](https://divestos.org/misc/ch-dates.txt)
- [https://divestos.org/misc/ffa-dates.txt](https://divestos.org/misc/ffa-dates.txt)

Mull is now the longest standing FOSS privacy browser on Android at 2,228 days old.

---

## Post 45 by @oci3o — 2023-12-28T22:15:26Z

Why dont you just follow what ffupdater does with chromium based browsers?  
Stick a ! next to it and say this contributes to the chromium monopoly etc.

Wish FF would get their game together and get some proper security in Android.

---

## Post 46 by @oci3o — 2023-12-28T22:16:16Z

I agree here.  
Mull is the FF browser I trust on Android, it does a lot of the leg work for you out of the box (Arkenfox on Android), while still being usable!

---

## Post 47 by @anon80779245 — 2023-12-29T06:00:46Z

My point was that Brave shipped with privacy by default while Firefox doesn’t. Since Firefox is used by dozens if not hundred of millions, the impact that Mozilla will make by just switching a few toggles on by default will be huge.

On Desktop, hardened FF is more private than Chromium.

Even though Mull has advanced fingerprint resitance, it leaks one crucial information: your device languages.  
I have 4 languages on my phone and I can confidently says less than 1 million internet users have the same setup. So Mull leaking them in the http header (no way to disable) means every other FP resitance is useless. On the other hand with Brave I can choose which languages will be used.

Also, why isn’t Mullvad available on the Play Store ?

---

## Post 48 by @anon63378630 — 2023-12-29T06:16:38Z

> [@anon80779245](#):
>
> Even though Mull has advanced fingerprint resitance, it leaks one crucial information: your device languages.

Locking to English was directly prohibiting usage by a significant population of the world. Nor does Mull strive to be Tor Browser.  
There was actually an impressively long-standing modded variant of Mull explicitly for adding RU support over on 4PDA.

---

## Post 49 by @Reset0609 — 2023-12-29T07:01:28Z

> [@anon63378630](#):
>
> Locking to English was directly prohibiting usage by a significant population of the world.

Indeed, I need to disable Brave’s language fingerprinting resistance feature, otherwise I’ll get English versions of a lot of websites, that being an oftentimes poor translation from their native/main language or even a diffetent website with a reduced feature set. That said, if I understand correctly, Chromium has a flag that sends just the user’s top language instead of all of them. Can’t Mull do something similar?

> [@anon80779245](#):
>
> Also, why isn’t Mullvad available on the Play Store ?

If you mean Mullvad browser, probably because its not available for Android

---

## Post 50 by @anon80779245 — 2023-12-29T10:33:05Z

I’m not talking about locking to english but why is it leaking the languages set in my phone settings?  
Let me choose what languages I want my content to be in instead of just fetching it from my settings.  
My case might be niche but I only browse in English while I am using one language regularly for communication. The two other languages are more rare but it’s still nice to have them enable on my phone.

---

## Post 51 by @anon80779245 — 2023-12-29T10:33:27Z

I meant Mull not Mullvad.

---

## Post 52 by @anon63378630 — 2023-12-29T16:37:10Z

It can’t load non-English pages if it doesn’t send the supported languages header.

It probably could be reduced, but that is for upstream to address.  
Fenix already implements custom language handling over desktop.

And why is Mull not in Play? Why shoot your foot off giving information to Google for a privacy browser?

---

## Post 53 by @FlipSid — 2024-01-01T18:50:24Z

Btw my vote goes for adding Mull to the recommendation list alongside Brave.

As proposed on post #1  
I mean if you can tust browser, then Mull.

Privacy wise, depending on how you set up ublock it will probably yield more privacy too.  
At least as far as I can tell per checking links (Brave does not remove \_utm from links for example) and ubo also tells you exactly what it blocked on the site.  
For setting up I’m using this guide:

> **[Home](https://github.com/gorhill/uBlock/wiki)**
>
> uBlock Origin - An efficient blocker for Chromium and Firefox. Fast and lean. - gorhill/uBlock

---

## Post 54 by @anon80779245 — 2024-01-09T15:54:29Z

I would argue it should be on the play store for a few reasons : user reviews (unlike Fdroid), visibility (you exclude 99% of android users) and security (Aurora Store is more secure than F-Droid). That being said it is not the subject of this post.

---

## Post 55 by @jonah — 2024-03-31T10:43:36Z

> <https://github.com/privacyguides/privacyguides.org/pull/2460>
>
> Changes proposed in this PR:
> 
> - https://discuss.privacyguides.net/t/mull-andro…id-browser-criteria-change/14460
> 
> 
> 
> 
> - [x] I have disclosed any relevant conflicts of interest in my post.
> - [x] I agree to grant Privacy Guides a perpetual, worldwide, non-exclusive, transferable, royalty-free, irrevocable license with the right to sublicense such rights through multiple tiers of sublicensees, to reproduce, modify, display, perform, relicense, and distribute my contribution as part of this project.
> - [x] I am the sole author of this work. 
> - [x] I agree to the [Community Code of Conduct](https://www.privacyguides.org/coc).

---

## Post 56 by @jonah — 2024-04-10T05:47:09Z

> **[Mobile browser: Add Mull (#2460) · privacyguides/privacyguides.org@5b41dec](https://github.com/privacyguides/privacyguides.org/commit/5b41dec8b086ba402834a8b49ac20bed5ca7f405)**
>
> Signed-off-by: Daniel Gray 
> Signed-off-by: Freddy 
> Co-Authored-By: redoomed1 <161974310+redoomed1@users.noreply.github.com>
