Just read through the above discussion and did some documentation updates earlier today. This is me trying to distill down my thoughts on the issue so far.
IMO, we absolutely must use a browser that has some dedicated, skilled, preferably paid development team behind it, that can reliably push out updates when necessary and deal with security issues in a timely fashion. While all of these other projects that make their own variants of Firefox or Chromium are neat, there are two potential severe issues that can result if we use one of them:
- Update lag. An update just not getting pushed out to users for a week could (in severe situations) be fatal to the userâs security. Browsers are the perfect storm of problems that make them attractive to an attacker - theyâre absolutely massive applications built in unsafe programming languages, theyâre very performance-sensitive (thus vulns can sneak in during optimization) they deal with unimaginable quantities of very complicated untrusted data all day every day, much of which is executable code, theyâre probably the most often-used application on a userâs computer, and they have access to an extremely large amount of sensitive personal and financial information for most users. Thus the browser is one of an attackerâs most lucrative targets. No matter how secure (or not secure) a browser may be, attackers are going to be throwing their resources into finding security bugs that they can exploit. They succeed in finding issues often (Escaping the Chrome Sandbox Through DevTools is a particularly good article documenting how someone found one such issue). Thus we should assume if a browser is out of date, itâs already being actively compromised in the wild. Updates have to be very timely.
- Projects going unmaintained. This is an even worse issue than update lag, because if someone just stops maintaining their project, now we have an entire userbase using an eternally insecure browser, that we can assume is being actively exploited in the wild. Not good. There are lots of browser forks that have died - Bold Browser (previously a Brave fork, then an ungoogled-chromium fork) is one, Light (a Firefox fork I used on Puppy Linux some time back) is another. Migrating users off of an abandoned browser would be a nightmare from a technical perspective, and it would be something that would have to be done very very fast for user security. Weâd also have to actually know the project was abandoned, and if the project gets silently abandoned, it might not be possible to tell a truly unmaintained project from a project with a bad case of update lag. We would probably not be able to start migrating users to a different browser until they had been left vulnerable for a very significant period of time.
This basically narrows us down to the two big players in the browser world, and some of the better-known and better-maintained forks. I would consider Firefox (ESR), Chromium, Brave, IceCat, Base Browser, and maybe Trivalent (though secureblue is a somewhat new project and seems to be mostly run by one guy, so Trivalent could be dangerous even if it is amazing from a security hardening standpoint). Pretty much all of the others (Waterfox, Pale Moon, Floorp, Zen, potentially even Librewolf) are too scary for me. Iâm reticent to list even IceCat because last I checked (which was earlier today) there were only three people maintaining it. But there is the fact that GNU has some serious issues with non-free JS, so if all three maintainers were to vanish into thin air, I find it likely that GNU would find people to pick up where they left off pretty quickly.
All of the above browsers either definitely support both x86_64 and arm64 (Firefox (ESR), Chromium, Brave) or probably support x86_64 and arm64 (IceCat, Base Browser, maybe Trivalent though it has things with hardened_malloc involved so there might be some fun problems there). So architecture considerations arenât likely to be a problem here.
Getting the latest supported version of one of the above browsers may or may not be tricky:
- Firefox ESR - In Debianâs repos, good, we already use this. Has security concerns.
- Firefox - Mozilla offers an official repo for Debian Stable that provides the latest versions of Firefox (not ESR). However, I believe this only provides x86_64 builds, not arm64.
- Chromium - As covered above, there isnât any trustworthy, universal source for a pre-built Chromium deb package. Even if there was, it might suffer from update lag and maintenance issues very similar to a Chromium fork. Debianâs repos suffer with very bad maintenance problems with Chromium every so often.
- Brave - Offers an official repo for Debian Stable that supports both x86_64 and arm64.
- Base Browser - Not distributed in binary form at all, weâd have to extract it and build it ourselves.
- IceCat - Only distributed in source-code format and as a Guix package. I tried installing the Guix package earlier today, it was an absolutely horrible experience for a new user, plus that would require introducing a whole new package manager into Kicksecure. So effectively weâd have to build it from source.
- Trivalent - Binaries are only available for secureblue, the source is available and the build instructions are very Fedora-centric. Unsure how hard this would be to make work. Itâs also intended to work with hardened-malloc (which secureblue has enabled system-wide), if we wanted to get the full security advantages weâd probably have to ship hardened-malloc alongside Trivalent somehow which could be hard. We canât enable it system-wide because that caused serious problems in the past.
Of the above browsers, we probably want to avoid the Firefox ESR derivatives, since weâre already using Firefox ESR and are dissatisfied with it. That means Base Browser and IceCat are no good. Of the remaining options, I would omit Brave, because Brave has been caught doing worrisome things over and over again, injecting affiliate links into the address bar, hijacking ads, installing a VPN service without permission on Windows, and some other things. They may not be leaking data during normal use, but to me this seems kind of like installing bulletproof windows only to leave the front door unlocked and wide open. A service or app is of no use from a security or privacy standpoint if the creator canât protect their users from themselves. This is a shame because this is like the only well-maintained browser for Linux that supports arm64 and provides an official repo.
That means that if wweâre really going to try to avoid building anything from source, and we want to avoid Firefox ESR, we have one choice, which is to provide the official FIrefox binary on x86_64 and continue to use Firefox ESR on arm64. If we want to do anything beyond that (thatâs noticeably better than just using Firefox ESR anyway), we get to set up some build infrastructure of our own.
If we did go with the option of setting up our own build infrastructure (which I know is something weâve tried to avoid), probably a good starting point would be:
- Pick a browser. If we think secureblue is going to stick around into the future, Iâd pick Trivalent, otherwise vanilla Chromium is probably the best option.
- Try to build it locally. Chromium isnât easy to build locally, but it can be done, and Trivalent seems to go out of its way to make it fairly easy.
- Figure out how to automatically detect and attempt building it every time a new browser version is out. The Linux Mint people are probably the ones to talk to about this since theyâve been down this road and acheived success.
- Set up x86_64 and arm64 build infra for this. Realistically weâd probably have to use cloud services for this, which would incur some amount of cost.
- Ideally, we should not make this just part of the Kicksecure repos, but should maintain it in a separate repo that anyone can then use without making a FrankenDebian. Then whoever ends up down this road next can use what we provide for their project and this problem of âhow do I build Chromiumâ will finally be solved.
Last idea to discuss, I was working on updating the Wiki with more default browser info, and ran into an interesting project listed there called ffprofile (Kicksecure Default Browser - Development Considerations). I looked into this tool a bit, and it looks like the basic idea it implements is a really good alternative to the plethora of Firefox customization projects that are out there (which may be opinionated in ways we donât like and neither do our users). However, it has some serious problems with the way itâs implemented as a server-side app that that you download your chosen configuration from. Itâs also a pain to use locally. It might be worth taking that project and re-implementing it as a desktop app that users can use to quickly reconfigure Firefox to be more secure, with sensible defaults applied that would provide the configuration we think is recommended. Then the user would be applying the config themselves, which dodges the legal issues with customizing Firefoxâs configuration that have been discussed elsewhere.