Open Bug 1730197 Opened 3 years ago Updated 1 year ago

Clear site Data broadcasts cross-origin domains to content processes

Categories

(Toolkit :: Data Sanitization, defect, P3)

defect

Tracking

()

People

(Reporter: tjr, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [sp3])

Since Bug 1499868 was filed, the Clear-Site-Data implementation has changed significantly. Reading the code however, I see several patterns of the form for (auto* cp : ContentParent::AllProcesses(ContentParent::eLive)) which appear to broadcast origin data to unnecessary content processes.

However I'm not certain about that. For example can example.com tell ritter.vg that any images from example.com in ritter.vg's cache should be expired? (I suppose so...) In that case the broad is necessary... except it winds up broadcasting the fact that the user visited example.com (and it sent the Clear-Site-Data header) to content processes that doesn't have an example.com image in its cache!

I think we need to get a better understanding of when example.com sends a Clear-Site-Data header of some type, what sets sent to non-example.com content processes (necessarily or unnecessarily) and from there we can understand the amount of leakage and what - if anything - can be done to limit it. I'm hoping Paul can help us understand this.

Flags: needinfo?(pbz)
Component: Applied Machine Learning → Data Sanitization
Product: Core → Toolkit

For context:
The Clear-Site-Data header gets processed in the parent process. ClearSiteData.cpp calls the ClearDataService here: https://searchfox.org/mozilla-central/rev/13378066961f195595822d4f543c8ac5b7f46490/toolkit/components/clearsitedata/ClearSiteData.cpp#213
That means in order to clear the in-memory image and stylesheet caches we need to have IPC with the affected content processes.

The pattern of clearing via broadcast for a specific principal isn't new. For the stylesheet cache it was added in Bug 1662987.
When a site sends the Clear-Site-Data header, in order to clear caches, we'll broadcast the storage principal to all active content processes.

There are plans to remove the "cache" feature from Clear-Site-Data, see Bug 1671182. However, there are concerns about web breakage.
Removing this feature would fix the issue partially. However, there is still another consumer: The methods linked above are also called when the user manually clears site data. Instead of a principal, the base domain will be passed, which could still leak information.

Emilio, from the perspective of the stylesheet cache, do you think we could be more specific about which content process we send the clear messages to, given a specific principal or a base domain?
I'm not an expert on the Fission architecture, but I imagine Bug 1491018 could be a dependency for that.

Flags: needinfo?(pbz) → needinfo?(emilio)
See Also: → 1671182

Yeah, I agree that's bug 1491018 basically.

Flags: needinfo?(emilio)

Thanks!
To re-iterate, I think fixing Bug 1671182, removing web callers of the broadcasting methods, would definitely improve the situation.

Heads up that bug 1671182 was fixed, not sure if that means all cases of this are gone now, if someone feels motivated you could check :)

(In reply to Johann Hofmann [:johannh] from comment #4)

Heads up that bug 1671182 was fixed, not sure if that means all cases of this are gone now, if someone feels motivated you could check :)

From the "Clear-Site-Data" header perspective yes. However, we will still broadcast if users clear data e.g. via preferences.

The severity field is not set for this bug.
:johannh, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jhofmann)
Severity: -- → S4
Flags: needinfo?(jhofmann)
Priority: -- → P3
Whiteboard: [sp3]
You need to log in before you can comment on or make changes to this bug.