browsingData RemovalOptions

[sammacbeth]

The chrome.browsingData API provides extensions various methods for removing browser storage (cache, cookies, history etc). These methods take a RemovalOptions argument, which allows control over what data is deleted. These options, however, differ per platform:

• Chrome: excludeOrigins, originTypes, origins, since.
• Firefox: cookieStoreId, hostnames, originTypes, since.

The primary incompatibility is the options that specify which storage is included or excluded from a removal operation. On Chrome, one must specify origins, and both inclusive (only delete storage from this set of origins) and exclusive (delete everything except storage from this set of origins) filters are supported. Firefox only supports inclusive filtering, and uses hostnames instead of origins.

Extensions using this API commonly do so to 'clean' browser storage for performance and/or privacy use-cases. With that use-case, users might wish to preserve data for some sites they're logged in. This requires the exclusive filtering case, which is missing on Firefox. Storage clearing extensions seem to be popular on extension stores, with multiple with 100k+ users. DuckDuckGo is also currently looking into using this API to ship our fire button feature to our extension.

We'd be interested to hear from browser vendors:

• If Firefox would be willing to support the inclusive filtering case (equivalent to Chrome's excludeOrigins).
• If the filtering options could be aligned to either require origins or hostnames. On MDN additional clarification is provided to state that the Firefox API does not expect origins, which indicates some developer confusion due to this difference.
• If there is any interest from Safari in adding support for this API in the future.

[zombie]

• If Firefox would be willing to support the inclusive filtering case (equivalent to Chrome's excludeOrigins).

I'm in favor of this, though I'd have to check technical feasibility, if our underlying platform storage can easily supports this.

• If the filtering options could be aligned to either require origins or hostnames. On MDN additional clarification is provided to state that the Firefox API does not expect origins, which indicates some developer confusion due to this difference.

Firefox supported hostnames about 2 years before Chrome added origins, and the MDN tries to clarify for folks expecting Chromium names in Firefox.

[zombie]

I believe this page has up to date info about how partitioning works in Firefox, as discussed in today's meeting: https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning

[Rob--W]

Pasting today's meeting notes since it includes relevant external links:

• [timothy] Currently no plans to implement this in Safari.
• [rob] Supportive in Firefox (tracking bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1632796). Patches are welcome.
• [rob] A consideration here is what it means to include or exclude. These days Firefox (and Safari) partition storage by top-level site, so storage is not just keyed by one origin, but double-keyed by two origins. What does it mean to include or exclude an origin in the API? Would we need new options?
• [oliver] Storage partitioning hasn't shipped in Chrome, but will ship at some point.
• [sam] For our use case, we often want to clear everything except specific sites where you're logged in.
• [tomislav] Please add a comment to the issue to describe this use case.
• [sam] How about the cookieStoreId property?
• [rob] cookieStoreId is meant to be relatively scoped and doesn't scale well to one for every website. In the Cookies API I introduced a “partitionKey” concept to cover storage partitioning.
  • https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/cookies#storage_partitioning
  • I have discussed this before in discussions in the Privacy CG, at How do Partitioned cookies interact with browser extensions? privacycg/CHIPS#6
• [simeon] Going back to the question of whether this should clear only the top level origin or if it should cascade into partitions, my gut feeling is that we should default to cascading as that more closely matches my expectations as a developer. That said, partitionKey sounds like a useful capability. May be better to expose this as a control than take an opinionated stance in the API.
• [sam] How do browsers feel about origins vs. hostnames?
• [rob] Please compare origins and hostnames and show the current and desired behavior in Firefox/Chrome. I expect origins to be a more useful primitive in the long term, but that needs to be verified.

[sammacbeth]

Following up from the discussion yesterday, there is some additional complexity here given that browsers may be partitioning storage. This could cause confusing with how origins and excludeOrigins might interact with partitions.

Proposal: Allow extension developers to be explicit about partition handling by adding new options partitionKeys and excludePartitionKeys. These would function similarly to origins and excludeOrigins, but operate on partitions only. If they are excluded, we assume the operation operates on all partitions. Some examples:

• { origins: ['https://example.com'] } - Clear data for example.com across all partitions.
• { excludeOrigins: ['https://example.com'] } - Clear data for all origins across all partitions, except for example.com.
  • This would still remove data for other origins inside the example.com partition.
• { partitionKeys: ['https://example.com'] } - Clear data for all origins in the example.com partition.
• { excludePartitionKeys: ['https://example.com'] } - Clear all partitions except example.com
  • Data for other origins in the example.com partition is not removed.
• { partitionKeys: ['https://example.com'], excludeOrigins: ['https://example.com'] } - Clear data for all origins except example.com in the example.com partition (i.e. all 3rd-party storage when on example.com).

This change would therefore be backwards compatible (calls with origins and excludeOrigins work as they do currently), but with more powerful filters for more complex use-cases. For example:

• Using excludePartitionKeys as a more robust way of preventing a user being logged out on a site that relies on 3rd-party auth providers.
• Being able to remove all storage used on a specific site, without causing side effects on other sites.