Disabling "Always use Private Browsing Mode" doesn't persist cookies for allowed exceptions

[ruihildt]

I'm trying to set up cookie exceptions for Mullvad Browser so whitelisted sites don't clear cookies on sanitization.

I've set it up exactly as I have it in LibreWolf, but cookies and the exception list are still clearing.

Is there an additional setting set by Mullvad Browser that is clearing the exception list? Usually the exception list is part of "Site settings." Thanks in advance.

Source: https://www.reddit.com/r/mullvadvpn/comments/12bvc7g/mullvad_browser_cookie_exceptions/

[jayna37]

As for the issue in the OP: This happens because in Mullvad Browser the private browsing mode is always on, there is no possibility to set exceptions. With LW/AF they have a slightly different approach. This has been explained in #1 pretty good by the AF creator:

• AF does not start in Private Browsing (PB) mode. Instead it can effectively achieve that in normal mode via sanitizing on close - and the threat model does go as far as trying to avoid all disk state (but you can do that in the optional OPSEC section)
  • This has benefits - such as being able to leverage containers (containers and PB mode are incompatible), being able to retain some login data (site exceptions are retained), being able to leverage private window sessions as another "container", having non-PB mode APIs available such as service workers
• AF uses dFPI and network partitioning, not FPI. FPI has some issues outside of PB mode, such as isolation of service workers. dFPI allows for site exceptions for cross-site logins

Maybe this can be improved upon in the future. Indeed personally I would also like to have an option to remain logged into sites that I have explicitly whitelisted. For example a session in Element Matrix client, because that is especially time-intensive to fully establish again.

[Thorin-Oakenpants]

If MB switches to non-PB mode, with some relaxed disk requirements, and used ETP strict (or some custom setup) with dFPI and thus increased the usability of the project, then AF wouldn't need to exist.

Usability drives crowds, and there are ways we can fix some RFP issues (such as subtle randomizing of canvas, default newwin sizes: window real estate fuckery is a real turn off for users, I think in a study it was 60% of the reason people flipped RFP off), but FPing aside - just the ability to cross-login (note dFPI has some hardening knobs), retain some logins, retain site settings, use features such as service workers/notifications, using the built in password manager (you can recommend setting a master password and add your own red warning symbol, and recommend using an extension - but blocking it actually hurts users), and so on

I get why TB does this - disk. But this all goes too far for something that is supposed to be in the middle. If MB was like AF it works (and AF can close down, point to MB, and I can put my resources there). The nice thing is this comes with the VPN and some other nice touches like DoH etc. And it allows a crowd for the VPN users, and maybe some less FP entropy for those that don't.

If the main purpose is the FPing protection as a point of difference (and the VPN), that doesn't mean to go all nuclear on disk "leaks". Of course necessity meant starting with TB's model. At least we have webadio, webrtc, media devices etc relaxed (and we can beat webaudio FPing - its coming up). You're almost there

Can't wait to retire AF

[ruihildt]

No matter what I try, Mullvad will not save my whitelist of one site. I have changed History to custom, deselected cookies and logins from clearing history, and added the site to the whitelist. Five times. But every time I launch Mullvad, all the settings have reverted.
Also, I continually get the warning that my browser is out of date and i need to get the latest version. I only just installed it yesterday!

[Thorin-Oakenpants]

No matter what I try, Mullvad will not save my whitelist of one site

site exceptions are session only - the data does not touch disk but is kept in memory

I am not endorsing changing any settings, and recommend against it

• this should be the pref that you flip to persist site exceptions

/* disable permissions manager from writing to disk [FF41+] [RESTART]
 * [NOTE] This means any permission changes are session only
 * [1] https://bugzilla.mozilla.org/967812 ***/
   // user_pref("permissions.memory_only", true); // [HIDDEN PREF]

[jonaharagon]

If the main purpose is the FPing protection as a point of difference (and the VPN), that doesn't mean to go all nuclear on disk "leaks".

I agree, what tracking/FP protections does permanent private browsing mode even provide that "Delete cookies and site data when Mullvad Browser is closed" doesn't, anything?

This happens because in Mullvad Browser the private browsing mode is always on, there is no possibility to set exceptions.

The issue in the OP is that permanent private browsing mode can be visibly disabled (see the unchecked box in the history section of the screenshot), but the site exceptions list still doesn't work. At the very least this is a UX bug, but I would argue that private browsing mode shouldn't be mandatory in the first place.

[Thorin-Oakenpants]

this issue has been present in TB for years - and there is a ticket (can't look for it right now) - from memory the consensus was that it takes away choice from those that want it, and users do flip prefs and settings to retain/use site exceptions, passwords etc

The problem is not that the UX exists, but that there are no warnings about it (there's another big ass catchall ticket about hardening prefs and tweaking the UI) - it exposes isolation leaks via service workers, and it compromises disk

If/when MB moves to normal mode and opens up all these usability features, there are still issues that need to be addressed first - e.g. blobs are not isolated, site exceptions for sanitizing on close also compromise dFPI, how to handle sanitizing on VPN endpoint changes, and so on. And all this would require divergent code changes at Tor Browser Tor Project, but that's OK, it's a different build, just saying it adds more maintenance - so it ain't going to happen soon

but I would argue that private browsing mode shouldn't be mandatory in the first place

in order to ship the product, it required base tor browser which is dictated by this mode. Otherwise we'd still be waiting in 2025

[mattdale77]

I came across this annoyance too. The majority of the small number of exceptions I use are for self hosted services. The very point of exceptions are that they don't have the same rules as everything else. Some websites get really stroppy if you log in from a new device each time, say paypal as one example in which you might have to go through several rounds of captchas every visit and it's session timeouts are really short.

While almost all sites I don't have a problem wiping every time I would like to choose the few where that I want to retain the data. And suggesting that if you disable privacy mode then the exceptions will work but still not have them work is just terrible UI design.

This is important and might prevent my migration from Librewolf

[storopoli]

Additionally, every time I've open a new session on the Mullvad browser and search with leta I need to type again my account number. Can't we save this in a persistent cookie session?

[ruihildt]

And suggesting that if you disable privacy mode then the exceptions will work but still not have them work is just terrible UI design.

@mattdale77 Agreed, pretty sure this is an upstream design. We are looking into it.

[ruihildt]

Additionally, every time I've open a new session on the Mullvad browser and search with leta I need to type again my account number. Can't we save this in a persistent cookie session?

@storopoli We're looking into fixing that through the Mullvad Browser Extension, Soon™.
See: mullvad/browser-extension#153

[felschr]

I've been trying Mullvad Browser with Private Browsing mode & memory only disabled (browser.privatebrowsing.autostart = false & permissions.memory_only = false) so I can set up exceptions.

I've had mixed success with it, though. I can't seem to set up exceptions for some websites (proton.me) whilte others work after some setup (app.element.io).

With FPI, exceptions need to be specified together with their fist party domain like https://sub.example.com/^firstPartyDomain=example.com. Adding the first party domain alone isn't enough for many websites.
The preferences dialog seems to do this automatically for simple cases (subdomains) but with across domains it's a bit more complicated.

E.g. to get Element working with the official matrix.org server I added these 2 exceptions:
https://app.element.io/^firstPartyDomain=element.io
https://matrix-client.matrix.org/^firstPartyDomain=element.io

For Proton I've added all of these and I'm still logged out after a restart:
https://proton.me/^firstPartyDomain=proton.me
https://.proton.me/^firstPartyDomain=proton.me
https://account.proton.me/^firstPartyDomain=proton.me
https://mail.proton.me/^firstPartyDomain=proton.me
https://calendar.proton.me/^firstPartyDomain=proton.me
https://drive.proton.me/^firstPartyDomain=proton.me

Via DevTools I checked the Domain property of all cookies across the proton.me (Mail, Calendar, Drive & Account) websites and these were the only values used:
.proton.me, account.proton.me, mail.proton.me, calendar.proton.me & drive.proton.me

I even tried adding some other URLs used by Proton, which also didn't help:
https://verify.proton.me/^firstPartyDomain=proton.me
https://account-api.proton.me/^firstPartyDomain=proton.me

dFPI doesn't use this URL schema, and according to some reports I've read people had fewer issues setting up exceptions with it and users seemingly only need to add first party domains to the list. I haven't tried it yet, but with dFPI I should be able to add an exception for https://proton.me and it would just work.

[Arzumify]

Interestingly, it seems to work if you disable this setting:

It seems that the distinction between history and cookies do not exist?

[Arzumify]

Well more specificly theres a settings button next to it that allows you to disable "clear cookies on browser close". Quite a misleading button, huh?

[tzb6js]

I find this UX to be very poor, indeed IMO the missing functionality means that MB is not usable as a main browser. Leaving an option for users to set and save that is then wiped out when the product is closed is poor and unprofessional. Either remove the option or fix it. If its deemed insecure to persist the function settings across sessions then remove it, otherwise the product appears amateurish. Moreover, users like me will waste precious time setting it repeatedly and then scratching our heads when it fails to work.

[ruihildt]

We have also noted the inconsistencies at various levels in the UI (for example, we have disabled the "Manage Exceptions" button, since it didn't work at all with "Always use private browsing mode").

But since this behavior is inherited from Firefox, it's unlikely we're going to drastically change it, as of now.
Because every time we change the UI, it means we need to keep up with whatever is updated upstream by Firefox.
The other reason is that Mullvad Browser for now doesn't support anything else than private browsing mode.

We're exploring ways to solve the underlying issue: we recognize that Private Browsing Mode as it stands can be too limiting like @Thorin-Oakenpants noted.

So I have a question for you @jonaharagon @felschr @yanagibashi-mt @mattdale77 @tracker-friendly @tzb6js @storopoli.

• For what purpose exactly do you want to disable Private Browsing Mode?
• What are you trying to achieve that is not possible with Private Browsing Mode?

(I of course have an idea, but I don't want to assume)

Thanks!

[tzb6js]

My required UX is to avoid having to re-enter passwords and settings on a very limited set of sites that are used many times throughout the day. For everything else I want all trace removed on exit. This function is called 'fire proofing' on the duckduckgo browser. I can't be re-entering credentials in a few key sites repeatedly through the day. You may think me lazy but I see these exceptions as key.--

[mattdale77]

I use a password manager so having to re-login to sites for the most part is not a problem. I would like Mullvad Browser to become my default browser of choice so that I am as private as reasonably possible for the vast majority of sites but would selectively allow cookies for some sites to remain logged in.
The specific cases are:

1. My own services, none of which track of FP, I would like to remain logged in rather than having to log in repeatedly throughout the day
2. Select other services which are more convoluted to log into, perhaps some with MFA and other that do not like you logging in from a new device and may present several rounds of captchas and require to MFA or have short session timeouts. The more you access a service then the more inconvenient it is to log in each time.

Of course this would all be fine if there were a better way of managing logged in sessions as cookies are obviously a terrible way to do it but until this is in place then the only conceivable solution is to allow permanent cookies for select sites

[Arzumify]

I am too lazy to log back into websites :-)

[Arzumify]

It would also be nice to be able to use expectations, and to be able to use regular private mode if you disable always private mode

[pospeselr]

@tracker-friendly that seems to be a bug, you can open a private window with the Ctrl+Shift+P shortcut, or by pressing alt and selecting New Private Window from the File menu

Opened https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/212

[ruihildt]

Having done further testing, it seems that disabling "Always use Private Browsing Mode" to persist cookies does work.
If you close your browser regularly, those settings are honored.

But if you use the New identity button in the toolbar, it will wipe everything regardless of those settings.
In some way, it works as intended, because "New identity" is a Tor Browser feature which assumes you're always in Private Browsing Mode.

Clearly we can do better with the UI/UX, but modifying default Firefox UI is also risk to have to maintain more custom code, so this is a decision which we will take the time to evaluate.

[felschr]

@ruihildt Like I mentioned in my previous comment (#issuecomment-1511206572), using it with exceptions doesn't seem to work for all websites. Which seems to be a due to FPI, which is an issue that could be fixed by adopting dFPI.

Related Reddit thread: https://www.reddit.com/r/firefox/comments/ezq413/cookies_exceptions_not_honouring_whitelist/

[ruihildt]

Thanks, it seems I get lost when navigating those convoluted settings.

What I described was not taking into account the Exceptions at all, just allowing cookies for all websites.

[jayna37]

Thanks for asking Rui. On a practical level, probably a lot of people would want something similar in functionality to what Brave is experimenting with their "Forgetful Browsing" (when used as a global default with manual overrides to disable it for certain sites): https://brave.com/privacy-updates/25-forgetful-browsing/

Reasoning being that you want to persist as little data as possible, but still allow for a more-or-less seamless browsing experience without having to login to your trusted email provider's webmail or your secured self-hosted cloud storage interface every few hours just because you closed the browser. And you could just use another browser for these trusted sites, because arguably fingerprinting countermeasures are not needed when you're always logged into the same account on a website, but having links in emails etc. open in Mullvad Browser with a single click and just not having to worry about potential issues like telemetry that arise when using another browser is overall a plus.

On a more technical level, I think we have already seen in this thread some examples why always using private browsing mode can be an issue for users:

• Site exceptions stop working as normally expected.
• Websites and extensions that rely on features like IndexedDB or Service Workers stop working completely, often without the cause for this being obvious to the user.
• ... and I might be overlooking something, for example I'm not sure if features like First Party Isolation or Containers work with private browsing mode. Although at least isolation seems to work fine in general with Mullvad Browser if we can trust these tests: https://privacytests.org

As for UX/UI, I acknowledge that it's a big maintenance burden to change anything from upstream, but I think it should be explored if it's possible to remove parts of the UI that are not really functional or that really shouldn't be messed with in the first place. There are other browser options out there for people that want customization, the main idea of Mullvad Browser and using a privacy-VPN in my understanding is looking the same as everyone else when browsing around.

Edit: Re-reading some comments here and another Leta search later, while FPI seems to work, the superior dFPI seems to not work in private browsing mode right now if my understanding is correct, so add that point to the bullet points above.

[ruihildt]

Thanks all for the input, and I can say we share the same frustration in regards to login, especially in a day and age where it's recommended to use MFA, which definitely adds friction to any repeated login experience.

We had arrived to similar conclusions, and we are looking at what is possible to do to have some kind of persistent (dare I say un-forgetful ;) ) browsing.

Note: interestingly the term "forgetful browsing" probably was devised after some research showed the vast majority of users misunderstand the term "Private browsing".

[felschr]

Update on my previous #29 (comment):

After updating to Mullvad Browser 13.0, it seems that cookie & site data exceptions work for a lot more websites now.
I didn't change the exceptions list after upgrading but I'm still logged in most websites after a browser restart than I was before the upgrade.

Sites where I'm now still logged in after a restart that didn't work before v13.0:
Proton, Mastodon, GitHub, GitLab, Toggl, Google

Sites that still log me out after a restart:
Asana (exceptions: https://asana.com, https://app.asana.com)

So, perhaps I'm just missing some domain for Asana, or something about Asana is special.
I haven't found another site that doesn't retain the if I add it to exceptions yet. If I do, I will update this comment.

[hanweikung]

I encountered a different result with version 13.0.

I turned on the Delete cookies and site data when Mullvad Browser is closed option and also made an exception for google.com to keep its cookies. Nevertheless, Google continued to log me out after I reopened Mullvad Browser.

Is there a particular setting I might have overlooked to ensure that site exceptions function as expected?

[felschr]

Did you set permissions.memory_only to false as suggested by #29 (comment)?

These are the user.js / about:config values I set (via Nix) that work for me:

Nix Config

{
  # Disable private browsing mode and enable restoring sessions
  "browser.privatebrowsing.autostart" = false;
  "browser.startup.page" = 3;

  # Enable persistence of site data
  "permissions.memory_only" = false;

  # Customise clear on shutdown
  "privacy.clearOnShutdown.cache" = true;
  "privacy.clearOnShutdown.cookies" = true;
  "privacy.clearOnShutdown.sessions" = true;
  "privacy.clearOnShutdown.offlineApps" = true;
  "privacy.clearOnShutdown.openWindows" = false;
  "privacy.clearOnShutdown.siteSettings" = false;
  "privacy.clearOnShutdown.downloads" = false;
  "privacy.clearOnShutdown.formdata" = false;
  "privacy.clearOnShutdown.history" = false;
}

Also, for Google you need to at least add the following URL to the exceptions:
https://accounts.google.com

Other URLs aren't strictly necessary to remain logged in, but might be beneficial to add to keep cache / local storage between browser restarts. E.g. in case of Proton Mail it's necessary to persist the local search index, which otherwise takes quite a while to rebuild.

[felschr]

All those settings except permissions.memory_only (afaIk) are exposed via the UI.
This is how the settings I mentioned should present in the UI:

[hanweikung]

Did you set permissions.memory_only to false as suggested by #29 (comment)?

These are the user.js / about:config values I set (via Nix) that work for me:
Nix Config

{
  # Disable private browsing mode and enable restoring sessions
  "browser.privatebrowsing.autostart" = false;
  "browser.startup.page" = 3;

  # Enable persistence of site data
  "permissions.memory_only" = false;

  # Customise clear on shutdown
  "privacy.clearOnShutdown.cache" = true;
  "privacy.clearOnShutdown.cookies" = true;
  "privacy.clearOnShutdown.sessions" = true;
  "privacy.clearOnShutdown.offlineApps" = true;
  "privacy.clearOnShutdown.openWindows" = false;
  "privacy.clearOnShutdown.siteSettings" = false;
  "privacy.clearOnShutdown.downloads" = false;
  "privacy.clearOnShutdown.formdata" = false;
  "privacy.clearOnShutdown.history" = false;
}

Also, for Google you need to at least add the following URL to the exceptions: https://accounts.google.com

Other URLs aren't strictly necessary to remain logged in, but might be beneficial to add to keep cache / local storage between browser restarts. E.g. in case of Proton Mail it's necessary to persist the local search index, which otherwise takes quite a while to rebuild.

I see. I did not touch permissions.memory_only. That was the reason. Thank you for clarifying.