Open Bug 1526246 Opened 5 years ago Updated 2 years ago

DOM Cache API is not cleared by the browsingData extension API "serviceWorkers" and "cache" options

Categories

(WebExtensions :: General, defect, P3)

65 Branch
Desktop
Unspecified
defect

Tracking

(Not tracked)

People

(Reporter: contact, Unassigned)

References

Details

Service workers cache assets that can be cleared with the browsingData API according to the docs, but the API unregisters service workers without clearing the cached data.

browser.browsingData.remove({}, {serviceWorkers: true})

The Cache API is also available to pages and can be accessed from the window.caches interface. Clearing the cache using browsingData does not clear data saved using the Cache API.

browser.browsingData.remove({}, {cache: true})

This enables tracking users that rely on extensions to clear browsing data.

Save the user ID:
window.caches.open('userid')

Get the user ID on future visits:
window.caches.keys().then(keys => console.log(keys[0]))

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/browsingData/remove

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/browsingData/DataTypeSet

Component: Security → DOM: Service Workers
Product: Firefox → Core

Moving to WebExtensions for triage.

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/browsingData/DataTypeSet#Type indeed does appear to indicate that the "serviceWorkers" setting should also be clearing out the DOM Cache API storage, and nothing else covers it.

Right now the serviceWorkers option uses ServiceWorkerCleanup.RemoveAll(), which will remove all ServiceWorkers across all origins, which is a bit much. It probably makes sense to use removeFromPrincipal() instead?

And to address the DOM Cache API clearing, quotaManagerService.clearStoragesForPrincipal(principal, "default", "cache"); should be used.

Component: DOM: Service Workers → General
Product: Core → WebExtensions
Summary: Cache is not cleared by the browsingData extension API → DOM Cache API is not cleared by the browsingData extension API "serviceWorkers" option
Priority: P3 → --

We rely on ServiceWorkerCleanUp.jsm for this, which is the same implementation that the data sanitization UI uses.

Component: General → Data Sanitization
Product: WebExtensions → Toolkit

(In reply to Kris Maglione [:kmag] from comment #2)

We rely on ServiceWorkerCleanUp.jsm for this, which is the same implementation that the data sanitization UI uses.

ServiceWorkerCleanUp is a hack for cleaning up the Service Worker Registrations only. This will wipe out the ServiceWorker registrations and the hidden chrome-namespaced DOM Cache API storage that stores the offlines ServiceWorker script and dependencies, but is explicitly not for clearing content-space DOM Cache API storages. In the future when bug 1183245 is fixed, ServiceWorkerCleanUp will go away and automatically purge registrations when DOM Cache API storage for the origin is wiped (via QuotaManager).

The browsingData API is unique in that it provides a granularity of removal options via browsingData.DataTypeSet that is not exposed by any Firefox UI. All Firefox UI (now) cleans up at the granularity of "offline apps" (or "cookies and site data"), which uses a combination of the hacky ServiceWorkerCleanUp and quotaManagerService.clearStoragesForPrincipal to clean up all QuotaManager clients (which includes IndexedDB, DOM Cache API, and imminently LocalStorage NextGen).

It does seem like the browsingData API is a bit of a foot-gun in terms of design; all data in an origin's storage bucket should be wiped at the same time to stick to the spec and avoid sites breaking or privacy-focused extensions accidentally leaving around super-cookie components. But if the API is going to be implemented as documented at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/browsingData/DataTypeSet, then the code should be explicitly wiping the "cache" QuotaManager client as in comment 1 or gain some other type of property on DataTypeSet that maps to that underlying operation (and is documented to that effect).

A better option, in my mind, would be to map at least both "indexedDB" and "serviceWorkers" to "offlineApps" as understood by the Sanitizer logic. That way you can indeed use the same implementation that the data sanitization UI uses.

Moving back to WebExtensions but cc'ing the folks who maintain the logic in question in case they have a different opinion for this.

Component: Data Sanitization → General
Product: Toolkit → WebExtensions

So, generally, ext-browsingData.js should start using nsIClearDataService and just pass the correct flags. Maybe we can mentor someone to make that change.

That would kind of imply just going with Andrew's suggestion in comment 3, I think.

Priority: -- → P3
Summary: DOM Cache API is not cleared by the browsingData extension API "serviceWorkers" option → DOM Cache API is not cleared by the browsingData extension API "serviceWorkers" and "cache" options

Those looking for a temporary solution can disable the Cache API by setting about:config?filter=dom.caches.enabled to false.

Chrome 72 has introduced the cacheStorage data type, and they no longer clear the DOM cache when browser.browsingData.remove({}, {cache: true}) is called.

https://developer.chrome.com/extensions/browsingData#method-removeCacheStorage

Blocks: 1760023

I am able to clear the "cache" data (from bug report at bug 1760023) with the following snippet:

Services.qms.clearStoragesForPrincipal(
 Services.scriptSecurityManager.createContentPrincipalFromOrigin("https://www.reddit.com"),
 null,
 "cache"
);

So it seems that we can support the "cacheStorage" data type, by adding the a similar snippet like the above at https://searchfox.org/mozilla-central/rev/f8db81665dc2833fff09dc7eef200539ac1fd351/toolkit/components/extensions/parent/ext-browsingData.js#170-182, and hooking that up at

Patches are welcome :)

Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.