force tracking protection to strict mode #1439

mentioned in issue librewolf-community/settings#147

marked this issue as related to librewolf-community/browser/source#20

mentioned in merge request librewolf-community/browser/source!21

changed the description

LibreWolf supports - and it enables by default - Enhanced Tracking Protection in Strict mode. This is one of the most important settings in the browser, as it provides state partitioning, strict blocking lists and other neat privacy features. We do not recommend changing to other modes. Learn more

at that link I will then:

• list all of the features included
• explain why it should not be changed and state that there's nothing to gain (breakage wise with standard, and privacy wise with custom)
• link to the overrides for changing that

marked the checklist item write proper description for UI; as completed

Looks great, thanks! I've updated the MR.

many thanks to you, this looks very nice :-)

mentioned in issue librewolf-community/browser/windows#173

marked the checklist item take decision; as completed

marked the checklist item update docs; as completed

according to the comment in the MR we are just going to do it. I will take care of the docs where I plain to knock out a bunch of changes anyway.

mentioned in commit librewolf-community/browser/source@0e3363249cf3613ea79a48e63422b27b823110a4

Documentation regarding this setting is not good right now, and its confusing people. It has to be made clear why the strict mode is recommended, and also explain how to change this setting for those who really want to override it. A friend posted this on social media, he can't seem to find any documentation on how to change this setting. I'm sure he isn't the only one confused by this setting, so please improve your documentation and make things clear.

tbh I think that the existing documentation is more than enough:

clicking on learn more would land you on -> https://librewolf.net/docs/faq/#what-is-mozilla-tracking-protection, which contains 10 lines of details.

as for writing in the docs how to revert that, since it brings no benefit at all I see no reason to actively document it. we only document overrides that we actually consider useful, and then leave the rest to user's research, as it doesn't make sense to document every single pref.
of course if we get feedback about use cases where changing make sense, we could always change that.

regarding the usual argument of "choice", why would we give users the choice to take a bad decision because they don't know better? I'd argue that the project should have the freedom of choice to move in a desired direction, as long as we are transparent about it.

PS: thanks for suggesting your friend to directly reach out to us, it seems like the right way to move and in fact I've personally replied to a similar question several times (when we still had the UI but it was reverting, which also shows how nothing really changed since then and that the UI was likely more confusing).

I honestly think adding documentation about how to disable tracking protection wouldn't hurt, there are enough barriers and hurdles for the user to understand that this is probably not a good thing to do. Adding the documentation would just mean less users are enraged about the choice "taken" from them.

regarding the usual argument of "choice", why would we give users the choice to take a bad decision because they don't know better?

I agree with this actually, and I don't personally have any issues with the direction this project is moving in. I thought I'd let you know because there was a user asking about this particular setting, now there are 2 possibilities here:

1. This setting does actually cause some problem we're not aware of.

2. The user didn't properly understood the documentation.

I don't know which of this is the case here, but if this documentation is causing confusion for the users and is affecting the reputation of this project, then I thought you should know about that. Its worth having a discussion about at least.

https://gitlab.com/librewolf-community/settings/-/issues/149#note_848350875 Here you mention that you will link to the overrides for changing this setting, so I initially thought you were going to add it to the documentation later sometime.

This setting does actually cause some problem we're not aware of.

if this is the case I think we should be aware of them, yes.

I thought you should know about that. Its worth having a discussion about at least.

indeed, thank you for bringing this to this issue in fact.

I would just like to make sure that it's actually worth adding it to the docs tho. I also understand what @maltejur says (and this is what I originally considered doing, as per your link), but then I figured it would produce the same result as the old and broken UI.

How about we just link to this thread in the documentation ? Something like "Read this thread to learn more about the rationale behind this decision". If users are annoyed by this setting, then that's probably because they think librewolf is restricting their freedom, but reading this thread would make them understand that its not the case. They can also participate in this thread if they want to.

we only document overrides that we actually consider useful, and then leave the rest to user's research, as it doesn't make sense to document every single pref.

Where can a user do research about this ? Even if there is a place where they can find documentation about all prefs, I don't expect everyone to know about that. Explain how users can change to different modes here, and then link to this thread in the documentation like I said. So you don't really have to add useless prefs on the documentation, but also allow users to change this setting if they really want to, probably for experimental purposes or something 'cause it doesn't really have much practical use case from what I understand.

ok back from the dead :-) after a deep sleep I also remembered one more thing that made me hold back on adding this to the docs: if a user changes to custom mode the UI will not show up, so he won't be able to tweak the various stuff without changing a bunch of prefs.

either way I'm sure I was being too strict yesterday, with a clear mind I can say that if we want to document it (either how to revert or link to this as suggested above) and not care then it's not the end of the world.

I still want to be clear that I'm not going to support users who change to custom in this repo.

Where can a user do research about this ?

I recently wrote a bunch of descriptions for the prefs in our config, in order to cover them all and possible do something useful for users and contributors. for example for TP's mode:
https://gitlab.com/librewolf-community/settings/-/blob/master/librewolf.cfg#L32

This is the current documentation about this setting:

Finally, there's no point in changing from strict to any other mode, as strict mode doesn't usually cause any kind of breakage, and changing to custom mode to block cookies will come at the expense of disabling dFPI: not worth it, so we decided to hide the UI that allows users to change this. You can explicitely force other modes with overrides, but once again we advise against it.

From what I understand, there is actually no practical use case for changing to any other modes, right ?
So forcing this setting to strict mode wasn't really a subjective decision, but an objective one. This is what users should understand, its not like librewolf decided to make a choice for the user, but rather just removed an option that will only have negative consequences for the user. Like I said before, the only reason to change this setting then would be for experimental purposes, maybe for testing something. The current documentation isn't very clear cut about these things, and that's why users feel like librewolf is taking away a "choice" from them.

I still think its a good idea to add a link to this thread. The documentation says strict mode doesn't usually cause any kind of breakage, but there is always a chance that it could cause some problem we're not aware of, so users should have the option of reporting it here if they came across something like that.

PS: Its nice that you're writing documentation for various prefs, this is the only place I'm aware of that has this info.

From what I understand, there is actually no practical use case for changing to any other modes, right ?

I would confidently say yes. during the one year I've been a contributor we have had zero issues related to tracking protection and dFPI (which is basically what makes strict mode).

users who change to other modes, do that for two main reasons, according mostly to reddit posts:

• they read strict so they think that if something is broken they need to change that. in my experience it never turned out to be true.
• they switch to custom to block third party cookies, which disables isolation making all the rest of the privacy measures useless, because lowest hanging fruit. even if they use FPI what they are getting is outdated code and more breakage, not good.

hopefully this further clarifies. this is how TP mode gets set for those who want to understand, override or whatever -> https://gitlab.com/librewolf-community/settings/-/blob/master/librewolf.cfg#L32

for the record I consider other modes to not be "officially supported", if that means anything :-)

users should have the option of reporting it here if they came across something

I agree but I think it would be best to have new issues for that. I would like to actually debug if it's caused by strict mode because:

• it never was, at least so far.
• if it is, changing to other modes is not a good workaround because it will disable isolation and at that point every other measure in the browser is useless.
• if it is, I also need to report this upstream to mozilla because that's in everyone's best interest and I wouldn't know how to fix and maintain complicated stuff like isolation.

I wrote something down here that maybe we can use to further clarify, by linking it in the faq for redundancy and more details. let me know if it looks good :-)

PS: Its nice that you're writing documentation for various prefs, this is the only place I'm aware of that has this info.

thx! if you're interested arkenfox has even better documented stuff all over their repo history.

So will you be linking to that message in the documentation ?

Just to be clear, FPI (and the new dFPI) refers to first party isolate, right ? So it'll prevent websites from reading the cookies of other websites.

I agree but I think it would be best to have new issues for that.

Yeah it makes sense to have new issues for these.

yes, it refers to first party isolate. instead when I say "isolation" in the above comment I mean everything provided by dFPI (you can learn more about it here).

I was thinking so, would it address the parts of the docs that were not clear?

Yes, I think it will make things more clear for the user.

mentioned in merge request librewolf-community/website!36

I want to add one last thing: TP allows for exceptions and it can be controlled from the urlbar per-site. this makes changing mode even less needed.

mentioned in commit JoaoCostaIFG/librewolf-settings@0822d491d2

moved from librewolf-community/settings#149

This issue was migrated from GitLab/Settings#149

Finally, there's no point in changing from strict to any other mode, as strict mode doesn't usually cause any kind of breakage

IMO this is a terrible excuse to not allow the user to change the setting at all. i understand setting it to strict by default, but disabling the ability for the user to change the setting at all because it doesn't "usually" cause any kind of breakage is just annoying.

the browser is called librewolf, so why am i not free to change this setting without having to dig into config files? if i wanted to do that, i'd go back to firefox.

From what I understand, there is actually no practical use case for changing to any other modes, right ?
So forcing this setting to strict mode wasn't really a subjective decision, but an objective one. This is what users should understand, its not like librewolf decided to make a choice for the user, but rather just removed an option that will only have negative consequences for the user. Like I said before, the only reason to change this setting then would be for experimental purposes, maybe for testing something. The current documentation isn't very clear cut about these things, and that's why users feel like librewolf is taking away a "choice" from them.

as a user i don't like being told what the correct settings are for me. i don't think it's an "objective" decision at all. put as many warnings as you want against it, i don't mind, but at the end of the day it's my decision as a user if i want to change it.

for the record, https://github.dev is a site that breaks when enhanced tracking protection is on. i encountered this within an hour of switching to this browser and i'm sure there will be more. i don't want to have to change this setting individually for each site because i will probably just forget about it and assume the site is broken.

the most part i'm enjoying librewolf more than any other firefox fork i've tried. i've been able to configure it to my liking for the most part (i just want an "un-mozilla'd firefox" and don't really care too much about the privacy stuff other than what ublock already provides). this is the only issue i've had with it so far.

I switched from firefox to librewolf only a few hours ago so maybe i'm missing something...
But for now when i find a website that use disqus but it doesn't appear because the Enhanced Tracking Protection blocks it then here's a workaround i found :
In a new tab i go to about:config and type privacy.trackingprotection.enabled then i change the first one (the same one) to false.
The disqus section appear when reloading. Then i change it back to true.
To make it easier to access, i pin the config tab.