Kicksecure Default Browser Discussion #192
Comments
|
Few problems.
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.
This is superfluous and possibly harmful because
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.
Same. Maybe. Better left to the user to decide. We want the browser to be daily driveable, I suppose.
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.
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.
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. |
That could and probably should done together with: The packaging upgrade path might be difficult.
Already default.
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...
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).
More maintainable but also more limited?
Nice syntax, there would be a lot details to discuss but I want to exhaust options working with upstream first.
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.
I don't mind much about HexChat nowadays that there's no IRC based project support anymore.
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.) |
|
@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 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. |
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.
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:
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.
You don't say. I'm not even sure the flatpak respects the system policy. Gonna have to test that.
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. |
|
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:
|
|
These connections...
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 related:
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. |
|
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. |
Permissions are detectable. By default they are all prompt. Setting them default deny provides no benefits other than altering the fingerprint.
Telemetry is disabled to its core and default search engine is ddg, in the current policy in the repo I shared.
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.
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. |
|
Closing this issue to move to a dedicated repository as suggested by @adrelanos. |
|
As the the radio silence feature, I am currently preparing a feature request with detailed reasoning why I think that is a must have development goal (even if we need to admit that it is infeasible to be implemented, browsers nowadays cannot be tamed).
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.
Messages such as
It's quite a heavy restriction to disable password saving in the browser. |
Yeah that can be removed. |
|
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 |
|
Yes. Working with upstream(s), and there are many, hasn't been exhausted yet. I would suggest to:
Feature request if it can be called that:
|
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.
When it comes to upstream, please let me exhaust some of the options for you.
Tor Browser Forks
Conclusion If you don't want MB, everything indicates a custom policy as the best option. |
|
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).
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:
|
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.
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. |
|
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.
This is one of the most convincing arguments for me. Librefox? https://github.com/intika/Librefox#ijwy-i-just-want-you-to-shut-up
Since this is a difficult decision with a lot pros and cons, now keeping track in the wiki with hopefully most arguments: |
|
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:
Which projects take such things serious and disable it by default? settings locking: |
adrelanos
changed the title
|
I am afraid we most likely won't be able to
due to Firefox Potential Legal Risk (Trademark Violation). Unbranded, recompilation would be too much effort at this stage of project development. |
I do find this hard to believe. Then how come it is the case that
Does not seem to add up.
Yes, shipping addons is a bad idea tho for many reasons.
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.
Me in my repository. See the lines in my policy:
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. |
|
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:
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
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.
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.
How? |
|
This link is broken due to a minor error (missing 'https:/'). Should be setup-wizard-dist instead? |
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. |
|
Link fixed.
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
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]
That's for sure but I doubt that makes a difference.
That's for sure.
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.
Report non-ideal compile time options to Mozilla or they got tickets already?
Right. I am not a C programmer and that stuff is high maintenance effort. |
|
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.
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. |
|
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: |
|
Pale Moon? |
|
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).
|
|
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).
|
A reply has been received. Posted in full here: My interpretation:
|
|
Well at least that has been settled. I guess we can either keep Firefox as is or go back discussing alternatives.
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. |
|
Mullvad Browser (MB) would be confusing. Documented here: |
|
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. |
|
Vpn is not used and the mullvad extension can be removed easily |
|
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. |
|
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. |
|
Closed #192 as completed.
So, after all that, which is the default browser of choice, satisfying which criteria?
|
|
Then why does Tor browser and Mullvad Browser not make outgoing connections when you launch the browser?
I have not tested thoroughly but each time I launch TB I see short but significant network activity increase in the network monitor (XFCE panel) *without* any other networking apps running.
I would say Mullvad Browser
Based on which criteria?
|
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.
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. |
|
After long elaboration, I made a decision.
|
|
The ticket can stay open for better visibility and discussion of other potential alternatives. |
|
Any comments about Waterfox? |
|
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: CreepJS is a fantastic best-in-class detector of browser fingerprinting: Browserleaks provides in-depth details of various identifying metrics: Cover Your Tracks is a EFF project to test for fingerprinting: Device Info is another good tool for detecting fingerprinting: No-JS Fingerprinting is as the name suggests one method of testing tracking without JS: This list obviously not comprehensive, but regardless is very helpful when trying to methodically evaluate browsers in my opinion. |
|
Mozilla Firefox feature request: Add an Unbranding Option in Firefox Settings |
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.
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 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. |
|
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. |
|
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. |
|
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) |
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. |
Has some benefits:
There are some major problems, however:
|
and others
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:
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:
The text was updated successfully, but these errors were encountered: