Kicksecure Default Browser Discussion

[monsieuremre]

I think it should be considered to move applicaiton specific hardening to its own repository.

Even if this happens or not, consider firefox as the default browser. Hardening might seem like a big undertaking, but it's not. There is a more maintainable way to harden mozilla applications, and that is to set policies. This allows more than just setting preferences. There are many useful macros to disable studies and/or telemetry. Ping and crash reports can also be disabled within the policy easily with preferences. To demonstrate the possibility of control and also the ease of maintainability, I want to present the following policy I created for firefox:

{
  "policies": {
    "Bookmarks": [
      {
        "Title": "Kicksecure",
        "URL": "https://kicksecure.com",
        "Favicon": "https://www.kicksecure.com/favicon.ico",
        "Placement": "toolbar",
        "Folder": "Kicksecure"
      }
    ],
    "DisableFeedbackCommands": true,
    "DisableFirefoxAccounts": true,
    "DisableTelemetry": true,
    "DisableFirefoxStudies": true,
    "DisableFormHistory": true,
    "DisablePocket": true,
    "DisableSystemAddonUpdate": false,
    
    "EncryptedMediaExtensions": {
      "Enabled": false,
      "Locked": false
    },

    "ExtensionSettings": {
      "[email protected]": {
        "installation_mode": "force_installed",
        "install_url": "https://addons.mozilla.org/firefox/downloads/latest/ublock-origin/latest.xpi"
      }
    },
    
    "ExtensionUpdate": true,
    "FirefoxHome": {
      "SponsoredTopSites": false,
      "SponsoredPocket": false,
      "Locked": true
    },
    "FirefoxSuggest": {
      "SponsoredSuggestions": false,
      "ImproveSuggest": false,
      "Locked": true
    },
   
    "PasswordManagerEnabled": false,

    "PDFjs": {
      "Enabled": false,
      "EnablePermissions": false
    },
    
    "Preferences": {
      "browser.contentblocking.category": {
        "Value": "strict",
        "Status": "locked"
      }
    },
    
    "PromptForDownloadLocation": true,
    
    "SearchEngines": {
      "Default": "DuckDuckGo",
      "PreventInstalls": true,
      "Remove": ["Google", "Amazon"]
    },
    
    "SearchSuggestEnabled": false,
    
    "StartDownloadsInTempDirectory": true,
    
    "UserMessaging": {
      "WhatsNew": false,
      "ExtensionRecommendations": false,
      "FeatureRecommendations": false,
      "UrlbarInterventions": false,
      "SkipOnboarding": false,
      "MoreFromMozilla": false,
      "Locked": true
    }
  }
}

What is done:

• Remove all sponsor junk
• Remove telemetry
• Remove studies
• Force install ublock origin and lock it
• Enable ETP in strict mode and lock it
• Remove mozilla recommending and shilling random stuff
• Disable scripting and permissions for pdf viewer
• Kicksecure default bookmark
• Privacy respectin search engine
• Disable drm
• And some other stuff, more can be added, possibilities are limitless

For this vast amount of settings, I would agree the policy file is very intuitive and human readable and brief and maintainable. It is also very solid, it provides more possibilites than just global preferences for firefox. We can control addons and stuff. A similar policy file can be maintained also for thunderbird. Kicksecure can lock security related settings this way too, like enforcing strong cipher, ssl etc. settings and locking them.

Locking settings results in this: the user can't change the setting in the browser, not in settings, not in about:config, nowhere, it is locked. Disabling the policy is the only way to get rid of our defaults, if we wish so.

Now, I already have some several suggestions for policies for firefox and thunderbird. I guarantee you they are all human understandable and reasonably brief to maintain. I suggest having a separate repository for ease.

I already suggest, we reconsider the default applications Kicksecure ships. My comments:

• Thunderbird - Already good, should stay
• Firefox - Should be included (doubles as a secure pdf viewer)
• Hexchat - Thunderbird has IRC, so why have this. Also, IRC is not common place, shipping a default application seems superfluous.
• Bitcoin - Ok, understandable, maybe, niche, but passable
• Electron - Superfluous since btc core is already present
• Monero - Passable, I guess, but not necessary, like bitcoin
• VLC - good, vital component for daily usage, should stay
• Some Office - Unsurprisingly, an office suite is probably more seeked by an average user than hexchat

[EclipseBazooka]

I agree but I think policies should be included to lock down settings that could effect a Kicksecure users security and privacy while still keeping open settings the user might like to change. The policy should not achieve this while also trying to not alter the browser fingerprint as little as possible. A prefs.js should still be included to cover settings that are out of the scope or not supported in policies.

Good Job on the policy, these would be a good to add in addition to be cleaned up a little more.

Disable Automatic Updates this is an attack vector:

+     "AppAutoUpdate": false,
+     "ManualAppUpdateOnly": true,

My understanding is that firefox is updated through sudo apt upgrade? if so then "DisableAppUpdate": true should be set instead.

Clear all data on shutdown:

+     "SanitizeOnShutdown": true,

Do not offer to save logins:

+     "OfferToSaveLogins": false,

EnableTrackingProtection

+     "EnableTrackingProtection": {
+       "Value": true,
+       "Cryptomining": true,
+       "Fingerprinting": true,
+       "EmailTracking" : true,
+       "Locked": true
+     },

Block location and microphone permisions:

+     "Permissions": {
+       "Location": {
+         "BlockNewRequests": true,
+         "Locked": true
+       },
+       "Microphone": {
+         "BlockNewRequests": true,
+         "Locked": true
+       }

Cookies which should be equivilent to network.cookie.cookieBehavior = 1 and network.cookie.lifetimePolicy = 2

+    "Cookies": {
+      "AcceptThirdParty": "never",
+      "ExpireAtSessionEnd": true,
+      "RejectTracker": true,
+      "Locked": true,
+      "Behavior": "reject-tracker-and-partition-foreign",
+      "BehaviorPrivateBrowsing": "reject-tracker-and-partition-foreign",
+    },

Preferences:

+      "browser.cache.disk.parent_directory": {
+         "Value": "/tmp",
+         "Status": "locked"
+       },
+       "browser.dom.window.dump.enabled": {
+         "Value": false,
+         "Status": "locked"
+       },
+       "geo.enabled": {
+         "Value": false,
+         "Status": "locked"
+       },
+       "dom.battery.enabled": {
+         "Value": false,
+         "Status": "locked"
+       },
+       "media.navigator.enabled": {
+         "Value": false,
+         "Status": "locked"
+       },
+       "network.connectivity-service.enabled": {
+         "Value": false,
+         "Status": "locked"
+       },
+       "network.prefetch-next": {
+         "Value": false,
+         "Status": "locked"
+       },
+       "network.dns.disablePrefetch": {
+         "Value": true,
+         "Status": "locked"
+       },

[monsieuremre]

Few problems.

• "AppAutoUpdate": false,
  

This is already taken caren of in compile time for debian packages. So whether we set this or not, it is not going to try to auto update anyway. No auto updates take place, already. These settings have no effect in either case.

• "EnableTrackingProtection": {
  

This is superfluous and possibly harmful because browser.contentblocking.category is set to strict and locked. Dynamically setting these makes us custom, which is subject to change over versions. Sticking to strict is a universal solution that covers the newest options in newer version automatically. Should stick to strict.

• "Cookies": {

For the same reason definetely superfluous and possibly harmful. Strict mode takes care of cookies. They are all partitioned. Rejecting third party serves no purpose. Expiring at session ends is normally better probably, you are right, but this is better left to the user to decide, because we probably want the browser to be daily driven.

• "SanitizeOnShutdown": true,
  

Same. Maybe. Better left to the user to decide. We want the browser to be daily driveable, I suppose.

• "Permissions": {
  

Most definetely not a good idea. All permissions are already prompt. If user does not allow explicitly, no harm is done. Having deny defaults changes the fingerprint. Unnecessary at best, harmful at worst.

We are not actively trying to defend against fingerprinting tho I suppose, thats why not setting RFP. We just use ETP strict and default their fingerprinting protections, which are like good for most non complicated fingerprinting. But if the maintainer decides firefox is the way, and he decides to go full RFP, then these settings would do a lot more harm.

geo.enabled media.navigator.enabled dom.battery.enabled

For the same reasons, I think unnecessary at best, harmful at worst. If we want to cover all of these we can just use RFP, which takes care all of these. In that case, changing these settings would definetely do more harm, as it would alter the fingerprint. If we decide to not go RFP, then they are non-necessary, and non benefitial, and cause more harm than good possibly.

network.connectivity-service.enabled network.prefetch-next network.dns.disablePrefetch

These are important and good. They should be included. Thanks.

Before anything, on the current form, before making any suggestions, @adrelanos should decide whether he likes the idea first. I think our chances are not bad, because this is some really human readable and easy to maintain file. But should wait and see.

[adrelanos]

I think it should be considered to move applicaiton specific hardening to its own repository.

That could and probably should done together with:

• https://github.com/Kicksecure/security-misc/issues/187

The packaging upgrade path might be difficult.

• Migration from security-misc to security-misc-shared is simple because security-misc-shared can declare Replaces: security-misc.
• But not sure if a package named (named what...? security-apps-config) could at the same time also use Replaces: security-misc.

Even if this happens or not, consider firefox as the default browser.

Already default.

Hardening might seem like a big undertaking, but it's not.

If I look at arkenfox, that's daunting. And I am not sure yet how much is accomplished.

Somebody [1] sent me a screenshot of LibreWolf's connections at each startup using OpenSnitch. Librewolf connects to ~ 11 different servers. Each of that server gets a free delivery of the users's external IP address every time the browser is started. That's just after startup. When watching the browser long, there's probably more. Far away from a radio silence mode.

Creating a (maybe mission impossible) project "tame Firefox to respect privacy" could easily be too much to maintain. And there's already a huge backlog of other improvements to be done (apparmor.d, ISO, whatnot, ...)

So rather I want to look into other upstream projects. There's a lot. 1) LibreWolf, 2) Librefox, 3) arkenfox, 4)... (In no specific order.) I want to review these one day with OpenSnitch and then post a bug report or feature request to implement radio silence and see what they say.

The secure Firefox implementation is further complicated by combining this with installing newer versions from Flathub.

So to make it abundantly clear...

1. Work with upstream first.
2. Work with upstream first.
3. Same as above.
4. You get the idea.

Only when there's no upstream or attempt to find consensus with upstream reached an impasse, consider forking things. 1), 2), 3), 4)... aren't even close to being exhausted yet.

[1] I sufficiently trust to not make this up from thin air and also a lot stuff sounds plausible (easylist, tracking-protection-cdn.mozilla.net, malware,-filter.gitlab.io, oscp.globalsign.com, and much more).

There is a more maintainable way to harden mozilla applications, and that is to set policies.

More maintainable but also more limited?

, I want to present the following policy I created for firefox:

{
  "policies": {

Nice syntax, there would be a lot details to discuss but I want to exhaust options working with upstream first.

I already suggest, we reconsider the default applications Kicksecure ships. My comments:

Some of it is easy to immediately agree with. But needs to be discussed in the forums for wider community input.

github isn't the place for this.

• Hexchat - Thunderbird has IRC, so why have this. Also, IRC is not common place, shipping a default application seems superfluous.

I don't mind much about HexChat nowadays that there's no IRC based project support anymore.

• Bitcoin - Ok, understandable, maybe, niche, but passable
• Electron - Superfluous since btc core is already present

Electron? You mean electrum?

Bitcoin Core isn't in Debian stable and never will be. Also hard to use for many reasons. (No mnemonic phrase backup, long time to sync chain.)

[adrelanos]

@EclipseBazooka's comment is interesting, certainly worth discussion. (I didn't check the merit of the different arguments.) However, that also makes the point that this is quickly getting far more complex, for more details than I am ready to deal with.

@monsieuremre did you consider maintaining your own upstream Firefox settings hardening project? Ideally make it genmkfile friendly. That basically just means put the file in a sub folder where it would actually be deployed such as /etc/firefox-esr/. But that's optional. Even more optional if it's only a very limited amount of files.

Maintain and promote this project independently of Kicksecure. Then Kicksecure would have an upstream to point to.

Once ready, Kicksecure (and Whonix with the correct phrasing) can help to promote the project through its usual channels to get users, reviewers.

Then I would open the "radio silence" feature request and see what you think about this. I think a Firefox improved privacy settings project should ship all needed configs (such as adblock lists) so these don't need to be downloaded over the internet from a different source. Keeping external connections to a minimum.

Otherwise, maybe even better, consider contributing to some of the many Firefox settings projects and see how that goes? Then this could become upstream for Kicksecure.

[monsieuremre]

@monsieuremre did you consider maintaining your own upstream Firefox settings hardening project? Ideally make it genmkfile friendly. That basically just means put the file in a sub folder where it would actually be deployed such as /etc/firefox-esr/. But that's optional. Even more optional if it's only a very limited amount of files.

Can do. For thunderbird too. Would rather contribute to a repo here tho. And by contributing, I mean I can write it from the ground up for kicksecure.

Somebody [1] sent me a screenshot of LibreWolf's connections at each startup using OpenSnitch. Librewolf connects to ~ 11 different servers. Each of that server gets a free delivery of the users's external IP address every time the browser is started. That's just after startup. When watching the browser long, there's probably more. Far away from a radio silence mode.

This is a very bad take IMO. Librewolf is pretty much arkenfox with ublock origin in compile time. All the connections are harmless. Telemetry of any kind is very disabled to the bones. There are certain connections we will make too after the hardening, the same ones as librewolf probably. A small list:

• We allow ublock origin to connect to respective sources to update the filters.
• We allow firefox ETP to make connections to mozilla to update the ETP lists and filters.
• Firefox makes connections to google data base and stuff to update the safe browsing block list. (Libreoffice disables this one, but we can decide on our own)
• Connections will be make to mozilla addons thing to update ublock origin whenever necessary.
• Connections will be make to places to update certificates and stuff.

Then I would open the "radio silence" feature request and see what you think about this. I think a Firefox improved privacy settings project should ship all needed configs (such as adblock lists) so these don't need to be downloaded over the internet from a different source. Keeping external connections to a minimum.

Can't be done without losing efficacy. These lists are heavily maintained. Especially on mozillas part, for fingerprinting protection and stuff, they are active and adding new things. Not to mention ublock needing to update itself regularly to ocntinue working on youtube, especially nowadays.

And all the hardening that is done, these connections are part of it. Assuring that every outgoing connection is encrypted is our part as ensuring security. These services have decent privacy policies that declare ip addresses or other metrics are not used to track or anything.

The secure Firefox implementation is further complicated by combining this with installing newer versions from Flathub.

You don't say. I'm not even sure the flatpak respects the system policy. Gonna have to test that.

If I look at arkenfox, that's daunting. And I am not sure yet how much is accomplished.

That is daunting because it seems long. But if you read it, it is a really simple piece of text. Main reason of the length is that it is really really well documented. Some settings are already the defaults, they are written just to document the reasoning, some are the default and there because they were different on previous versions of arkenfox, so they allow updating. Most anything is commented out. That is why arkenfox is really more like a really good template to use, to choose and create our own config. Policies can achieve more than a user.js file btw, because we can add addons for example and so on too.

[EclipseBazooka]

@monsieuremre

Well ok i'm kinda confused but like I said the policy should lock settings that could effect the users security or privacy if changed while still leaving user control up to basic things. I am not trying to argue if it sounds like that but just to understand more as I agree that you don't want to have conflicting settings.

I do however think the policy should lock down these things within reason:

• Disabling Firefox telemetry

• Locking down security settings

• Locking down privacy settings (location services & fingerprinting for example)

"AppAutoUpdate": false, This is already taken caren of in compile time for debian packages. So whether we set this or not, it is not going to try to auto update anyway. No auto updates take place, already. These settings have no effect in either case.

Yeah i'm thinking of Tor Browsers stupid choice of coming with auto updates enabled

This is superfluous and possibly harmful because browser.contentblocking.category is set to strict and locked. Dynamically setting these makes us custom, which is subject to change over versions. Sticking to strict is a universal solution that covers the newest options in newer version automatically. Should stick to strict. https://mozilla.github.io/policy-templates/#enabletrackingprotection

privacy.trackingprotection.enabled privacy.trackingprotection.pbmode.enabled privacy.trackingprotection.cryptomining.enabled privacy.trackingprotection.fingerprinting.enabled

These are the prefs that are effected and yeah on second look it should not be locked, if the locked part is not set it will be eqivilent to Status: user which will set them every time browser is launched but allows for user to toggle them off or on if need be.

"SanitizeOnShutdown": true,

This should be set as their is no reason to store cache, cookies or browser history past current session.

That is why I set the cache directory to be in /tmp since Kicksecure sets /tmp to tmpfs so this would make the cache in RAM if i'm correct?

+     "Permissions": {
+       "Location": {
+         "BlockNewRequests": true,
+         "Locked": true
+       },

and:

+       "geo.enabled": {
+         "Value": false,
+         "Status": "locked"
+       },

Should be set since Kicksecure removes geoclue it would make sense to also disable any kind of geo location services in the browser.

Also I'm kind confused as if Librewolf comes shipped these would not effect fingerprint since Librewolf already has a unique fingerprint and these prefs are already set in them.

Some things are out of the scope of mozila policies and you mention including uBlock orgin which is also included in Librewolf i believe?

for example I think JIT is disabled in Librewolf:

 javascript.options.asmjs = false
 javascript.options.wasm = false
 javascript.options.ion = false
 javascript.options.baselinejit = false

This is debated to make the performance better for the uBlock extension if JIT is disabled:

javascript.options.jit_trustedprincipals

[EclipseBazooka]

@monsieuremre

Thunderbird - Already good, should stay

Thunderbird can also be locked down with a policy like these two important settings:

+{
+  "policies": {
+    "Proxy": {
+      "Mode": "manual",
+      "Locked": true,
+      "SOCKSProxy": "127.0.0.1:9050",
+      "SOCKSVersion": 5,
+      "UseProxyForDNS": true
+    },
+    "Preferences": {   
+      "mail.smtpserver.default.hello_argument": {
+        "Value": "[127.0.0.1]",
+        "Status": "locked"
+    }
+  }
+}

• Forcing locking thunderbird to use Tor (Since Kicksecures relies on Tor for updates-over-tor) to pretect users IP.

• Preventing the smtp server from leaking the clients IP even though its using Tor which has been an issue in the past in Thunderbird

taken from Tails thunderbirds prefs

[adrelanos]

What is the rationale behind locking settings? Setting secure defaults for the user is OK but we shouldn't add extra hurdles for a user who wants to customize that.

radio silence:

• Google, Mozilla, Cloudflare and who knows who else get everyone's IP every time a browser (which is mostly Firefox, Chromium based) gets started.
• How would it sound if Google, Mozilla, Cloudflare said: "We want everyone's IP address every time they start their browser."? Sounds creepy.
• Hence, for minimum privacy, all of the required file updates (adblock lists, ...) should
  • A) ideally be delivered through the package manager; or
  • B) at least be downloaded over Tor.

[adrelanos]

These connections...

• The IP address leaks the approximate location to these companies. There's even Open Source databases with this information. We can assume that private companies specialized in data mining have even better databases.
• Time of usage patterns. Means a human was active at exactly that time.
• Lets say someone has the habit of reading the news at 7:00 AM. This happens every day until one day it does not happen. This indicates some sort of habit change, special occasion, whatnot. None of the business of one of these companies.
• We can assume that most users start their browser when they start their computer.
• This data can be combined with other data leaked through normal browsing and browser fingerprinting.
• It's similar to a "ping".
• The end result is similar to saying every time "Hi Google, it's me, first name, last name, social security number, I am right now physically at using this this specific ".
• Data collection can go one for decades with people employed full time to think about how to profit from this data.
• It's prudent to assume that this data will or at least could be utilized to the fullest extend possible.
• Most users using Google Android (and probably similar for iOS) have "enhanced" GPS activated. Meaning the phone scanning for Wifi, Bluetooth. This was used to be called "wardriving". Google is the biggest war driver ever as most people driving around with these scanners all the time. The data harvesting by phones is also massive. This data can be combined with the "pings" from desktop browsers.
• The only defense is to avoid this data falling into the wrong hands.
• Phrased differently: Don't dox users behind their back before they have a chance to dox themselves.

@monsieuremre did you consider maintaining your own upstream Firefox settings hardening project? Ideally make it genmkfile friendly. That basically just means put the file in a sub folder where it would actually be deployed such as /etc/firefox-esr/. But that's optional. Even more optional if it's only a very limited amount of files.

Can do. For thunderbird too. Would rather contribute to a repo here tho. And by contributing, I mean I can write it from the ground up for kicksecure.

Better to have it generic (unspecific to Kicksecure) to have more users and contributors looking at it.

There should be very little (hopefully nothing) Kicksecure specific.

Default project homepage is defined by package kicksecure-welcome-page file /etc/firefox-esr/30_kicksecure-welcome-page.js - so no need to do it in a Firefox security/privacy settings project.

cat /etc/firefox-esr/30_kicksecure-welcome-page.js

pref("browser.startup.homepage", "/usr/share/doc/homepage/kicksecure-welcome-page/kicksecure.html");
pref("startup.homepage_welcome_url", "")

related:

• https://github.com/Kicksecure/kicksecure-welcome-page
• https://forums.whonix.org/t/kicksecure-landing-page-developent/8001

{
  "policies": {
    "Bookmarks": [
      {
        "Title": "Kicksecure",
        "URL": "https://kicksecure.com",
        "Favicon": "https://www.kicksecure.com/favicon.ico",

Bookmarks are not important enough to make this a Kicksecure specific package. If really neeed. Kicksecure could ship a different file or - hopefully not - have a small fork that file.

[monsieuremre]

Wakey wakey. New repo now available.

Policies created for firefox and thunderbird. Both tested locally on my machine. Real good real nice. Do your suggestions there please.

Also @adrelanos, firefox apparently released their official deb package (very recently). You know, if we want firefox instead of firefox-esr, now we have an official deb repo.

[EclipseBazooka]

What is the rationale behind locking settings?

• Scenario A.

User acidently changes settings in about:config or settings menu that effect their security and or privacy and forgets about them. Then goes on to then be using said unsecure or not private setting going forward and never finds out or finds later on they were.

• Scenario B.

User goes shopping online and saves their form data (which could include passwords, credit cards, and addresses) unknowingly or forgets they did to then realize later on its been saved the whole time. This is default in most web browsers including firefox I believe and could effect a users privacy and security if an attacker got ahold of this.

but we shouldn't add extra hurdles for a user who wants to customize that.

Yes, thats why a hardened good default or anything better then default prefs.js or user.js should be shipped with firefox but certain things like in scenarios above should be locked to never allow changing.

When it comes user customization and usability a policy should be very minimal so users can change their settings in prefs.js or user.js how they wish while also locking down things to prevent user error or protect them like form data and password manager from even being able to be saved/enabled in the browser.

Same can be said for Thunderbird with a policy. You can have locked down prefs shipped but then moment the user starts changing setting, then the local prefs in ~/home are prioritized over anything in system wide to be used so a policy to lock down settings that could harm an end user could be set while still keeping customization open. Sadly there is no prefs or policy setting for profiles to be launched at start to be the default which I think is better for compartmentlization of different emails with different settings. Like one profile you may want to only connect through tor and only open links via tor browser while another like jobs/banking or a work email you may want to open with another browser.

[EclipseBazooka]

@adrenlanos You are probably one of the few devs and project maintainers that seems to get it. Sadly many projects are loosing site of the things that do matter by instead focusing on politics or being politically relevant.

Google, Mozilla, Cloudflare and who knows who else get everyone's IP every time a browser (which is mostly Firefox, Chromium based) gets started.

+{
+  "policies": {
+    "CaptivePortal": false,
+  },

and like I mentioned above:

+     "Preferences": {
+       "network.connectivity-service.enabled": {
+         "Value": false,
+         "Status": "locked"
+       },

should be locked and the geo.enabled should be and maybe location permissions also. Most distros ship firefox with its default setting which also include google as the default search engine.

[EclipseBazooka]

Somebody [1] sent me a screenshot of LibreWolf's connections at each startup using OpenSnitch. Librewolf connects to ~ 11 different servers. Each of that server gets a free delivery of the users's external IP address every time the browser is started. That's just after startup. When watching the browser long, there's probably more.

Here are some tests on different browsers telemetry: https://spyware.neocities.org/ https://sizeof.cat/post/web-browser-telemetry/

[monsieuremre]

should be locked and the geo.enabled should be and maybe location permissions also.

Permissions are detectable. By default they are all prompt. Setting them default deny provides no benefits other than altering the fingerprint.

Most distros ship firefox with its default setting which also include google as the default search engine.

Telemetry is disabled to its core and default search engine is ddg, in the current policy in the repo I shared.

Google, Mozilla, Cloudflare and who knows who else get everyone's IP every time a browser (which is mostly Firefox, Chromium based) gets started.

All the remaining connections are strictly functional and non-telemetry. No sensitive data leaves the browser. What sites are visited or what cookies are blocked are not shared. Once in a while we connect to mozilla and update our fitlers locally. This not only provides mozilla with no information, it really is no different than just visiting the mozilla sources yourself and downloading them. Ip address in this case is useless, because there is no information tied to it in any sense. Torifying this traffic is litreally of no use, other than extra overhead.

This data can be combined with other data leaked through normal browsing and browser fingerprinting.

No it can't. This data can not even be combined with its own use case, which is blocking web content. Mozilla does not know which part of the filters we use, it is done locally.

Ip address in normal browsing is a highly unreliable and inefficient method of tracking. Because it is not 1995 anymore. An ip address cannot be associated with a device. It changes regularly. It shared by a pool of people. These are why no one uses ip addresses to track anything on the web. And even if they did, it still does not allow combining the data with first example (getting the filters), because there is no data in the first example.

[monsieuremre]

Closing this issue to move to a dedicated repository as suggested by @adrelanos.

[adrelanos]

As the the radio silence feature, I am currently preparing a feature request with detailed reasoning why I think that is a must have development goal (even if we need to admit that it is infeasible to be implemented, browsers nowadays cannot be tamed).

What is the rationale behind locking settings?

• Scenario A.

User acidently changes settings in about:config or settings menu that effect their security and or privacy and forgets about them.

Is it even possible to change settings in about:config if these are locked in policies.json?

I've seen Firefox policies (and locking) only in context of Enterprise, used also by corporations wanting to restrict their employees.

about:config already comes with a conspicuous notice. Users going that route should not be restricted from doing so.

Messages such as Your organization has disabled the ability to change some options. that Firefox will show then when using locked policies seem inappropriate outside an Enterprise context.

but we shouldn't add extra hurdles for a user who wants to customize that.

Yes, thats why a hardened good default or anything better then default prefs.js or user.js should be shipped with firefox but certain things like in scenarios above should be locked to never allow changing.

When it comes user customization and usability a policy should be very minimal so users can change their settings in prefs.js or user.js how they wish while also locking down things to prevent user error or protect them like form data and password manager from even being able to be saved/enabled in the browser.

It's quite a heavy restriction to disable password saving in the browser.

[monsieuremre]

It's quite a heavy restriction to disable password saving in the browser.

Yeah that can be removed.

[raja-grewal]

For what its worth, I also agree that when it comes to web browsers, it would be a much better to exhaust all possible avenues in working with upstream before shipping custom hardened browser configs.

Modern web browsers are very complicated beasts. I am sure your custom configs work perfectly fine today (and would very likely be just as great tomorrow and also the day after). However, over the long run this specific maintenance burden has the potential to become a crippling bottleneck when shipping new releases.

Given that web browsing is one of the primary activities people will the OS for, I think it would be far wiser to select an existing well-maintained project that is on roughly the same page when it comes security and privacy. If such a project does not exist, we should first try our absolute best to assist in including missing desirable features in existing browsers.

At this point, in my opinion I think Librewolf is probably a great starting-point. It is ships Firefox updates very quickly, has sensible defaults (made even better by also enabling ResistFingerprinting), and approachable contributors.

[adrelanos]

Yes. Working with upstream(s), and there are many, hasn't been exhausted yet.

---

https://github.com/monsieuremre/deskapps-harden

I would suggest to:

• rename the repository into something browser / Firefox specific (but of course without violating any trademarks) for better impact (by comparison, LibreWolf, LibreFox, sounds catchy but these are already used by others)
• some promotion (post on reddit, hacker news, whatnot) to get users and reviewers

Feature request if it can be called that:

• Suggest to other upstream's to use policies instead of user.js. I would need to see some discussions if that is approximately the same or the one being better than the other.

[monsieuremre]

Suggest to other upstream's to use policies instead of user.js. I would need to see some discussions if that is approximately the same or the one being better than the other.

One is not better, there are different use cases. Policies are for enterprises originally but are more powerful than js pref files and can be used daily, as the documentation makes clear.

Yes. Working with upstream(s), and there are many, hasn't been exhausted yet.

When it comes to upstream, please let me exhaust some of the options for you. Firefox Forks

• Firefox itself: Unironically good and getting better in terms of security and privacy. Has problems with telemetry and studies and pings. Metrics are anonymized and whatnot but a lot is still collected. Does not protect the users privacy that well from mozilla itself, so to say.
• Arkenfox: Very good, but the dev won't package for system wide configs and/or policies
• Librewolf: Literally just arkenfox+ublock origin but in compile time and settings are locked. not much different then what we would get with a policy. devs are real good and they often contribute to arkenfox etc. updates are understandably slower, sometimes really slow. they have had a bad raputation of shipping security updates really late. I have no experience regarding that. This may or may not be fixed as of know, I have no idea.
• Any other firefox fork: Garbage

Tor Browser Forks

• Tor Browser itself: Uses tor, so no. Not suited for daily usage. Also in many aspects unusable because e.g. webaudio is disabled. Eventho webaudio is completely protected with rfp with the current firefox. They will enable it probably with the next TB release, but still. It still uses tor and that is big not usable, bad.
• Mullvad Browser: More usable than TB, blocks ads too, so real nice. No telemetry or anything whatsoever (literally). Big time fingerprinting protection, the only other browser that protect your FP because everyone has the same. Literally the best option here. Also maintained by the tor team and mullvad team together. (big maintenance, they won't randomly disappear)

Conclusion If you want the best option, mullvad browser hands down, no discussion. Don't want mullvad brand? I don't know, just rebrand it i guess. It is not tied to the vpn product at all, only the name. It is not, and will never be, a mullvad vpn routing tor style browser. If you want upstream, take MB and rebreand it or whatever and package it as deb (or don't package it, whonix does not package TB, it just uses the tarball, no? same can be done with MB).

If you don't want MB, everything indicates a custom policy as the best option.

[raja-grewal]

Recall that one critical difference between Firefox (and its respective forks) and the Mullvad Browser (MB) is the base version of Firefox. For simplicity, let us assume Firefox is unsuitable due to telemetry while all its security and privacy improvements are implemented and improved on in Librewolf .

Firefox (and Librewolf) naturally use the current stable build while MB uses the ESR (as it is a fork of the Tor Browser).

Conclusion If you want the best option, mullvad browser hands down, no discussion.

In my eyes at least, definitively stating that using the ESR base for Kicksecure is unquestionably superior to the stable release is not a claim I would be willing to so confidently make.

For example, if we want native Wayland, it was introduced only last month in 121.0. While they do ‘promise’ to backport security fixes, newer features for both hardening and privacy may not be added till the next ESR. This situation can lead to both positives and negatives as newer features may either increase or reduce the attack surface.

Regarding Librewolf’s slow updates, I think this issue has been very greatly exaggerated, having used it as one of my browsers for almost over 30 months, I personally do not recall it ever really being more than one week behind Firefox, usually it is only a couple working days at worst.

Additionally, for MB, having letterboxing (fingerprinting protection) by default is something many users might find very undesirable despite its clear objective benefits when it comes to privacy. However, given we have no telemetry it would be challenging to obtain community feedback. Personally, I am not sure shipping this as a unchangeable default should be done without some actual data backing the decision. Though, chances are people will probably get used to it and their continued use will benefit everyone using the browser.

I think either Librewolf or MB would be a great choice if we want to move away from Firefox in order to ship more sensible defaults across the board.

Some of the key deciding factors between the choice would be:

• Firefox stable vs. ESR,
• The degree of fingerprinting protection forced on the end-user,
• Associating with a either community-driven project or the Mullvad brand, and
• Ultimately whether we actually want to be reliant on something downstream from Firefox.

[monsieuremre]

In my eyes at least, definitively stating that using the ESR base for Kicksecure is unquestionably superior to the stable release is not a claim I would be willing to so confidently make.

Oh you are 100% right. Absolutely. That is the one catch. This has its possible issues, but it also has some benefits. ESR release cycle makes fingerprinting resistance much more effective. And MB, like the TB, is very strong against fingerprinting.

Additionally, for MB, having letterboxing (fingerprinting protection) by default

Yeah this one is just like looks. The tor folks are working on making letterboxing look more natural and purposeful. Letterboxing is not noticable on devices with high pixel ratio, where the screen uses like more than 100% scaling. Even with non dense devices, I can live with it, but I understand that a lot of users might be bothered by it.

RFP makes little sense without letterboxing. If we want to avoid that, then we have to stick to FPP, which is also decent and getting better. That's what I do in my own policy for example.

Sidenote: I think keeping the firefox branding and improving upon it might be more user friendly than shipping unpopular brand browsers.

[adrelanos]

Primary importance for Kicksecure must be security. Anti-fingerprinting is nice but secondary. Disabled telemetry can be considered a security feature since it lowers attack surface and a privacy feature.

Arkenfox: Very good, but the dev won't package for system wide configs and/or policies

dev won't package for system wide configs and/or policies: non-issue as per: https://github.com/Kicksecure/security-misc/pull/183#issuecomment-1895948795

Sidenote: I think keeping the firefox branding and improving upon it might be more user friendly than shipping unpopular brand browsers.

This is one of the most convincing arguments for me.

---

Librefox?

https://github.com/intika/Librefox#ijwy-i-just-want-you-to-shut-up

IJWY (I Just Want You To Shut Up) This is a set of settings that aim to remove all the server links embedded in Firefox and other calling home functions in the purpose of blocking un-needed connections. The objective is zero unauthorized connection (ping/telemetry/Mozilla/Google...).

---

Since this is a difficult decision with a lot pros and cons, now keeping track in the wiki with hopefully most arguments: https://www.kicksecure.com/wiki/Dev/Default_Browser#Comparison_of_Browsers

[adrelanos]

Enabling non-freedom software DRM is just 1 click away even if using Debian's Firefox package. When visiting a DRM test website with Firefox:

You must enable DRM to play some audio or video on this page. Learn more [Enable DRM]

Which projects take such things serious and disable it by default?

---

settings locking: Can Firefox add-ons change settings which are already modified in user.js (by system or user) but not locked by policy?

[adrelanos]

I am afraid we most likely won't be able to

1. use Firefox from packages.mozilla.org or Flathub, and
2. harden it with Firefox settings hardening project such as arkenfox user.js or similar,

due to Firefox Potential Legal Risk (Trademark Violation).

Unbranded, recompilation would be too much effort at this stage of project development.

[monsieuremre]

I am afraid we most likely won't be able to use Firefox from packages.mozilla.org or Flathub, and harden it with Firefox settings hardening project such as arkenfox user.js or similar,

I do find this hard to believe. Then how come it is the case that

• Practically all distros package firefox to their liking, including adding custom homepages and changing settings and preferences
• We can ship Mozilla Thunderbird, which is by all means affected by the same trademark problems if anything

Does not seem to add up.

Can Firefox add-ons change settings which are already modified in user.js (by system or user) but not locked by policy?

Yes, shipping addons is a bad idea tho for many reasons.

Enabling non-freedom software DRM is just 1 click away even if using Debian's Firefox package.

This is how it should be. Enforcing freedom forcefully is makes the product less free, ironically. If the user chooses to enable drm, let them be. There are enough warning, and we can add our own custom warning message here with the policy if we want to.

Which projects take such things serious and disable it by default?

Me in my repository. See the lines in my policy:

"EncryptedMediaExtensions": {
 "Enabled": false,
 "Locked": false
  },

Locking it is one word away, but I am not a fan of the idea.

I just want to say, of course I am biased but, I think this is just really not hard to understand and/or maintain by any means.

There are few things I lock. I lock https-only mode, I lock https upgrades and mixed content. I lock strict ETP mode. That's it. Looks like to me that the policy locks security relates settings only. I also lock telemetry and studies. Don't know, you tell me, but I think that's only fair for a secure system.

[adrelanos]

The trademark chapter was updated with more content. Not sure you already saw that version. But will copy the most relevant things in here.

Mozilla went hard versus phyrox-portable (formally firefox-portable), which is (forgive my ignorance, never seen before) probably a small project judging from at time of writing 313 followers on github:

But even modest changes to preferences (such as whether "Know Your Rights" information is displayed to users) are sufficient to violate our policy against distributing modified versions of Mozilla software with our trademarks. Of course, end-users may choose to change preferences and settings in Firefox. But we don't allow others to distribute unofficial versions of "Firefox" with modified configurations or preferences.

source: phyrox-portable published an e-mail from a Mozilla attorney.

Well, Mozilla at least gave 30 days to come into compliance and didn't instantly file a lawsuit, which is nice. But when having bad luck, 30 days can easily pass without reaction in case of sickness, accident or other real life issues without any activity and in a lawsuit might actually be filed or the project kicked from github due to trademark violation report and whatnot. Not a risk that I am willing to easily take on.

LibreFox developer mentioned legal issues in https://github.com/intika/Librefox/commit/45a4d3ce647b8c896e81ce3e5ac5ddc95ff045e0 and then never heard again from on github commenting on LibreFox. Assumed still alive however since developer website linuxhacks.org still active and also active on stackexchange.

Changes requiring Mozilla’s prior written permission include (but are not limited to):

Changing the default home page or adding bookmarks,

source: Mozilla Trademark Distribution Policy

So Mozilla trademark policy and reported enforcement actions, that is Mozilla contacting downstream projects, seems to be in alignment. So caution seems to be justified.

To illustrate my point if arguing against that: Would you you willing to be non-anonymous, to take on full responsibility, pay all legal expenses, fines, and/or attend court? I am just mentioning this because it's easy to talk but might change when considering being the one being on the hook.

Just now checked. Debian doesn't change Firefox's default homepage. Debian's Firefox settings changes are minimal. Any distribution that does? In that case, could consider reporting a bug and pointing to Mozilla trademark policy.

Also while Debian doesn't want it, I would assume that Debian due to its size and overlapping connections get more benevolent treatment from Mozilla.

Is there any Linux distribution that majorly modifies Firefox, while not unbranding of course), that does one or multiple of the following, disabling all telemetry, disable all background connections, security hardening, anti-fingerprinting? I am not aware of any.

Yet another precaution can be contacting Mozilla directly and asking about this.

I mean, I can even understand Mozilla. They don't want users reporting broken Firefox functionality, which can easily be caused by some browser hardening settings, blamed on Mozilla, their reputation harmed, while it's caused by a fork or distribution.

If it's an issue, then a Firefox settings project could be packaged, installed by default but not enabled by default. The user would have to enable it by default as an opt-in. setup-wizard-dist (first boot wizard) could ask about this. Ugly and best avoided. But that would probably a legally secure workaround because users are permitted to change Firefox settings, even if the tool used to so is simple to use. And distributions cannot be banned from making these tools easily available.

---

Yes, shipping addons is a bad idea tho for many reasons.

Not only shipping addons. Also user installed addons might justify that it is better to lock some settings? Just speaking theoretically without actually known examples.

and we can add our own custom warning message here with the policy if we want to.

How?

[raja-grewal]

setup-wizard-dist

This link is broken due to a minor error (missing 'https:/').

Should be setup-wizard-dist instead?

[monsieuremre]

Well, Mozilla at least gave 30 days to come into compliance and didn't instantly file a lawsuit, which is nice. But when having bad luck, 30 days can easily pass without reaction in case of sickness, accident or other real life issues without any activity and in a lawsuit might actually be filed or the project kicked from github due to trademark violation report and whatnot. Not a risk that I am willing to easily take on.

That's really interesting what you posted there @adrelanos. That really suggests there might be real problems.

However, I can't help but notice, how is this allowed then. Tumbleweed distributes a firefox with modified preferences, including modifying the homepage to feature their search engine. Name of the package is still firefox. So they have Mozilla's permission maybe? Or another example. Like these people can distribute their custom preferences version of firefox. So there has to be a boundary there obviously to what is allowed or not.

I guess we can at the very least try our shot to get permission from Mozilla? There are no malicious intentions and they seem to be allowing things in reasonable boundaries to a degree, and whonix is not a no-name random project. I think your chance of getting permission from Mozilla might be higher than you think.

And also, I also want to underline the fact that we are not distributing a modified firefox here. That was not the idea. We would be packaging a system policy as a separate package. I don't know if this counts or where it falls. Like if kicksecure packaged a modified firefox with good options at compile time, that would be really good. But you don't seem to be into that kind of stuff that much.

[adrelanos]

Link fixed.

Well, Mozilla at least gave 30 days to come into compliance and didn't instantly file a lawsuit, which is nice. But when having bad luck, 30 days can easily pass without reaction in case of sickness, accident or other real life issues without any activity and in a lawsuit might actually be filed or the project kicked from github due to trademark violation report and whatnot. Not a risk that I am willing to easily take on.

That's really interesting what you posted there @adrelanos. That really suggests there might be real problems.

However, I can't help but notice, how is this allowed then. Tumbleweed distributes a firefox with modified preferences, including modifying the homepage to feature their search engine. Name of the package is still firefox. So they have Mozilla's permission maybe? Or another example. Like these people can distribute their custom preferences version of firefox. So there has to be a boundary there obviously to what is allowed or not.

It's hard to interpret the (trademark enforcement vs non-enforcement) actions by a third-party. More so, one I only ever interacted with online. Here are a few possibilities...

• A) Nobody noticed (yet) and/or nobody bothered to Report of Misuse of Mozilla Trademarks.
• B) It depends on the nature of the patches.
  • That kind of patching being permissible. Rather minimal settings changes. In the category of acceptable vs not acceptable patches. [1] [2]
  • They did not disable the "Know Your Rights" information page.
  • They did not disable all telemetry.
  • They did not make changes potentially breaking lots of websites by improving fingerprinting protections.
• C) Nobody was bothered enough yet to escalate telling people until they tell an attorney to actually write an e-mail.
• D) These are large Linux distributions, large projects, so these get preferential treatment.
  • Debian in [1] expressed they don't want to accept a special permission that would prohibit forks from the same rights. Other Linux distributions might have similar policy.
  • Even if large projects such as these Linux distributions don't request, accept special treatment, they most likely do receive special treatment.
  • Two people doing the same unfortunately isn't an equal thing, which goes for many things in life.
  • As we can see in https://github.com/portapps/phyrox-portable/issues/11, the large (popular) project portableapps.com got a special trademark deal with Mozilla. But Mozilla refused the (presumably) smaller, lesser popular portapps.io project. No detailed reasoning, no objective criteria for how these decisions are reached has been published.
    • portableapps.com: Got a trademark deal.
    • portapps.io: While Mozilla was friendly in tone and at least not quick to raise in this in court - just got a trademark enforcement e-mail.
  • Debian, Fedora, Suse, RedHat in the viewpoint of Mozilla might be equally or even more important than portableapps.com.
  • I am afraid, realistically Kicksecure would get the short end of the stick so to speak, being in a similar category as portapps.io.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006 [2]

= About the Debian specific patches =

Mozilla recognizes that patches applied to Iceweasel/Firefox don't impact the quality of the product. Patches which should be reported upstream to improve the product always have been forward upstream by the Debian packagers. Mozilla agrees about specific patches to facilitate the support of Iceweasel on architecture supported by Debian or Debian-specific patches.

More generally, Mozilla trusts the Debian packagers to use their best judgment to achieve the same quality as the official Firefox binaries.

In case of derivatives of Debian, Firefox branding can be used as long as the patches applied are in the same category as described above. Ubuntu having a different packaging, this does not apply to that distribution.

I guess we can at the very least try our shot to get permission from Mozilla?

Debian didn't request or receive a special permission which would not extend to forks. This seems the right thing to do.

An e-mail to ask for clarification can be drafted and discussed here before I'll send it. Can be somewhat based on the previous Debian ticket for references and wording. [1]

And also, I also want to underline the fact that we are not distributing a modified firefox here. That was not the idea.

That's for sure but I doubt that makes a difference.

We would be packaging a system policy as a separate package.

That's for sure.

I don't know if this counts or where it falls.

From trademark, lawyer perspective which is non-technical, all it matters that somehow, someone is redistributing Firefox. If it's modified by default in one way or another is just a technical detail.

Surely this detail can be mentioned in an e-mail to Mozilla just in case.

Like if kicksecure packaged a modified firefox with good options at compile time, that would be really good.

Report non-ideal compile time options to Mozilla or they got tickets already?

But you don't seem to be into that kind of stuff that much.

Right. I am not a C programmer and that stuff is high maintenance effort.