search

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
https://www.kicksecure.com/wiki/Impressum
Other
517 stars 51 forks source link

Kicksecure Default Browser Discussion #192

Open monsieuremre opened 10 months ago

monsieuremre commented 10 months ago

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:

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:

monsieuremre commented 10 months ago

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 commented 10 months ago

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.

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 commented 10 months ago

@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 commented 10 months ago

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

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.

adrelanos commented 10 months ago

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:

adrelanos commented 10 months ago

These connections...

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

monsieuremre commented 10 months ago

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.

monsieuremre commented 10 months ago

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 commented 10 months ago

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

adrelanos commented 10 months ago

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 commented 10 months ago

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

Yeah that can be removed.

raja-grewal commented 10 months ago

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 commented 10 months ago

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

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

I would suggest to:

Feature request if it can be called that:

monsieuremre commented 10 months ago

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

Tor Browser Forks

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 commented 10 months ago

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:

monsieuremre commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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

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 commented 10 months ago

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 commented 10 months ago

setup-wizard-dist

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

Should be setup-wizard-dist instead?

monsieuremre commented 10 months ago

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 commented 10 months ago

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

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

monsieuremre commented 10 months ago

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.

adrelanos commented 10 months ago

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.

adrelanos commented 10 months ago

Pale Moon?

monsieuremre commented 10 months ago

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.

adrelanos commented 10 months ago

Right.

Next step is to draft an e-mail to Mozilla.

monsieuremre commented 10 months ago

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:

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

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.

adrelanos commented 10 months ago

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.

adrelanos commented 10 months ago

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.

adrelanos commented 10 months ago

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:

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:

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:

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

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.

adrelanos commented 9 months ago

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

adrelanos commented 9 months ago

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

adrelanos commented 9 months ago

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:

adrelanos commented 9 months ago

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

Ping @monsieuremre.

adrelanos commented 9 months ago
monsieuremre commented 9 months ago

I think you can send it.

raja-grewal commented 9 months ago

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.

adrelanos commented 9 months ago

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

adrelanos commented 9 months ago
adrelanos commented 9 months ago

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.

monsieuremre commented 9 months ago

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.

adrelanos commented 9 months ago

monsieuremre:

These connections are needed to update the filters.

I know. This is acknowledged in my write-up.

The source code is open

Doesn't help because too much code, constantly changing, nobody able to keep up.

Chapter "Open Source in Name Only" from the ticket applies.

All filtering is done locally.

Yes.

This is not a privacy risk.

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.

Well, if you're not convinced of this despite the huge ticket with detailed reasoning then I doubt there is anything else I can say.

However, it's a security risk. See chapter "Blocklist Downloads as a Security Risk".

Mozilla does not even store ip addresse. (Gotta take their word for it ofc)

You mentioned the issue already. Gotta take their word.

Also not only Mozilla being contacted for blocklists downloads but also a number of other organizations. So you gotta take their word too.

Not establishing these connections is a bigger privacy risk.

Not if all needed data is already available through package manager updates as mentioned in the ticket.

emanruse commented 9 months ago

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

emanruse commented 9 months ago

Gotta take their word.

We have taken too many.

adrelanos commented 9 months ago

chromium based was previously disregarded due to other issues. References here:

emanruse commented 9 months ago

Both links in your reply talk about Google in relation to Chromium.

However, I explicitly said Ungoogled chromium, not Chromium. There is a reason it is called ungoogled.

Previously, I have been able to use it through Tor without issues (and with complete radio silence).

adrelanos commented 9 months ago

The arguments from the miscellaneous user freedom threats wiki page extend to any forks of Chromium, unless it would be a fully independent hard software fork (which means that they no longer rebase on upstream Chromium, becoming a fully independent project instead of a patch set).