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

Status: RESOLVED FIXED

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

Description

[Thomas Wisniewski [:twisniewski]]

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

[Anonymous]

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).

Comment 23

[Emma Zühlcke [:emz]]

Taking over this patch. This will need some work because we now need to integrate with the redesigned settings.

Comment 24

[Emma Zühlcke [:emz]]

Attachment: WIP: Bug 1767271 - Split clear-on-shutdown exceptions into a dedicated persist-data-on-shutdown permission. r=#anti-tracking

Today the "Manage Exceptions…" dialog under Cookies and Site Data writes the
"cookie" permission, which also disables Total Cookie Protection partitioning
for the listed sites. Users who add a clear-on-shutdown exception unknowingly
disable TCP for that site.

This change separates the two roles:

• "cookie" keeps its original meaning (cookie allow/deny/session, ETP
  relaxation) and no longer exempts a site from clear-on-shutdown.
• A new "persist-data-on-shutdown" permission is the dedicated shutdown
  exception. The Sanitizer consults it instead of "cookie" when deciding
  whether to keep a principal's data on shutdown.

The siteSettings cleaner now takes a clearHonoringExceptions argument:
shutdown uses CLEAR_SITE_PERMISSIONS so PermissionsCleaner preserves the
new exception type, while a manual Clear Now uses CLEAR_PERMISSIONS so the
user can wipe their exception list via the existing Site Settings UI. The
manual "Clear Recent History" dialog passes clearHonoringExceptions=false
for the same reason.

A new "Manage Exceptions…" button is added under the "Clear history when
Firefox closes" checkbox in both the redesigned History subpanel
(about:preferences#history) and the legacy custom-history layout. It opens
the permissions dialog with permissionType="persist-data-on-shutdown".

Comment 25

[Emma Zühlcke [:emz]]

Attachment: WIP: Bug 1767271 - Migrate existing cookie ALLOW exceptions to persist-data-on-shutdown. r=#anti-tracking

Existing users have set clear-on-shutdown exceptions via the old "cookie"
permission. After the permission split, those records no longer exempt a
site from shutdown clearing. To preserve user expectations across the
upgrade, bump APP_DATA_VERSION to 174 and duplicate each cookie ALLOW
permission as a persist-data-on-shutdown ALLOW.

DENY is not duplicated (irrelevant to persistence). SESSION is not
duplicated either: its "clear on shutdown" intent is preserved by the
SESSION-wins-over-exception branch in the Sanitizer, so making it an
exception too would be wrong.

The xpcshell test verifies the three capabilities behave as described and
that re-running the migration is idempotent.

Comment 26

[Emma Zühlcke [:emz]]

Attachment: WIP: Bug 1767271 - Tests for the persist-data-on-shutdown permission. r=#anti-tracking

Updates existing sanitize and cleardata tests to use the new permission
type where the test's intent was a clear-on-shutdown exception. Leaves
cookie permission usages alone where they're testing cookie behaviour
itself (DENY blocks cookies, SESSION semantics).

Adds:

• test_shutdown_exception_permission.js — rewritten to cover the
  permission split: CLEAR_SHUTDOWN_EXCEPTIONS targets
  persist-data-on-shutdown only, CLEAR_SITE_PERMISSIONS now also clears
  "cookie" while still preserving persist-data-on-shutdown.

• browser_shutdownClearingExceptions.js — end-to-end test for the new
  "Manage Exceptions…" button under "Clear history when Nightly closes",
  registered in both the legacy and settings-redesign privacy panes.
  Exercises the disabled-state bound to sanitizeOnShutdown, the
  permissions sub-dialog, and persistence across re-opens.

• Additional cases in browser_sanitize-cookie-exceptions.js covering
  cookie SESSION winning over a persist-data-on-shutdown exception
  (same principal and parent-domain), and parent-domain exceptions
  protecting subdomain data via the permission manager's ancestor walk.

• Additional cases in browser_sanitize-sitepermissions.js asserting that
  a manual Site Settings clear wipes persist-data-on-shutdown while a
  shutdown-context Site Settings clear preserves it.

Comment 27

[Emma Zühlcke [:emz]]

Attachment: Bug 1767271 - Split clear-on-shutdown exceptions into a dedicated persist-data-on-shutdown permission. r=#anti-tracking

Today the "Manage Exceptions…" dialog under Cookies and Site Data writes the
"cookie" permission, which also disables Total Cookie Protection partitioning
for the listed sites. Users who add a clear-on-shutdown exception unknowingly
disable TCP for that site.

This change separates the two roles:

• "cookie" keeps its original meaning (cookie allow/deny/session, ETP
  relaxation) and no longer exempts a site from clear-on-shutdown.
• A new "persist-data-on-shutdown" permission is the dedicated shutdown
  exception. The Sanitizer consults it instead of "cookie" when deciding
  whether to keep a principal's data on shutdown.

The siteSettings cleaner now takes a clearHonoringExceptions argument:
the shutdown path uses CLEAR_SITE_PERMISSIONS so PermissionsCleaner
preserves the new exception type, while a manual Clear Now uses
CLEAR_PERMISSIONS so the user can wipe their exception list via the
existing Site Settings UI. The manual "Clear Recent History" dialog
relies on the default falsy clearHonoringExceptions to take the manual
branch automatically.

A new "Manage Exceptions…" button is added under the "Clear history when
Firefox closes" checkbox in both the redesigned History subpanel
(about:preferences#history) and the legacy custom-history layout. It opens
the permissions dialog with permissionType="persist-data-on-shutdown".

Comment 28

[Emma Zühlcke [:emz]]

Attachment: Bug 1767271 - Migrate existing cookie ALLOW exceptions to persist-data-on-shutdown. r=#anti-tracking

Existing users have set clear-on-shutdown exceptions via the old "cookie"
permission. After the permission split, those records no longer exempt a
site from shutdown clearing. To preserve user expectations across the
upgrade, bump APP_DATA_VERSION to 174 and duplicate each cookie ALLOW
permission as a persist-data-on-shutdown ALLOW.

DENY is not duplicated (irrelevant to persistence). SESSION is not
duplicated either: its "clear on shutdown" intent is preserved by the
SESSION-wins-over-exception branch in the Sanitizer, so making it an
exception too would be wrong.

The xpcshell test verifies the three capabilities behave as described and
that re-running the migration is idempotent.

Comment 29

[Emma Zühlcke [:emz]]

Attachment: Bug 1767271 - Tests for the persist-data-on-shutdown permission. r=#anti-tracking

Updates existing sanitize and cleardata tests to use the new permission
type where the test's intent was a clear-on-shutdown exception. Leaves
cookie permission usages alone where they're testing cookie behaviour
itself (DENY blocks cookies, SESSION semantics).

Adds:

• test_shutdown_exception_permission.js — rewritten to cover the
  permission split: CLEAR_SHUTDOWN_EXCEPTIONS targets
  persist-data-on-shutdown only, CLEAR_SITE_PERMISSIONS now also clears
  "cookie" while still preserving persist-data-on-shutdown.

• browser_shutdownClearingExceptions.js — focused mochitest for the new
  "Manage Exceptions…" button under "Clear history when Firefox closes",
  registered in both the legacy and settings-redesign privacy panes.
  Asserts the button's disabled state follows
  privacy.sanitize.sanitizeOnShutdown, and that clicking it opens the
  permissions sub-dialog wired for permissionType="persist-data-on-shutdown".
  Generic permissions-dialog mechanics (add/save/cancel/remove) are
  already owned by existing tests under preferences/tests/etp/.

• Additional cases in browser_sanitize-cookie-exceptions.js covering
  cookie SESSION winning over a persist-data-on-shutdown exception
  (same principal and parent-domain), parent-domain exceptions
  protecting subdomain data via the permission manager's ancestor walk,
  and the "general sanitizeOnShutdown is off but a few SESSION origins
  are tagged" flow (SESSION origins cleared, untagged origins preserved).

• Additional cases in browser_sanitize-sitepermissions.js asserting that
  a manual Site Settings clear wipes persist-data-on-shutdown while a
  shutdown-context Site Settings clear preserves it.

Comment 30

[Emma Zühlcke [:emz]]

Attachment: Bug 1767271 - Update data-sanitization docs for the persist-data-on-shutdown split. r=#anti-tracking

Reflects the permission split in the antitracking data-sanitization
reference:

• "cookie" ALLOW no longer exempts a site from clear-on-shutdown.
• "persist-data-on-shutdown" ALLOW is the new exception, with a note
  that "cookie" SESSION on the same principal still forces clearing.
• siteSettings clearing now distinguishes the shutdown path
  (CLEAR_SITE_PERMISSIONS, exception preserved) from the manual Clear
  Now path (CLEAR_PERMISSIONS, exception wiped) so the existing UI can
  fully clear the exception list.

Comment 31

[Emma Zühlcke [:emz]]

Fenix also has a clear on shutdown feature, but it looks like they don't have an exception mechanism. No code updates needed for Fenix specifically and no migration.

Comment 32

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/749dcbeb9b45
https://hg.mozilla.org/integration/autoland/rev/69a567a9df5c
Split clear-on-shutdown exceptions into a dedicated persist-data-on-shutdown permission. r=fluent-reviewers,bvandersloot,Gijs,bolsson
https://github.com/mozilla-firefox/firefox/commit/8ea362e9a6e9
https://hg.mozilla.org/integration/autoland/rev/7166aacf7dc1
Migrate existing cookie ALLOW exceptions to persist-data-on-shutdown. r=firefox-desktop-core-reviewers ,bvandersloot,Gijs
https://github.com/mozilla-firefox/firefox/commit/d42e4cab589e
https://hg.mozilla.org/integration/autoland/rev/ffd1357e6177
Tests for the persist-data-on-shutdown permission. r=bvandersloot,Gijs
https://github.com/mozilla-firefox/firefox/commit/759fde4ff924
https://hg.mozilla.org/integration/autoland/rev/d7f249df4e73
Update data-sanitization docs for the persist-data-on-shutdown split. r=bvandersloot

Comment 33

[Emma Zühlcke [:emz]]

Good news: I've managed to incorporate the new (separate) shutdown clearing exceptions in both the old and the new settings design. I've also added a migration so all cookie allow exceptions are copied to the shutdown clearing exceptions one time. Feel free to manually delete the cookie allow exceptions in the other dialog if you no longer need them.

Comment 34

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/69a567a9df5c
https://hg.mozilla.org/mozilla-central/rev/7166aacf7dc1
https://hg.mozilla.org/mozilla-central/rev/ffd1357e6177
https://hg.mozilla.org/mozilla-central/rev/d7f249df4e73

Comment 35

[Thorin [:thorin]]

This would be nice to have in ESR153, but IDK if you're willing to do that (i.e current beta) - maybe backport later after it's had time to bake?

Comment 36

[Emma Zühlcke [:emz]]

(In reply to Thorin [:thorin] from comment #35)

This would be nice to have in ESR153, but IDK if you're willing to do that (i.e current beta) - maybe backport later after it's had time to bake?

Sorry, I think it's too risky for an uplift or a backport. It also contains a migration which makes it more complex.

Comment 37

[Dianna Smith [:diannaS]]

:emz Did you want to include this in the 154 release notes? Please nominate if so.

Comment 38

[Emma Zühlcke [:emz]]

Release Note Request (optional, but appreciated)
[Why is this notable]:
Clear on shutdown exceptions used to rely on the same permission as cookie exceptions. That meant if a user wanted to exempt a site from shutdown clearing they would also allow it to set cookies and bypass some tracking protections. Now shutdown exceptions are separate permissions and do not influence cookie settings.

[Suggested wording]:
Exceptions for sites that have their cookies & site data cleared on shutdown can now be set without exempting the site from tracking protection and other cookie restrictions.
[Links (documentation, blog post, etc)]: -