First: Recommending Mull, available from F-Droid. Obviously there is not a lot of diversity in our mobile browser recommendations, and Brave heading down the bloatware 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, along the lines of:
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.
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.
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.
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).
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!
Sort of on-topic, but @SkewedZeppelin, 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?
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.
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:
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.
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.
@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.
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:
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.
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.
However, we still explicitly recommend Element and Session because they have a lot of unique functionality that the alternatives lack. I feel like Mull falls closer to this category.
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.
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.
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?
Uuuh, I’m definitely looking forward to finding out what a full-time dev will do with Vanadium:)
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.
Cool 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!
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.
Great! Will the results of this be shared somewhere?^^
FWIW I think 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.
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:
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.
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.