For the record, this is what most of the discussion in this thread has been comparing LW to, and we believe FF+AF is better too, not just Mullvad Browser.
Wow, one year without logging into the forum and the Librewolf issue is still being discussed⊠I am honored to have created one of the most discussed threads on privacyguides hahahahahaha.
By the way, hello everyone again. Iâm not going to appear here much, the truth is that Iâm very busy with my computer science degree, and on top of that Iâve become obsessed with philosophy, so I donât have much time left during the day to stay updated on the forum, but even with that I try to check the forum and the web updates from time to time.
I will try, as far as I can, to be more active in the forum and propose/discuss more things.
(PS: In general terms, nowadays I still prefer to use Librewolf in Linux as default browser that I almost never use, something like what happens with Vanadium in Graphene, that although I use more frequently Brave or Firefox, I leave Vanadium as default so I donât mix up the fingerprints when opening links from the rest of the applications.)
Welcome back!
I just came across this and thereâs a tonne of useful information here: https://www.reddit.com/recap/LibreWolf/
LibreWolf is one of the best privacy browsers out of the box. It also does have automatic updates now.
Good news.
LibreWolf is one of the best privacy browsers out of the box.
I agree. I think LW serves much the same niche as Brave (easy privacy without much of a learning curve)
My personal perspective:
Librewolf doesnât provide anything that canât already be achieved with Firefox (in fact virtually every privacy protection Librewolf enables was built by Firefox (and Tor) contributors and is present in Firefox.
But that doesnât mean there is no value to Librewolf. Librewolf serves a particular type of user quite well, more or less a similar demographic to Brave Browser, those who desire privacy, but lack either the knowledge, time, interest, or confidence to harden their browser themselves. For this sizeable group of users, I think Librewolf is a very reasonable choice.
Regardless of whether you start with Firefox and harden it yourself, use a template like Arkenfox, or want a turnkey solution like Librewolf, you can achieve more or less the same configuration. It just depends on how you want to get there, and the degree to which factors like reliance on an additional smaller 3rd party matter to you.
In terms of the Firefox family of browsers I think all of these options have a place and a comparative advantage in at least one specific area:
- Firefox mildly hardened (etp strict, https only, gpc, uBO, and a couple other tweaks)
- Librewolf
- Firefox w/ Arkenfox (âhardenedâ Firefox)
- Mullvad Browser
- Tor Browser
relevant, but personal frustration
A mild frustration of mine, is that because Librewolf has been debranded/rebranded, and because there is a bit of bias/distrust of larger projects in this space, less informed users often misattribute Firefox features present in Librewolf as being Librewolf features, and misconstrue Librewolf as âfixing Firefoxâ when in reality it is leveraging features built into Firefox, and is much closer to a pre-configured Firefox profile, than an alternative to it (LWâs configuration is largely based on Arkenfoxâs user.js template). This is not a criticism of Librewolf as a project, just a frustration.
edit: IIRC the (valid in my eyes) reason LW isnât recommended officially by PG (apart from automatic updates) is that compared to just using Firefox itself, it introduces potential vulnerabilities (trusting a smaller project/additional 3rd party, potential for delayed updates, etc), while not solving any additional privacy/security problems that canât be solved with a well configured Firefox or another recommended option (Brave, Mullvad, Tor). But remember, something not being recommended by PG, just means its not a recommendation, It doesnât mean it is an anti-recommendation.
Just asking out of curiosity, does this not apply to Arkenfox as well?
Not really. I think this is one of the strengths of the Arkenfox approach. Arkenfox is just a template, (the user.js file in combination with your own useroverrides.js file which are a set of changes to Firefoxâs default preferences).
When you use Arkenfox, you are still using Firefox, Arkenfox isnât software, it doesnât modify the Firefox browser, doesnât affect Firefox updates (which still come directly from Firefox). So you are not dependent on the maintainer of Arkenfox in the same ways you are dependent on a software developer
And equally importantly because Arkenfox is a semi-DIY process, you are expected to read the wiki, encouraged to understand the changes being made and the process, and expected to customize it to fit your needs. You are necessarily much more involved in the process and informed if you follow the wiki, review the pretty well commented user.js or webui. So the trust relationship is a bit different in the case of Arkenfox.
With that said, you are still putting some trust in the maintainer of Arkenfox to choose good defaults, and/or trust in yourself to recognize when they make a choice you disagree with and override it yourself (this is how the project is intended to be used, it isnât a one-size-fits-all solution).
Sorry I canât buy the additional 3rd party potential vulnerabilities argument. It just sounds so unfair to Librewolf team.
Who would assure that arkenfox wonât change security.certerrors.mitm.priming.endpoint
from https://mitmdetection.services.mozilla.com/
to their own server, or change DoH to their own DNS server in an update?
Who would assure that the next 31/71 virus detection of Mullvad wonât be false positive any more?
You are exposing to the codes of 2 entities (Chromium and Brave) with Brave and 3 entities (Firefox, Tor and Mullvad) with Mullvad. Itâs not different to Librewolfâs. The only difference is the âbiggerâ organizations of the others. If PGâs criteria for browsers include âMust come from a big teamâ then I would 100% agree of rejecting Librewolf because of that criterion.
Currently the only valid reason to reject Librewolf is the update criteria. All of other reasons are just bias nitpicking and ignoring the same things with other browsers, and not in the criteria at all.
The difference is that Brave and TB/Mullvad are ahead of their upstream projects. Features originally developed by the Tor Project are regularly added to Firefox as well as vice-versa. Brave has features which are unavailable in any other Chromium browser, Tor private windows and native IPFS support just to name two examples.
I donât think Librewolf adds anything to Firefox that Firefox canât already do, it just takes things that Mozillaâs released and enables them by default. Arkenfox does the same thing, except to stock Firefox. Correct me if Iâm wrong
Personally Iâm kind of neutral on Librewolf at this point, but I think the update situation in particular is still a big deal to other team members, so it likely still wonât be added.
I was talking about the concern of âpotential vulnerabilitiesâ due to Librewolf being a 3rd-party or a smaller project, itâs an unfair reason if itâs used to reject the proposal. I didnât talk about its features comparing to the upstream, itâs about the same vulnerabilities existing in other configurations/browsers that are not from chromium or firefox team themselves as well.
I did say if thereâs a reason to reject this based on the criteria, itâs just about the updates. (And yes, if you count âbringing something differentâ as a hidden criterion for recommendations, I would agree too, since I also see this in some other topics, and I donât have further opinions about this criterion).
I donât think Librewolf adds anything to Firefox that Firefox canât already do
Honestly, you might be right, but not 100% sure this is true, but even so, I think privacy by default is very valuable to the common user especially if they are not so tech savvy (majority of users). There is a trade off for privacy at slight expense of security via relatively slower updates, but this is a privacy guide after all. There are several projects on Privacy Guides that are as small as Librewolf, yet still recommended.
Just find it somewhat odd that almost every other privacy community outside of Privacy Guides recommends Librewolf as a default out-of-the-box privacy browser.
Maybe add it as a sub-recommendation below firefox for those user without the capability or will to harden firefox with a small disclaimer on the trade-off?
Hmmm, I do not think itâs just that itâs a 3rd party. Technically Mullvad Browser, Tor Browser, etc, are also 3rd party and therefore a non zero risk introduced. I think the differences are the following points:
- Mullvad Browser and Tor Browser have substantially larger resources dedicated to development
- The above two browsers offer entirely unique use cases as to why youâd want to choose them over vanilla Firefox
The point seems to be that it seems to be fork with less resources and doesnât seem to do anything majorly different than a configured Firefox, or Firefox with Arkenfox.
With that, if there are automatic updates, and there is a clear comparison between the other choices about why it is better than an alternative, then I think it makes for a good recommendation. But if the other choices offer the same benefits with less risk, seems to be at best a footnote that it was considered but excluded due to XYZ.
On the topic of Librewolf:
I think part of the issue here is differing impressions of what PG recommendations mean, and what role the criteria play.
My imperfect understanding is that PG recommendations are meant to highlight the best in class software and services (in the context of Privacy and Security). It is a curated selection, not an exhaustive list of every tool that exceeds minimum criteria. Meeting the criteria is the minimum, not a guaranteed way to get a product listed. And just because something is not listed as a recommendation doesnât mean you personally canât or shouldnât use it, and doesnât mean it is an anti-recommendation.
Sorry I canât buy the additional 3rd party potential vulnerabilities argument. It just sounds so unfair to Librewolf team.
I think you donât buy it because youâve only considered half of the equation: the issue is that you are extending reliance to a 3rd party AND not gaining anything not already possible with mainline FF or the other recommendations on the list. It is a cost/benefit thing, you canât just look at half the equation.
Brave offers clear improvements over upstream Chromium, Mullvad and Tor Browser serve specific use-cases better than any other browser, including upstream Firefox. A downstream derivative that has some unique clear comparative advantage will be weighted differently than a downstream derivative that isnât providing something unique.
(with that said, Iâm sympathetic to the argument that the comparative advantage LW provides is âeasy-button-privacyââalthough Brave serves that niche as well)
I also think you may have misinterpreted what I meant by vulnerabilities. I was not referring specifically to malicious code. Maybe additional âpotential points of failureâ would be a clearer way to express what I mean. You are counting on an additional 3rd party to:
- Consistently and promptly provide updates. (this has historically been a common issue with smaller derivative browsers)
- Write decent code / be competent
- Stay committed / not lose focus or interest in the project. (this is historically a big issue in FOSS, so many projects get a flurry of attention/development in the first few years and then slowly (or quickly) fade into being under or un-mantained.
- Not do something dumb or immature (see Thorium)
- Have decent security practices
That doesnât mean downstream derivatives are bad or should never be used (I think they are good in the bigger picture, and Iâve repeatedly defended and acknowledged the value of Librewolf throughout this thread). These are just somewhat minor points to consider when choosing the browser that is best for you. Personally I am fairly neutral on whether LW should or should not be listed, I donât really think there is a wrong choice here, but I think I understand the reasons why LW is currently not listed as well as the reasons many people are attracted to Librewolf.
On the topic of Arkenfox:
Ideally you would and should. And itâs made easy to do. the ability to see the changes an update will apply is built into the updater script which you run manually. Arkenfox is just a human readable file, it cannot and does not update itself on its own.
Also, changelogs and changes are posted and discussed publicly and all modified settings can be reviewed here. And because it is just a user.js file, changes tend to be somewhat infrequent and very âbite sizedâ (small). Because updates are small and infrequent (often just a few flipped preferences) and because the userbase is pretty experienced and engaged, it is pretty unlikely a malicious or negligent setting would slip by unnoticed, even if you are not personally checking every update (which you are encouraged to do).
But again, I do not think we need to be focusing on the less likely risk of either LW or AF being outright malicious. That was not something I intended to imply. But if that were to occur the potential consequences are much more limited in the case of AF (as it is just a list of changes to about ~100 Firefox preferences)
Security risks have their own standards and assessments. Itâs not something to ignore just because the software brings something different of privacy to the upstream. GrapheneOS rejects Gecko-browsers because of their security risks although forks like Mull bring a lot of improvements in privacy (and actually security with JIT-disabled) comparing to chromium.
I did not just compare with AF alone.
Who would assure that the next 31/71 virus detection of Mullvad wonât be false positive any more?
Why is only Librewolfâs security is a concern while Mullvad showed the same security concern with that? I know about Mullvadâs response. My point here is if you bring security as an aspect to reject, please back it up with valid evidence because itâs a serious topic.
(And actually the non-autoupdateable of AF brings a contradiction to PGâs update criterion, and a âdifferenceâ of LW with FF+AF, but ok if no one wants to discuss between LW and AF, I wonât discuss it further).
Again, as I said above, if we count âbringing something differentâ as a hidden criterion, I wonât oppose it and there would be none of this discussion. But if you bring security concern as another half of equation, please back up that half clearly with security-based evidence, not via âits privacy trade-off aspectâ because itâs a whole other serious field with plenty of resources and can easily raise many other peopleâs eyebrows.
I think youâre still fundamentally misunderstanding what Arkenfox is.
Arkenfox is not a browser. There is no Arkenfox Browser to autoupdate, no security patches to apply, etc.
Arkenfox âusersâ are simply Firefox users, using the Firefox Browser (not a fork, not modded version, just Firefox).
Updates come directly from Firefox, exactly as quickly as mainline Firefox (because it is mainline Firefox). In terms of update speed, In terms of update speed, FF+AF exceeds all of the recommended desktop browsers except for Firefox (which it ties with) on the update criteria:
- Supports automatic updates. [Firefox does, and by extension Arkenfox does]
- Receives engine updates in 0-1 days from upstream release. [Firefox has no upstream, FF (including FF+AF) users receive updates as soon as they are ready]
I think that you are confusing updating the browser (this is the PG criteria) with updating your personal settings which are fundamentally very different things. An unpatched browser is a big deal, a Firefox setting being left in its default state is not (and that is the only consequence of not updating your user.js file).
What you are interpreting as a flaw of Arkenfox is actually one of its strengths.
FF + AF is recommended as a bundle in one of the recommendations. Yes, outdated preference can still lead to some security risks because under the hood, it changes the relevant codes inside too. This is integrated to the browser core even deeper than changing CSS on the websiteâs interface and CSS is not immune to security risks either. Thereâs not much sense to keep your browser updated and your forced preferences outdated for years.
And that is just a small part about the security assessments in my previous comments. Iâm using FF+AF with RSS feed notified about the commits before updating, and the only reason I assess it to be safe is because itâs still active, discussed and updated with FFâs updates. Iâm also using both Librewolf and Mullvad, depending on the situation, and security-wise everytime I deemed myself that âthis browser is more secureâ, I have to ask myself the opposite question âwhat is the risk of the other browserâ. Thatâs when things are boiled down to these 3 bullets (which are applied to all 3 options Iâm using above)
- Is it updated? How many days is it late to upstreamâs updates? Do I accept that delay?
- Who is the team behind the project?
- How much different is it comparing to the upstream?
Only the 1st one is valid based on PGâs criteria. The other 2, if we agree as hidden criteria, I agree too. But none of that is just because they are done by 3rd-party team, it needs more details than that.
Iâm not sure where youâre getting the idea that outdated user.js âchanges relevant codes insideâ because if the preference the user.js is changing gets deprecated or removed or even just renamed, there is no setting in the ff code for that user.js preference to change and ff will just ignore it when parsing the prefs.js generated from the user.js. Itâs pretty clear what user.js does as per the Arkenfox wiki
I donât really mean outdated here as Firefox removes it completely at an update. In many cases, Firefox hid the option out of about:config
and put the plan to deprecate it over time (and of course it would still run during this time until they remove it completely). Itâs not uncommon practice. And yeah, âchangeâ is not really a correct term here, I should say that they run another code path depending on the value of the preferences.
I can understand why PG may have a preference for Firefox/Arkenfox in its recommendation, considering LibreWolfâs delay in security updates. But I do not understand why they cannot both be recommended, with the caveat included for readers to decide for themselves.
Personally I find the modification of Firefox too daunting, and find the Mozilla big-tech affiliations off-putting. The LibreWolf developers takes care of both of these concerns, by doing the modifications for me, and by providing an independent check of Mozilla updates just in case Mozilla were to tamper with anything privacy related.
Which is why I am opting for LibreWolf. But I think it would be of benefit to all if the PG desktop browser recommendation page included LibreWolf, and more generally had a more clear and comprehensive synopsis in the opening paragraph.
For example:
Tor is the only browser which can come close to ensuring full anonymity. However, websites are often blocked through Tor, and connection speeds are slow, which is why we also recommend Mullvad, Firefox, and Brave, all of which provide good privacy in conjunction with a VPN.
Mullvad out-of-the-box provides strong privacy protections, which are greatly weakened if extensions are used or settings modified. Firefox is capable of providing the same anti-fingerprinting protection, but requires much modification (with Arkenfox) which some may find inconvenient. LibreWolf is a preconfigured Firefox suitable for those who are intimidated by the modification required to harden Firefox, though comes with the security risk of having its updates released a couple of days later than the mainline Firefox browser.
Some websites may not work properly on Mullvad and Firefox, which is why we also recommend Brave, which is based on Chromium and therefore has minimal compatibility issues. Brave does not provide the same level of privacy protection, however it remains good option for those who value privacy, relative to Google Chrome and other mainstream browsers.
Apparently LW doesnât disable JIT (not sure itâs an issue in ARM Linux, though).
MB does so (in an Apple silicon Mac).