Can't clear site data while offline

[ithinkihaveacat]

Since clear-site-data is "only respected on responses fetched over network, and not those served by a service worker", it can't be made to work offline.

This means that a "logout" action that involves the use of clear-site-data cannot complete until the user agent is online.

I don't see how this can be fixed, but it's unfortunate.

[msramek]

I have talked to several people building service worker-based apps that were considering using Clear-Site-Data as a way to clean up after themselves. This seems to be indeed a popular usecase.

And the solution is not actually difficult. For simplicity (of spec and implementation), we proposed to completely disable Clear-Site-Data for service workers; but we could still allow them on requests that are same origin (worker <-> resource). The only risk we were protecting against was the service worker impersonating other origins.

[ithinkihaveacat]

Can the rules that decide whether a response is opaque or not be re-used to control whether clear-site-data works?

[Krinkle]

Being able to "log out" and securely wipe all traces of a web app should indeed be possible offline.

There may be cases where individual web app authors may prefer to be online and not support it while offline (e.g. if they want to clear stuff server-side as well) but that's not a reason not to offer the ability in the web platform.

Back to the offline scenario, I think it might make sense to expose the "Clear site data" feature through a JavaScript interface to the worker. E.g. self.navigation.clearSiteData() or some such.

That way we can keep the restriction on the HTTP header to be limited to online fetched resources. It avoids any possibility of poisoning or circumvention through caches or any other intervention, whilst still explicitly granting a Service Worker to pull the plug through a programmatic interface, which naturally works offline (and would as such, could also remove the Service Worker itself and make site no longer offline available).

[msramek]

@ithinkihaveacat Opaque responses are probably not a good precedent. Those can still set cookies, so prohibiting them from deleting cookies (...and other datatypes coming along with clear site data...) does not seem like the right choice.

And since we're talking about consistency between setting and deleting cookies, note that service workers can't add/modify the Set-Cookie header either. So from consistency perspective, keeping the current behavior is desirable.

We discussed this with @mikewest today and came to the same conclusion as you do, @Krinkle . The JS API is actually already spec'd (https://www.w3.org/TR/clear-site-data/#dom-api). Header is a good tool for a server requesting this functionality, but when you already have JS running locally, there's no reason not to use that.

[msramek]

And more to the topic of consistency with Set-Cookie.

Instead of having to explain the intricacies of service workers in the Clear-Site-Data spec, would it be perhaps cleaner to define Clear-Site-Data as a forbidden-response-header-name? Which means that the header simply can't be modified from JavaScript. So we would have a perfect separation - header for servers, JS API for JS.

@annevk , @mikewest , WDYT?

[annevk]

I think once you integrate with Fetch to define when the header gets processed it'll automatically fall out that service workers are not (or are, depending on what you do) considered. That integration is necessary anyway, otherwise it's not defined from first principles when this header is processed.

[mikewest]

Being able to "log out" and securely wipe all traces of a web app should indeed be possible offline.

I agree with @msramek that providing an API hanging off of navigator.storage is probably the right thing to do. We dropped it from the editor's draft both because we didn't need it for the bits we initially shipped, and because it probably fits better in the Storage spec than as a standalone in this spec. It does seem like a useful thing to add to the platform in one way or another.

I think once you integrate with Fetch to define when the header gets processed it'll automatically fall out that service workers are not (or are, depending on what you do) considered. That integration is necessary anyway, otherwise it's not defined from first principles when this header is processed.

We're currently threading Clear-Site-Data processing through HTTP-network fetch in order to avoid the Service Worker entirely. That might or might not be a reasonable thing to do. Adding Clear-Site-Data as a forbidden response header might be reasonable, but doesn't seem necessary if we integrate as described above. One of the concerns it wouldn't address, for example, is replaying a third-party clearing action (e.g. a Service Worker caches the response to /logout, and replays it to destroy user data), which I think is a reasonable thing to be concerned about.

@msramek: Are you interested in extracting the monkey patch in https://w3c.github.io/webappsec-clear-site-data/#fetch-integration out into a PR against Fetch for deeper discussion? (@annevk: Would you accept a patch against Fetch given that there's only one implementation?)

[annevk]

Are other implementations interested in this? I'd assume so. In any event, adding a single step with a note seems fine. We can add a source comment to indicate the implementation status.

[mikewest]

Are other implementations interested in this? I'd assume so.

I believe so, yes. Folks were positive at TPAC. But no one I know of is actively working on an implementation, so... In any event, if you're happy adding it to Fetch, I'd be thrilled to get it out of this document. :)

[msramek]

I'm interpreting @annevk 's thumbs up as yes. OK then, I'll send a PR for Fetch.

[asakusuma]

Storage buckets might address this concern, since you can delete a bucket and service workers can be put in a bucket.

https://github.com/WICG/storage-buckets/blob/gh-pages/explainer.md#deleting-buckets