Firefox ESR as the default Kicksecure Browser hardened with arkenfox user.js

[monsieuremre]

Not meant to merge yet. This is the arkenfox user.js file for version 115 (ESR). The only change is that "user_pref" instances are replaced with "pref", to make this a systemwide policy.

Whonix may prioritize anonymity before anything but the core os Kicksecure is meant to be a security first OS. It has already become clear that the TB won't be the default browser for Kicksecure like Whonix, obviously, because this is a daily driven OS.

@Thorin-Oakenpants's project makes security a priority. They make use of the newest security features that are in firefox like fission and they harden the security of the browser to the highest degree. I am under the impression that in terms of pure security, arkenfox hardened firefox is the best browser one could get. Mozilla has been making some good leaps to catch up with chromium browsers in terms of sandboxing and security. Most of these features are still being tested and in their early phases, but arkenfox enables them whenever possible.

The base OS Kicksecure should have firefox esr as the default browser, and have a system policy in place using this package, just like we have one for thunderbird. I see this as the best way. Our secure default browser option should be this.

Alternatively, Kicksecure can ship the Mullvad Browser (this might be the superior option anyway). It is already available as a tarball. Just like how we bundle GrapheneOS's hardened-malloc as a deb package in the repositories, the same can be done for the Mullvad Browser. I don't think any modifications on our end would be necessary at all for the Mullvad Browser.

[adrelanos]

Firefox hardening is a huge project. That's a project by itself. So I cannot maintain that. Attempted so previously and then deprecated.
(https://www.whonix.org/wiki/SecBrowser)

---

arkenfox:
Since this user.js is already maintained in a different repository with its own issue tracking, git history, it shouldn't really be copied over here. Better would be packaging it for Debian (or Kicksecure). A Debian RFP (request for packaging) would be useful.

---

Related wiki page:

• https://www.kicksecure.com/wiki/Dev/Default_Browser

---

Mullvad Browser:

Also an option to consider.

---

Packaging Mullvad Browser (MB):

• That would need to be done, maintained by upstream. Since MB is similar to TB (Tor Browser) where a .deb feature request is ~ 11 years old and rejected, my hopes aren't so high that this is going to happen. Happy to be wrong about this.
• Create deb/rpm packages mullvad/mullvad-browser#133
• Add rpm/deb package repositories? mullvad/mullvad-browser#201

---

Mullvad Browser Downloader:

related:

• Mullvad Browser support tb-updater#25
• Add support for Mullvad Browser tb-updater#26

---

Librefox? No idea. Didn't look into yet.

[monsieuremre]

Firefox hardening is a huge project. That's a project by itself. So I cannot maintain that. Attempted so previously and then deprecated.

The way I'm suggesting does not require full time maintenance on our end.

Since this user.js is already maintained in a different repository with its own issue tracking, git history, it shouldn't really be copied over here. Better would be packaging it for Debian (or Kicksecure). A Debian RFP (request for packaging) would be useful.

That won't work almost certainly. The project is meant to be a template. If you read the wiki, it is not a install and forget kind of thing, it requires some manual work on the user end (very minimal). I suggest we use this template, and literally just change one or two things there if necessary, and package it right here. The file itself is extremely good commented all the way. The wiki also is great to learn if we really need/want to change things. Whenever there is an update in the project, we update our 'base', and do our extra configs as usual. If you want a separate deb package, we can take it upon ourselves to it, because arkenfox maintainer will most likely not be doing this, as this is quite outside the scope of his project. But I really don't see no reason why we can't package arkenfox ourselves for the 'system' and not for one profile. It really is not difficult. There hardly ever big changes at all. And since we are on a LTS firefox release, we only get a new arkenfox file every 6 months. And chances are, not a lot will change on what we do with these updates, or maybe at all. I think this option is very doable and is the right choice.

When it comes to Mullvad Browser, it goes above and beyond arkenfox, as it is a separate browser, that is more based on the tor browser without the tor functionality, and it is in many ways better than TB in terms of modern web compatibility. This would be the best choice. But if not that, arkenfox is the next best thing.

Librewolf is a ok i guess. It is pretty much just arkenfox in compile time + ublock origin. It won't provide any real benefits over just doing arkenfox ourselves. And also librewolf can sometimes lag in terms of updates, which we probably do not want.

[adrelanos]

I don't want to get lost in the Firefox hardening rabbit hole at this point. Certainly needs an upstream to point to.

MB is more realistic and already has a ticket.

[adrelanos]

MB might come with its own issues...

• advertising a VPN
• maybe in the future enabling mullvad VPN by default
• not really technologically neutral

In any case something as complex, controversial, follow-up issues generating as a browser config shouldn't be mixed into security-misc.

Debian managed to package far more complex stuff than an alternative browser config. I'd be surprised if Debian would fail to ship reasonable defaults.

[adrelanos]

arkenfox seems pretty simple to package. (But not by copying over the file here.)

But there seems to be some fundamental ideological disagreements.

Paraphrasing:

Telemetry is nice let's keep it enabled.

source: arkenfox/user.js#1659 (comment)

This ticket implies that telemetry is still enabled:

• explain telemetry better arkenfox/user.js#1660

But the user.js shows telemetry disabled. This is confusing.

I wish there was a project that would not produce even my current comment. That sets reasonable secure and privacy preserving defaults. Disabling telemetry is a simple one. If there is not even consensus about this one, I think we need another upstream.

[monsieuremre]

maybe in the future enabling mullvad VPN by default

Most definetely not, it is stated as a clear project goal, but we will have to take their words for it, which I am willing to given their good track record.

not really technologically neutral

I happen to think it is.

Debian managed to package far more complex stuff than an alternative browser config. I'd be surprised if Debian would fail to ship reasonable defaults.

Depending on the debian team for security purposes is mistake. Debian teams values universality and compatibility beyond everything and anything else. This is the real underlying problem with having debian as the base.

arkenfox seems pretty simple to package. (But not by copying over the file here.)

A yessir, we would still need a fork repo tho. Some things would change. But yes, very easy to package indeed. I recommend kicksecure does it.

This ticket implies that telemetry is still enabled:
Absolutely no.

From the arkenfox project in the issue:

To be EVEN MOAR CLEAR ... disabling telemetry will stay - I simply want to differentiate it from privacy/tracking issues.

I am glad you are considering this possibility. I think this is the best options for shipping a browser. I created an issue upstream to see if the maintainer himself is willing to provide a system config file upstream. If he does, Kicksecure would just have to package the file and that would be it.

[adrelanos]

• Configuration File for a Full System Policy arkenfox/user.js#1795

[adrelanos]

Alright, so that ticket arkenfox/user.js#1660 is confusing but now I get it. It's not about enabling telemetry. Only about moving it to its own section in the config file. Which is more like a textual, stylistic change.

[Thorin-Oakenpants]

project makes security a priority. They make use of the newest security features that are in firefox like fission and they harden the security of the browser to the highest degree

Not true. Security can't really be improved upon, and we don't harden to the highest degree - you just end up with a broken web. We never turned on fission, we let that ride the trains with Firefox (as I do with a number of things, especially something like fission which really had to be release ready)

Edit: AF is a template with lots of advice on what you could do and what you shouldn't to effectively improve privacy and reduce tracking

[adrelanos]

arkenfox/user.js#1795 was closed but that's not a big deal. That could easily be handeld during the package build process with something like this:

search='pref("'
replace='user_pref("'
file_name='user.js'
str_replace "$search" "$replace" "$file_name"

The diff would be reasonable simple.

---

Thank you for commenting here. @Thorin-Oakenpants

[Thorin-Oakenpants]

I would suggest you disable the items in section 4500 - all the RFP stuff - it's not everyone's cup of tea, especially canvas breaking as it's becoming more ubiquitous across the web (FFS, google docs uses canvas to write text .. what a world we live in .. insanity .. or to upload an image it uses canvas ... sigh) - that's probably the worst one in terms of actual breakage. A few others will definitely throw users for a curve - such as times (depending on how the site handles date/times) being returned as UTC (so you will look up a cricket match and then miss it, or order pizza and it will arrive the following day, or send yourself emails from the future via web client to os/app client...)

I plan to make this section inactive anyway (soon!! maybe FF123 or FF124), because in ETP strict mode we now have FPP (fingerprint protection) which subtly randomizes canvas (per PBM/non-PBM session, per eTLD+1, per scheme) and doesn't break anything - and this is a good start/balance as it will foll foil a ton of FPing scripts - it will get more protections down the track

so if you're planning on pushing this out soon, at least do that or you'll have to add reams of explanations about RFP somewhere and deal with the fallout