1629667 - Site Data Manager clears localStorage and SessionStorage cross-origin

Status: RESOLVED WONTFIX

(Toolkit :: Data Sanitization, defect, P2)

Description

[Steven Englehardt [:englehardt]]

STR:

1. In a fresh profile go to https://senglehardt.com/test/dfpi/first_and_third.html. Note the random value set in the test.senglehardt.com iframe.
2. In about:preferences#privacy click "manage data" and select senglehardt.com, click "Remove Selected". Save changes and confirm
3. Reload the test page.

ER: Only the senglehardt.com iframe has its storage reset.

AR: the localStorage and sessionStorage data for the test.senglehardt.com is also reset.

This doesn't reproduce in the other direction; that is, clearing test.senglehardt.com will not clear senglehardt.com.

Comment 1

[Johann Hofmann [:johannh]]

So this is interesting because it's sort of the opposite of bug 1629658. Sub-domain clearing for localStorage is implemented in, as I mentioned, https://searchfox.org/mozilla-central/rev/a4d62e09a4c46aef918667fa759bf9ae898dc258/toolkit/components/cleardata/ClearDataService.jsm#561. This will cause all lower-level domains (anything with more subdomains) of the given host to be cleared, which explains why clearing test.senglehardt.com doesn't clear senglehardt.com.

In bug 1629658 I suggested that we extend this practice to all quota storage when clearing by host through ClearDataService, but I understand that in the case of site data manager this may not actually be desirable.

Maybe we should instead remove the sub-domain clearing from clearDataService entirely and instead clear all affected host individually.

(We can still fix this issue mentioned in bug 1628240 in ClearDataService by going through all available principals and checking for host to ensure we cover all ports).

Complicated stuff.

Comment 2

[Tom Tung [:tt, :ttung]]

Sub-domain clearing for localStorage is implemented in, as I mentioned, https://searchfox.org/mozilla-central/rev/a4d62e09a4c46aef918667fa759bf9ae898dc258/toolkit/components/cleardata/ClearDataService.jsm#561. This will cause all lower-level domains (anything with more subdomains) of the given host to be cleared, which explains why clearing test.senglehardt.com doesn't clear senglehardt.com.

To elaborate more, we collect all origins in the user's dom storage profiles at https://searchfox.org/mozilla-central/rev/1843375acbbca68127713e402be222350ac99301/toolkit/components/cleardata/ClearDataService.jsm#530

And check whether the origin has the root domain with the requested origin in https://searchfox.org/mozilla-central/rev/1843375acbbca68127713e402be222350ac99301/toolkit/components/cleardata/ClearDataService.jsm#549

Then, clear matched origins at https://searchfox.org/mozilla-central/rev/1843375acbbca68127713e402be222350ac99301/toolkit/components/cleardata/ClearDataService.jsm#552

If we want to switch to only clear the requested host/origin individually, we only need to remove the former two steps for QuotaCleaner.

Maybe we should instead remove the sub-domain clearing from clearDataService entirely and instead clear all affected host individually.

I remember a use case for removing the sub-domain clearing from clearDataService entirely is that, says, we have storage like:

• foo.com
• music.foo.com
• mail.foo.com

When the storage for "foo.com" is requested to be removed, we should probably remove the storage for "music.foo.com", and for "mail.foo.com" since these storages (e.g. Cookie) might have connections with each other.

However, I just notice that Cookie now only remove the exact host in deleteByHost at https://searchfox.org/mozilla-central/rev/1843375acbbca68127713e402be222350ac99301/toolkit/components/cleardata/ClearDataService.jsm#73 since FF77.

So, what I remember is probably wrong or not valid and QutoaCleaner probably needs to clean the exact host in deleteByHost to aligning the behavior with Cookie?

Comment 3

[Emma Zühlcke [:emz]]

Since the work on Bug 1646215 we're clearing site data either by principal, or if user triggered, we clear data for the entire base domain.