Increasing granularity of storage directive

[asakusuma]

For folks wanting to use the storage directive to remove a bad service worker, storage is probably going to cause collateral damage, since service workers can't even touch several of the storage APIs, like localStorage and sessionStorage. I would prefer a directive that only remove service workers + async storage APIs, which are the only storage APIs accessible from a service worker.

[annevk]

But those APIs are accessible from other contexts as well so you might still get collateral damage. The way to solve this is by addressing whatwg/storage#2 I think and then developers can use specific buckets for "suborigin" applications and clear those when needed.

[asakusuma]

But those APIs are accessible from other contexts as well so you might still get collateral damage

True, but I would argue that removing all IDB and Cache data, including data potentially created from another context, is necessary to guarantee that a service worker issue is not propagated via storage. Removing localStorage is unnecessary, since there's no chance the service worker could have tainted localStorage data.

@annevk so are you proposing that CSD could specify a bucket identifier as an argument to the storage directive?

[annevk]

Well, but the localStorage data might depend on there being something in the Cache API or there being a service worker.

An approach where developers get to decide what the independent storage buckets are and some control over removing them atomically seems preferable. (And yeah, an identifier might be the way to go.)

[asakusuma]

Yea true, there could be localStorage data indirectly affected by the service worker.

I agree that a first-class mechanism for granular control over storage buckets in general is a better approach, closing in favor of whatwg/storage#2