1767271 - Add a way for cookie-clearing exceptions to not also affect cookie partitioning

Status: ASSIGNED

(Core :: Privacy: Anti-Tracking, enhancement, P2)

Description

[Thomas Wisniewski [:twisniewski][PTO until Mar.16]]

Right now, I believe that if a user sets a cookie-clearing exception (via Cookies and Site data > Delete cookies and site data when Firefox closes > Manage Exceptions), it also ends up disabling partitioning for that cookie.

According to :pbz, this should be because the two share the same underlying permission, rather than having a separate one for each use-case.

I'm not 100% sure what implications it would have to add this complexity, given that cookie-clearing is less relevant with partitioning on, but it sounds like something that would at least be nice to have (as there will always be desired exceptions, especially for users wishing to be as strict as possible).

Comment 1

[Fabrizio]

As Total Cookie Protection has been shipped to all Firefox users I think this ticket is very very relevant.

Given that TCP is presented in the ETP section of the UI, and exceptions are instead in the Cookie and Site Data part, it is also not very easy to figure out for end users that they might be disabling partitioning for a certain domain. On top of that it is most likely to affect users who want to sanitize on close (so privacy conscious ones), and who are instead introducing a hole in this otherwise great mechanism.

Comment 2

[Adam Yorns [:debsidian]]

Bump

Comment 3

[u716861]

Oh wow this is a horrific discovery.

Comment 4

[Emma Zühlcke [:emz]]

We had a brief discussion with the team about this today. The overlap of this permission seems unexpected for users so this is worth addressing.

I'm in favor of changing the permission used for shutdown clearing exceptions to a new one. Updating our existing cookie permission that's consumed all over anti-tracking code is probably more work.
When we switch over we also need to migrate existing values over. Since we can't tell apart "cookie" exceptions and clear-on-shutdown exceptions we should migrate everything over and only separate the mechanism going forward.

Comment 5

[ashirg]

Apologies for the comment without any additional information, but is this issue still planned to be addressed? There do not seem to be any comments since five months ago, so it is not clear to me.

While I would like to fix it myself, I do not have enough experience with the source code (namely zero) to actually conduct such a large change by myself.

Comment 6

[Emma Zühlcke [:emz]]

Apologies for the comment without any additional information, but is this issue still planned to be addressed? There do not seem to be any comments since five months ago, so it is not clear to me.

While I would like to fix it myself, I do not have enough experience with the source code (namely zero) to actually conduct such a large change by myself.

Yes! But we can't prioritize it in the short-term. I'm adding this to our internal backlog.

Comment 7

[Emma Zühlcke [:emz]]

Ideally we can split up the two permissions into separate permissions with separate management UI:

1. "cookie" permissions: These can be used to relax cookie restrictions for specific sites, such as disabling Total Cookie Protection, or enabling cookies if they're blocked globally. They can also be used to have stricter rules or block cookies for a specific site. This permission is currently exposed via the permissions panel when you visit a site, it's also shown in the pageInfo window permissions tab. They also need a global management UI in preferences (that's currently the "manage exceptions" button).
2. "shutdownclearing" exception permissions (NEW): These will be used for exempting sites from being cleared on shutdown by our Sanitizer.sys.mjs code. To preserve current functionality they should also support clearing only specific sites by setting not an ALLOW for the permission value/capability but e.g. a SESSION. This permission does not have to exposed on a per-site basis in the permission panel or pageInfo window.

As already mentioned, when splitting up the two permissions we will need a migration mechanism so that all "cookie" permissions are also added as shutdown exceptions one-off. After the migration they will be split.

Comment 9

[kovyngnm8]

Atleast inform users about this. It is privacy nightmare.

Comment 10

[Emma Zühlcke [:emz]]

https://searchfox.org/mozilla-central/query/default?q=calls-to%3A%27mozilla%3A%3Anet%3A%3ACookieJarSettings%3A%3ACookiePermission%27%20depth%3A4 shows all the calls to the cookie permission getter.

I believe this is where partitioning gets disabled for explicit "cookie" ALLOW permissions: https://searchfox.org/mozilla-central/rev/4582d908c17fbf7924f5699609fe4a12c28ddc4a/toolkit/components/antitracking/StorageAccess.cpp#484

Comment 11

[Emma Zühlcke [:emz]]

William, would you like to take this one next? This work would involve adding a separate permission type / id for clearing on shutdown.

Comment 12

[William Wen (:wwen)]

Yeah I can definitely take this one after I fix up 1658094. Would extra UI elements be in the scope of this bug or would this just be separating the two permissions with a way to add them independently coming later?

Comment 13

[William Wen (:wwen)]

Attachment: Bug 1767271 - Add new permission for shutdown exceptions. r=pbz

Comment 14

[m.fessler]

(In reply to u716861 from comment #3)

Oh wow this is a horrific discovery.

Sorry for the disturbance, but can someone please explain to me how this affects me as a user who uses "cookie + site data delete on close" with exceptions?
Is this feature not working properly or does it reduce security when handling cookies?
Many thanks and regards, Martin

Comment 15

[Ed]

See https://www.reddit.com/r/firefox/comments/1k464n9/eli5_cookieclearing_exceptions_affecting_cookie/.

Comment 16

[bugzilla]

Glad to see there's been effort put into this, thank you @wwen.

The last comment on the proposed fix is from Aug 2024 and states "we're still blocked on a final UX". Any chance we can get an update on the status?

Comment 17

[XE]

This bug was elevated from P3 to P2 7 months ago.

Mozilla defines P2 as:

Fix in the next release cycle or the following (nightly + 1 or nightly + 2)

Nightly was 142a at the time status was changed to P2. (+1 would've been 143a, +2 would've been 144a)

Is something blocking progress on this issue? Is progress being made behind the scenes?

A status update would be much appreciated.

Comment 18

[ajchow666]

(In reply to XE from comment #17)

This bug was elevated from P3 to P2 7 months ago.

Mozilla defines P2 as:

Fix in the next release cycle or the following (nightly + 1 or nightly + 2)

Nightly was 142a at the time status was changed to P2. (+1 would've been 143a, +2 would've been 144a)

Is something blocking progress on this issue? Is progress being made behind the scenes?

A status update would be much appreciated.

Apparently it has been fixed since August of last year but has yet to be accepted pending changes based on the revision attached to the bug report: https://phabricator.services.mozilla.com/D215233

Comment 19

[William Wen (:wwen)]

This work was blocked on new UI for the additional menus that would be required. iirc this was pushed to be either part of or post settings redesign and I am not sure what the progress on that is right now.

@emz: maybe you have a better answer on this?

Comment 20

[Emma Zühlcke [:emz]]

Settings redesign is currently WIP. You can already see some of it in Nightly if you flip browser.settings-redesign.enabled.

We'll revisit this bug once we've shipped the new design. Keeping the NI.

Comment 21

[Alexander Labrie]

This has a high impact as most users are unaware of the privacy implication and there is no workaround, severity should be S2.

Comment 22

[DylDyx]

Does this also affect cookies when Multi Account Containers are in use? For example, if a user sets firefox to delete cookies on quit but has exceptions for sites to maintain logins, but only uses those sites within specific Multi Account Containers rather than a bare tab with FPI (which is broken in this case when exceptions are made).