Giters

Kicksecure / security-misc

Kernel Hardening; Protect Linux User Accounts against Brute Force Attacks; Improve Entropy Collection; Strong Linux User Account Separation; Enhances Misc Security Settings - https://www.kicksecure.com/wiki/Security-misc

Home Page:https://www.kicksecure.com/wiki/Impressum

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Kicksecure Default Browser Discussion

monsieuremre opened this issue · comments

commented

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": {
      "uBlock0@raymondhill.net": {
        "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
commented

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.

commented

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

That could and probably should done together with:

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.)

commented

@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.

commented

@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.

commented

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.
commented

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:

{
  "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.

commented

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.

commented

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.

commented

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

commented

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.

commented

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

Yeah that can be removed.

commented

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.

commented

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.
commented

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.

commented

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.
commented

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.

commented

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: #183 (comment)

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

commented

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?

commented

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.

commented

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.

commented

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 intika/Librefox@45a4d3c 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?

commented

setup-wizard-dist

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

Should be setup-wizard-dist instead?

commented

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.

commented

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 portapps/phyrox-portable#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.

commented

Before making any speculations, I think contacting mozilla and asking would be the sound choice here. After this is cleared, options then can be discussed. I don't think asking for permission from mozilla is anyhow bad.

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

It isn't high maintenance tho. Literally just a pipeline, get the tarball from mozilla sources, change some prefs in the tarball, then package it as a deb. That's a very automated and straightforward process. High maintenance would be doing this for 2000 packages. If kicksecure packages vital components itself, I don't think it would be much high maintenance for a distro. It would be high maintenance for you all alone tho possibly. Anyway, such undertakings wouId mean that kicksecure would no longer be a softy soft fork of debian, it would be more of a harder fork, kinda.

commented

If you change compile time options (or even if you don't) and/or use system hardening settings, when you compile you can easily get a compilation error and then have to figure out how to fix it. For example here I tried compiling VirtualBox I had a compilation error (posted a link to it from Whonix forums) and nobody was sharing how to fix it. If I run into similar issues with Firefox, then what? No solution. I assume compiling Firefox with more than 10 millions lines of code has equally much or more opportunities to fail compiling. Search term: firefox compilation issue
Not something I would recommend without expert level C++ knowledge and nowadays also requiring Rust.

commented

Pale Moon?

commented

Not something I would recommend without expert level C++ knowledge and nowadays also requiring Rust.

Yeah but no actually, because my suggestion does not involve compiling the binaries and stuff, at least not necessarily. We can do compile time but you are right this is just too much maintenance. An alternative is to just package it using the binary tarball. There is no compilation here. These are already done. The components are there. The only thing is linking these binaries to each other and to libraries and stuff, which actually that might even not be necessary also. Like the process is just, we get the tarball (binary) from mozilla sources, apply our patch (just add files and lines to scripts). then package it as deb. Like we will just pull the tarball and package it as deb, and in the process just add config files. Pretty straight forward and automated process. This is what most distros do also. So as I said, no compilation.

This option is worth considering depending on the degree mozilla would be willing to allow us to package other defaults. Which again, I think is a ok and there is a chance they might just allow it.

commented
commented

I guess it would look something like this:

Something something opening,

I am the lead developer of the Whonix project, an anonymity and privacy focused operating system. The base operating system for Whonix, which is in extension based on Debian GNU/Linux, is planned to be separated to be a standalone distribution for daily usage. The primary focus of the base project Kicksecure is to provide a security hardened operating system. The hardened defaults extend to the default user applications on the system, which includes the web browser. Since separating only the security components from Whonix means Tor Browser cannot be shipped on this operating system as a daily driveable browser, there is still an ongoing process of reviewing and considering potential candidates to be the default web browser on Kicksecure.

It is with good intentions that the various Kicksecure contributors have come up with the suggestion to ship Mozilla Firefox as the default browser on this said operating system. Having the claim to be security hardened is not limited to protecting Firefox with operating system security measures like Mandatory Access Control, however that is also done. What is of concern of some contributors including me is the modification of the Firefox browsers default settings that we intend to do. We have no intentions to do rebranding or change compilation of components and binaries. In fact, we are in favor of keeping the Mozilla Trademarked names for the products to provide our users with a sense of familiarity.

Our intentions of modifying Firefox is strictly limited to repackaging the already compiled set of binaries that are to be acquired from Mozilla sources with custom default configurations that we deem suit our expectations. I can state that we intend:

  • Not to use Mozilla trademarks in the name of your business, product, service, app, domain name, publication, or other offering.
  • Not to use marks, logos, company names, slogans, domain names, or designs that are confusingly similar to Mozilla trademarks.
  • Not to use Mozilla trademarks in a way that incorrectly implies affiliation with, or sponsorship, endorsement, or approval by Mozilla of your products or services.
  • Not to display Mozilla trademarks more prominently than your product, service, or company name.
  • Not to use Mozilla trademarks on merchandise for sale (e.g., selling t-shirts, mugs, etc.)
  • Not to use Mozilla trademarks for any other form of commercial use (e.g. offering technical support services), unless such use is limited to a truthful and descriptive reference (e.g. “Independent technical support for Mozilla’s Firefox browser”).
  • Not to modify Mozilla’s trademarks, abbreviate them, or combine them with any other symbols, words, or images, or incorporate them into a tagline or slogan.

Primarily our intention is to have a default policy (or employ other means if more appropriate) to do the following:

  • To disable all Telemetry, Studies, Reports and non-essential implicit outgoing connections
  • Force install the addon "uBlock Origin" by Raymond Hill
  • Set and lock hardened SSL/TLS related settings, including but not limited to settings HTTPS-only mode as the default, blocking mixed content, not trusting unsafe negotiations, disabling unencrypted background requests, etc.
  • Disable sponsored components, like bookmarks and suggestions
  • Set and lock strict mode for ETP

We are willing to elaborate on the details and consider making modifications upon request by Mozilla. We formally ask for your permission to distribute Firefox as the default browser on the Whonix base Kicksecure with our custom settings.

but I have no idea how this works so yeah. It would be good to keep track of things if you notify us after you contact mozilla. Their attitude will probably tell us what we need to know to stop considering firefox or whatever.

commented

The first sentence shouldn't mention Whonix since this isn't the main thing this is about? It's about Kicksecure. Not Whonix, which would be unaffected by this.

It however would make sense to mention "Kicksecure is being developed by the same contributors as Whonix" or something like that as that is a much more established project already.

Tor Browser: Wouldn't mention. Causes confusion.

Otherwise good stuff. Contains points which are important to make which might not have come to my mind. Glad I asked here, thank you!

It's on me now to come up with a new revision. If you want to do another sooner, please comment here when you start so we're having a "lockfile" (i.e. not editing at the same time). I'll also write when I start another revision.

commented

Also shouldn't ask for any special permission similar as Debian did in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006

Working on a new draft now.

commented

new draft:

I am the lead developer of the Kicksecure project, a Linux distribution focused on security and based on Debian. Kicksecure is developed by the same team as Whonix, which is somewhat more well-known.

Our hardened defaults extend to the default user applications on the system, including a daily drivable web browser.

We are currently in the process of reviewing and considering potential candidates to be the default web browser on Kicksecure.

With good intentions, various Kicksecure contributors have suggested shipping Mozilla Firefox as the default browser. However, some contributors, including myself, are concerned about the modifications to Firefox's default settings we intend to make, versus Mozilla's Trademark Policy. We have no intention of rebranding or changing the compilation options of Firefox binaries. In fact, we prefer to keep the Mozilla trademarked names for the products to provide our users with a sense of familiarity.

We would acquire unaltered binaries from one of the following sources:

  • Debian's official packages.debian.org repository
  • Mozilla's official packages.mozilla.org repository
  • Mozilla's official Firefox Flathub repository

Ideally, we would use Mozilla sources.

Here is a trademark-respecting list of things we are aware of and want to avoid for understandable reasons:

  • Not using Mozilla trademarks in the name of our business, product, service, app, domain name, publication, or other offering.
  • Not using marks, logos, company names, slogans, domain names, or designs that are confusingly similar to Mozilla trademarks.
  • Not using Mozilla trademarks in a way that incorrectly implies affiliation with, or sponsorship, endorsement, or approval by Mozilla of our products or services.
  • Not displaying Mozilla trademarks more prominently than our product, service, or company name.
  • Not using Mozilla trademarks on merchandise for sale (e.g., selling t-shirts, mugs, etc.)
  • Not using Mozilla trademarks for any other form of commercial use (e.g., offering technical support services), unless such use is limited to a truthful and descriptive reference (e.g., “Independent technical support for Mozilla’s Firefox browser”).
  • Not modifying Mozilla’s trademarks, abbreviating them, or combining them with any other symbols, words, or images, or incorporating them into a tagline or slogan.

And here is a list of things that we would like to do. Our primary intention is to have a default policy (or employ other means if more appropriate) to do the following:

  • Use unaltered binaries.
  • Disable all Telemetry, Studies, Reports, and non-essential implicit outgoing connections.
  • Force install the addon "uBlock Origin" by Raymond Hill.
  • Set and lock hardened SSL/TLS-related settings, including, but not limited to, setting HTTPS-only mode as the default, blocking mixed content, not trusting unsafe negotiations, disabling unencrypted background requests, etc.
  • Disable sponsored components, like bookmarks and suggestions.
  • Set and lock strict mode for ETP.
  • Change the default homepage.
  • Disable the default display of the "Know Your Rights" information page.

As an illustrative point of how specifically we plan to apply these changes:

  • Our intended changes would be made by providing a separate package (for example, named "hardened-browser-config").
  • This package would install config file(s) in folder(s) such as /etc/firefox or /etc/firefox-esr.
  • The package would be installed by default.

We are willing to elaborate on the details and consider making modifications upon request by Mozilla.

We are not asking for any special permission that does not extend to derivatives. As stated on the Debian issue tracker:

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.

This is related to the Debian Free Software Guidelines (DFSG) (item 8):

License must not be specific to Debian

The rights attached to the program must not depend on the program's being part of a Debian system. If the program is extracted from Debian and used or distributed without Debian but otherwise within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the Debian system.

We would like to be able to state similarly:

In case of derivatives of Kicksecure, Firefox branding can be used as long as the patches applied are in the same category as described above.

We are asking for your opinion on whether this would be in conflict with Mozilla's Trademark Policy.

We intend to publish our correspondence for the sake of transparency. Our communications and your responses will be publicized in full, verbatim, without modifications.

commented

Is this draft ready to be sent to Mozilla or more time needed for review, editing?

commented

LibreWolf:

Looking at https://codeberg.org/librewolf/issues/issues/ it seems most issues are ignored for ~ 3 weeks already.

Bugs reported to only be reproducible in LibreWolf but not in Firefox:

Bugs maybe specific to LibreWolf only but not Firefox:

commented

Is this draft ready to be sent to Mozilla or more time needed for review, editing?

Ping @monsieuremre.

commented

I think you can send it.

commented

Your feature request was very well presented and articulated. It is a shame the Librewolf issue tracker has been so unresponsive. Additionally, personally I am not exactly certain why the user.js request was "invalid". Regardless, I look forward to Mozilla's response.

commented

Sent to Mozilla. Once there's any reply I post a short notification here and the full reply here:
https://www.kicksecure.com/wiki/Dev/Default_Browser#Correspondence_with_Mozilla_about_its_Trademark

commented

Your feature request was very well presented and articulated.

Thanks for review!

It is a shame the Librewolf issue tracker has been so unresponsive.

Right. To add some context, it's not discriminatory against the radio silence feature request. Most issues for the last ~ 3 weeks or so are not receiving any activity so the feature request comes with a somewhat bad timing.

Additionally, personally I am not exactly certain why the user.js request was "invalid".

Upstream seems to be very much against this feature to the point of deleting tickets. Someone sent me this.

Therefore no surprise I couldn't find prior discussions about this.

Quote @Thorin-Oakenpants in https://web.archive.org/web/20210602135212/https://github.com/arkenfox/user.js/issues/917#issuecomment-609087428

I know you say since 68, but this is not something that I'm going to waste my time on. Update checks, blocklist updates, SB updates, etc are a normal part of browser functionality, and there are no privacy, security, tracking, FPing issues here (unless there's a bug).

Upstream actually agrees with me somewhat.

(unless there's a bug)

That is exactly the critical point. Unfortunately, upstream seems to reject proactive hardening, in defense in depth.

The search for browsers / configurations without phone home continues.

commented

These connections are needed to update the filters. The source code is open no data is sent what so ever. You just get the filter updates. All filtering is done locally. This is not a privacy risk. Mozilla does not even store ip addresse. (Gotta take their word for it ofc) Even if you don't believe them, ip addresses are useless because there is literally 0 data attached to them in this case, like not even one bit. Not establishing these connections is a bigger privacy risk.

commented
commented

Consider ungoogled chromium. When I tested various browsers a few years ago, it was possible to configure it for complete radio silence.

commented

Gotta take their word.

We have taken too many.

commented
commented
commented

Sent to Mozilla. Once there's any reply I post a short notification here and the full reply here: https://www.kicksecure.com/wiki/Dev/Default_Browser#Correspondence_with_Mozilla_about_its_Trademark

A reply has been received. Posted in full here:
https://www.kicksecure.com/wiki/Dev/Default_Browser#06_March_2024

My interpretation:

  • The short answer is no.
  • As in, no, we are not allowed to make these kind of changes without removing removing Mozilla's trademark.
  • Pretty difficult to misunderstand.
  • Pretty unlikely that there has been any miscommunication.
commented

Well at least that has been settled.

I guess we can either keep Firefox as is or go back discussing alternatives.

LibreWolf feature request: Radio Silence by Default for Browser Startup and Background Connections aka "Disable Phone Home" #1779

This issue appears to have still remained without response (much like dozens of other psoted issues).

Therefore, if we want to switch, I think going with the Mullvad Browser is likely the best option at this current point in time.

commented

Mullvad Browser (MB) would be confusing. Documented here:

commented

Personally I get that while it might be confusing to some, I think the benefits outweigh the negatives.

Perhaps for the time being we could provide both Firefox (default) and MB.

Then collect feedback and if everything goes well, we could eventually make MB default while still keeping Firefox.

Alternatively, we could shelve this discussion temporarily and keep things as is for now.

commented

Vpn is not used and the mullvad extension can be removed easily

commented

I also want to mention that kicksecure or whonix compiling the default browser has advantages even with settings not changed. Most noticeably, jemalloc integration is just a compilation parameter. So compiling firefox with hardened-malloc compatibility is actually a no-brainer, it requires just setting one parameter only. Also there a lot of non-true information on the wiki about hardened maloc, like flatpaks being incompatible. It is very trivial to create a global flatpak environment variable override to load hardened_malloc. But the more elegant solution would be just shipping our own hardened_malloc baked in glibc, to avoid LD_PRELOAD alltogether, because it is not a good way to integrate this actually. Anyway, not the right place, but just mentioning.

commented

As I mentioned, blocking outgoing connections has no real benefits. These are non javascript static answers just to update filters. Not updating regularly on its own is a bigger privacy and security risk. Some ip address connected to get fitler texts is not a tracking point. Not having filters updated can make you unironically stand out more. Anyway, closing.

commented
commented
commented

Whats the point of using both blocklists?

There is no point. The point is that uBlock is used for blocking ads primarily. If firefox's default filters blocked ads, we would not need uBlock. It does not make sense to disable the default filters just because we have uBlockOrigin tho. Because it would bring no tangible benefits.

Based on which criteria?

There is no decision, I think he just gave his opinions. Which makes sense. Whonix uses TB. Mullvad is basically TB without Tor (actually more than that, but lets use this definition for simplicity). And eventhough there is effort to make a different impression, as it stands, Kicksecure is defacto basically just a non-tor version of Whonix. So it using the non-tor version of the TB would make sense.

The only concerns @adrelanos has with the MB is the fact that it includes a company name. Not the potential Trademarek issues, because there is basically none. But rather the, oh am I using a vpn feeling. Which, I don't think is the case, but it's not up to me to decide.

The issue was closed, not because a decision about the default browser was made. It was closed because the discussion has come to an end, which was whether or not a modified firefox would be suited to be the default browser.

commented

After long elaboration, I made a decision.

  • Opt-in Installation: Users can easily opt-in to install Mullvad Browser (MB).
commented

The ticket can stay open for better visibility and discussion of other potential alternatives.

commented

Any comments about Waterfox?

https://www.waterfox.net/

commented

I would also like to present a few useful resources for comparing browsers in terms of both security and privacy:

Privacy Tests is a good way to compare a myriad of features between browsers:
https://privacytests.org/

CreepJS is a fantastic best-in-class detector of browser fingerprinting:
https://abrahamjuliot.github.io/creepjs/

Browserleaks provides in-depth details of various identifying metrics:
https://browserleaks.com/

Cover Your Tracks is a EFF project to test for fingerprinting:
https://coveryourtracks.eff.org/

Device Info is another good tool for detecting fingerprinting:
https://www.deviceinfo.me/

No-JS Fingerprinting is as the name suggests one method of testing tracking without JS:
https://noscriptfingerprint.com/

This list obviously not comprehensive, but regardless is very helpful when trying to methodically evaluate browsers in my opinion.

commented

When it comes to changing the browser fingerprint. What kinds of things alter them the most?

If we are just trying to avoid naive and weak scripts, we are good already. If we want to resist real fingerprinting that involve more sophisticated scripts, everything that touches the dom will alter the fingerprint. Change the default permissions will most certainly alter the fingerprint even for naive fingerprinting mechanisms most certainly. The defaults are all to prompt the user, they are safe. Using default reject is a bad idea with no real benefits.

Any add-on that touches the dom will alter the fingerprint. Using varying filters or non up to date ones for that matter, will change the fingerprint in sophisticated scenarios. Fingerprinting is a very detailed topic and there is no realistic way to prevent it on a chromium browser. On gecko, it is still very difficult, but not impossible. But the key is that, a lot of things should be non customizable. Mullvad browser here is our only bet here, realistically. If you want real fingerprinting protection, mullvad browser is the only way to go. We can also do our own config, but this would be a bad idea, because our pool would be literally non-existent to blend in.

Mozilla Firefox feature request: Add an Unbranding Option in Firefox Settings

Will get rejected most certainly. There is already a build option to do unbranding in compile time. Once again, we will have to compile the browser if we want our own unbranded browser. And won't you know, if we do that, we can just sneak in the --no-jemalloc option while compiling too, which will make the browser work normally with hardened malloc.

If you do not want to bother with compilation (which is really automated and we will just change so little, won't be hard to maintain), the only realistic choice is the MB. They also just added a .deb builds, that are downloadable. They will soon be available in a repository. So the easy path would be this one.

commented

I agree that when it comes to Chromium-based browsers, preventing fingerprinting is next-to-impossible. You should have no illusion of privacy when using these browsers.

For example, CreepJS will reveal how accurate Chromium fingerprinting is no matter how hard you try to obscure. Overall, if you visit various websites controlled by a single entity, if they implement state-of-the-art tools such Fingerprint, they can rather effortlessly identify you browsing.

Chromium-based browsers do however have several benefits when it comes to overall security in comparison to Gecko-based browsers (which is another topic).

I also concur that using the Mullvad Browser is quite likely the best option that currently exists (but even that can be defeated by CreepJS). In principle, true privacy when browsing the web is something that should always be consider compromised by default.

However, if you seek to try to preserve maximum privacy, one possible route you could take is to create a new VM used solely for each browsing session. This will obviously be quite inconvenient, though if your threat-model is dialed all the way up to 11, it is a feasible method. Just try to make sure that the VM you create each time is somewhat unique in terms of the amount of threads/RAM/storage you allocate.

commented

For Kicksecure, we don't necessarily need to fix the very hard to solve issue of browser fingerprinting.

However, if there is a well maintained browser that has disabled / less telemetry, radio silence by default and/or is more secure by default, it can be considered.

Related:
Privacy Goals and Non-Goals of Kicksecure

commented

In theory, yes. But please read prior discussion so it does not go in circles. This was addressed just a few posts ago: #192 (comment)

commented

Any comments about Waterfox?

https://www.waterfox.net/

https://digdeeper.club/articles/browsers.xhtml#waterfox

This site has some "hot takes," but the basic information on this page is generally accurate to my knowledge.

The bottom line is that Waterfox is still chock full of telemetry, and if it's any better than Firefox, it's only marginally so and it's not worth going downstream for such little benefit unless you really care about XUL addons, which are inherently more permissive than modern webextensions and could increase attack surface.

If you care, you can also test yourself the outgoing connections of most browsers using this this guide by the same person.

commented

Pale Moon?

Has some benefits:

  • Can be made radio silent (not by default, harkens back to the about:config situation and would best be addressed with a user.js like this)

  • Smaller codebase compared to both modern Firefox and Chromium

  • Many exploits targetting more common browsers don't work on PM

There are some major problems, however: