search

arkenfox / user.js

Firefox privacy, security and anti-tracking: a comprehensive user.js template for configuration and hardening
MIT License
9.97k stars 511 forks source link

work with temporary containers? #1124

Closed fu8765 closed 3 years ago

fu8765 commented 3 years ago

(DISCUSSION) Given that we have some sites that we use on a daily basis, we can't possibly re-login continuously. even with a password manager that makes this easier, 2FA makes it a hassle.

Couldn't we propose the use of temporary containers, and create permanent containers for which we want to stay permanently logged in?

here's the changes I made to be able to do this. user-overrides.txt

With temporary containers set as auto. Still no third party cookies, but 1st party are OK and kept, as long as they're in a permanent container

does this make sense? Do the new cookie isolation changes in v86 help us in any way?

Thanks

Thorin-Oakenpants commented 3 years ago

posting here because every time I want to view it, it downloads and opens in an external viewer

edit: that in no way means I endorse it. I will get around to thinking about this in the next week: it's more complicated than just the below txt (which includes prefs at the same value we already have them)

that txt file reads

/* 2701: disable 3rd-party cookies and site-data [SETUP-WEB]
 * 0=Accept cookies and site data, 1=(Block) All third-party cookies, 2=(Block) All cookies,
 * 3=(Block) Cookies from unvisited websites, 4=(Block) Cross-site and social media trackers (default)
 * [NOTE] You can set exceptions under site permissions or use an extension
 * [NOTE] Enforcing category to custom ensures ETP related prefs are always honored
 * [SETTING] Privacy & Security>Enhanced Tracking Protection>Custom>Cookies ***/
user_pref("network.cookie.cookieBehavior", 1);
user_pref("browser.contentblocking.category", "custom");

/* 2703: delete cookies and site data on close
 * 0=keep until they expire (default), 2=keep until you close Firefox
 * [NOTE] The setting below is disabled (but not changed) if you block all cookies (2701 = 2)
 * [SETTING] Privacy & Security>Cookies and Site Data>Delete cookies and site data when Firefox is closed ***/
   // user_pref("network.cookie.lifetimePolicy", 0);

   /* 2803: set what items to clear on shutdown (if 2802 is true) [SETUP-CHROME]
 * [NOTE] If 'history' is true, downloads will also be cleared regardless of the value
 * but if 'history' is false, downloads can still be cleared independently
 * However, this may not always be the case. The interface combines and syncs these
 * prefs when set from there, and the sanitize code may change at any time
 * [SETTING] Privacy & Security>History>Custom Settings>Clear history when Firefox closes>Settings ***/
user_pref("privacy.clearOnShutdown.cache", true);
user_pref("privacy.clearOnShutdown.cookies", false);
user_pref("privacy.clearOnShutdown.downloads", true); // see note above
user_pref("privacy.clearOnShutdown.formdata", true); // Form & Search History
user_pref("privacy.clearOnShutdown.history", true); // Browsing & Download History
user_pref("privacy.clearOnShutdown.offlineApps", false); // Offline Website Data
user_pref("privacy.clearOnShutdown.sessions", false); // Active Logins
user_pref("privacy.clearOnShutdown.siteSettings", false); // Site Preferences
de-es commented 3 years ago

That described exactly my use case and it was working perfectly this way in ESR68. But since I had to switch to ESR78 and more recent versions, it doesn't work any more satisfactorily because network.cookie.lifetimePolicy=2, which I was using then, has now a different behavior.

In ESR78+ all cookies, even of whitelisted sites, will only be session only, the expiration date is always overwritten. So I have to temporarily switch the lifetime policy while I visit new sites which cookies I want to keep or set the expiration date of the cookie(s) to the future via the developer tools. It's working but not very convenient.

I have tested this with an otherwise unchanged arkenfox user.js in ESR68, ESR78 and FF85 in brand new profiles to be sure it's not another setting I wouldn't expect.

I would appreciate if we find a way to restore the previous behavior. I guess this is what fu8765 also had in mind.

Thorin-Oakenpants commented 3 years ago

This was touched on in #1123 : the how to retain some cookies thing

FYI: network.cookie.lifetimePolicy is going to be removed: and.. AFAIK, but I would need to test to confirm

The key is sanitizing but keeping some cookies (for auto-login). And if you're auto-logging in, it doesn't matter if IDB or any other state persists. We need to be careful how we use the word cookie. Cookies control access to other state: such as if you block cookies, it blocks localStorage, sessionStorage, IDB, shared + service workers and thus service worker cache as well, etc. And when we mention "cookies and site data" this uses Quota Management (I think) and I'm not sure if that contains the same items: what if it left service worker caches behind?

Then there's also history/downloads, which is orthogonal IMO. And forms is a bit in between. Cookie control and managing site data do not cover those.

I know how I achieve this: but it's not for everyone. And the other thing to remember is that the cookie setting will move to value 5 in the long term: FPI is going to be removed and dFPI used instead (with some extra settings to harden it to Tor Browser standards) - and that means a value of 5 would be required: and this would break how I currently do it (block all cookies but allow exceptions). Now hopefully that could be ready in four releases time so it's usable in ESR91: but there is no hurry to make this ESR compliant for Tor Browser, as they are going to move to the non-ESR channel anyway

However, getting side-tracked a little, sorry. This is not about cookie settings: it's about sanitizing properly. I've been down this road before having discussions on what mix of settings and extensions to use: and it always comes down to user preference: and all of them have something that either leaves a hole, or upsets the end user

I do see the issue of wiping all cookies on close with privacy.sanitize.sanitizeOnShutdown. It means you need to re-login for sites, and personally I find that a real PITA: especially given that my browser opens and closes dozens of times a day.

Maybe we could set up a sticky issue (without the noise) that lists about three or four different strategies: except that's just more work and as per usual, it'll just all end up on me: so TBH, I'm not really that interested: at least until we move to dFPI and I have to change my config

PS: there's a bugzilla in that requests that those who use privacy.sanitize.sanitizeOnShutdown and clear cookies, that the exceptions in manage cookies and site data be respected: <-- this is the answer, and I'd rather that happen than piss around with endless discussions and writing up numerous ways to achieve something

Woofy-Wolf commented 3 years ago

I accomplish @fu8765 's goal with a 3rd-party utility (I hope):

I create a permanent container for each site where I want to preserve logged-in status across sessions. I add their cookies to the CCleaner exclusion list. CCleaner wipes all other cookies including those in open tabs in temp containers. It also wipes "internet cache" although I use ghacks' setting for no disk cache.

But does it truly work the way I hope? I use an old version of CCleaner (from before it changed ownership) on Windows 7. My fear is that the old utility isn't really working the way I hope it is across containers and after so many updates to Firefox. I don't know what data CCleaner might be failing to remove. My method might only appear to work well.

Do the new cookie isolation changes in v86 help us in any way?

And are those changes compatible with TC and an external cookie-clearing utility?

fu8765 commented 3 years ago

Preferrably in the user.js itself, so it's easier for no so technical people to comment/uncomment.

Personally, I think the use case where it maintains no logins whatsoever should exist as an option rather than default. because if you login to a website, you're already been tracked by them, so what's the point. and if you do want to remain anonymouse (visit flight booking, and avoid their pricing) you can easily open a temporary container or Private browsing session

Thorin-Oakenpants commented 3 years ago

delete cookies with utility CCleaner

don't do that: it can cause issues: like removing entries from the databases but leaving orphaned data behind (seen a few bugzillas about this of thing: external cleaners). ALWAYS use the application's mechanisms: or an extension (TC will clean for you and you're already using that)

are those changes compatible with TC

Total Cookie Protection (i.e dFPI, which uses cookie behavior = 5) has issues with extensions: what those are will vary. I do know that Cookie Auto Delete breaks - see 1669716. TC I'm not sure about, it uses a different API to sanitize data

Thorin-Oakenpants commented 3 years ago

THIS is your solution

Keep using custom history settings

Then when the browser closes, everything state is wiped except those you give Allow exceptions for. And it still allows you to clear other items like history etc

Personally I think they need to restructure and combine the PB mode startup, persistent web data (cookies + site data), and other items (history + downloads, formdata, site settings) into a three clean sections

The problem is that it's all quite complex, and you need to handle Forget about this site (which has a different meaning), and everyone's expectation on what sanitizing is differs. There are literally dozens of bugzillas about this, and blindspots - and it's all about integrating the complexities into a single sanitizer that handles PB mode needs, Forget about this site, Quota Manager, custom history items, and session restore is in there as well.

They haven't even managed to migrate everyone to LSNG, and Quota Management v3 is already being worked on

Woofy-Wolf commented 3 years ago

Wow, thanks Thorin. I'll work through what you've laid out before updating to v86.