In 2.1:

If the value of the header’s data-type-list contains cookies or *, then all cookies which would be sent along with any request to the response’s url's host MUST be removed.

This seems to contradict 3.4.4. Namely, if subdomain.example.com sends the clear cookie header, 2.1 implies that a cookie for .example.com would be cleared (since it would have been sent to all subdomains).

FYI: We've published this as an FPWD: http://www.w3.org/TR/clear-site-data/

@diracdeltas: Cookies are nuts. Help.

Basically, I'm not really sure what the right behavior is here. Because cookies implicitly span domains, it's tough to reason about them within an origin-based system. In particular, consider social-network.example.com wants to use this to clear locally stored data on logout, but example.com would murder them in their sleep if they cleared all your state on example.com while doing so.

WDYT, oh great and powerful keepers of the web's architecture?

/cc @slightlyoff @mnot

Should this be Clear-Origin-Data?

WRT Cookies - hm. Giving JS on subdomain.example.com the power to clear a HTTPOnly cookie for *.example.com is... interesting.

If that's a concern, the fix would be to say that say that these cookies (I.e., those with both HTTPOnly and Domain) can only be cleared via JS from an exactly matching origin; e.g., if I want to clear a cookie via JS that has "HTTPOnly; Domain=example.com", I need to clear the site data from example.com (or do it using the response header).

It'd be kind of unfortunate to have that special case in the spec, but it might be necessary.

Should this be Clear-Origin-Data?

Eh. Maybe? That seemed to rule out subdomain-spanning behaviors, though, so it's not clear to me that it's the right name for the long term.

WRT Cookies - hm. Giving JS on subdomain.example.com the power to clear a HTTPOnly cookie for *.example.com is... interesting.

I suppose. The risk seems low if we clear out every other cookie for *.example.com as well.

Again, cookies are nuts. Paths and domains and etc. make me crazy.

It'd be kind of unfortunate to have that special case in the spec, but it might be necessary.

Why? What risk would that special case mitigate?

It's a genuinely new capability; today, script on a subdomain didn't have the power to clear the "main" domain's cookies if they were HTTPOnly.

In common use today, that may not be a huge problem, given that domains like github.io are separate from github.com (and this seems to be a common pattern), and what's at risk is usually having to log into a site again.

That said, I'm still hesitant, because the Web is big, and it's absurd to think we know all the ways cookies are used. Also, I'd thought that the point of much of what we're doing is to make it eventually possible to have sites like mysite.github.com to be securely partitioned from www.github.com, and this seems like it'd be another reason people would avoid deployments like that.

WRT site vs. origin -- I'm not sure "site" conveys what you want it to; it just seems to add another, imprecise term.

It's a genuinely new capability; today, script on a subdomain didn't have the power to clear the "main" domain's cookies if they were HTTPOnly.

For clarity, this applies only to the JavaScript API, right? Not to the HTTP header.

Also, I'd thought that the point of much of what we're doing is to make it eventually possible to have sites like mysite.github.com to be securely partitioned from www.github.com

As long as we have cookies that span origins, that's going to be a difficult goal to achieve. How about those origin cookies, eh? (https://tools.ietf.org/html/draft-west-origin-cookies-01)

WRT site vs. origin -- I'm not sure "site" conveys what you want it to; it just seems to add another, imprecise term.

We use "site data" in Chrome's data-removing UI: chrome://settings/clearBrowserData. shrug I'm open to renamings.

taken up at Boston f2f

consensus - we are happy with the direction and will raise issues individually on their repo

Hey folks. Blast from the past! We're gearing up to ship an initial implementation of Clear-Site-Data in Blink. Since it's been a while, it would be helpful if y'all would take another pass through the document as @msramek and I clean it up.

@torgo: Should I file another issue, or would you prefer to reopen this one?

I'm definitely not qualified to look into this, but I'll give a first pass look at it. For now, I think we can live with necromancy on this, if the discussion gets too long we can start from a clean slate.

Discussing in Tokyo F2F.

Spec url redirects to https://w3c.github.io/webappsec-clear-site-data/ (in case the redirect goes away but the new URL stays good).

"This is reverse do-not-track." – @travisleithead

Feedback provided here: https://github.com/w3c/webappsec-clear-site-data/issues/22#issuecomment-297894485

Reposting @slightlyoff's feedback here with @mikewest's responses

Link to explainer and/or use-cases doc?

https://w3c.github.io/webappsec-clear-site-data/#intro is the best I've got, and it goes into a good amount of detail on both the overview and goals. It's not an explainer, but I'm hoping for some sort of grandfathered-in exception, since this has been kicking around in one form or another for years. :)

I'm happy to write something if there's still value, but it feels a bit like tacking on a design doc after building a project.

The names are a bit confusing at first glance: cache doesn't clear the SW Cache API. Maybe a different name for that one to indicate that this clears caches that aren't programmable?

Sure. That is the distinction we're making, and if you have a naming suggestion, I'm happy to accept it.

Why is storage different to cookies? Is storage a superset? Conceptually cookies are a storage mechanism, so should other storage mechanisms be called out and be able to be reset granularly?

Cookies don't respect the same-origin policy, so we have to clear them at the eTLD+1 level in order to leave a site in a sane state. I agree that the name storage could be improved. Help? :)

Is there a * value? Seems like that would be the default in an incident-response scenario. It that doesn't make sense, would love to see a note a to why

We had * and removed it. I don't recall why, but adding it back is pretty trivial.

Are there are interactions with the credential manager API?

No. We don't intend to give sites the ability to clear passwords, as those are in some way "user" data as opposed to "site" data. There's a good argument for including the requires user mediation bit in cookies, however. I'll make sure that's added.

To raise as issues:

• Add explainer
• Add a * value
• More detail on network cache
• Order of execution re setting cookies in a response that does Clear-Site-Data: cookies
• SW intermediary behaviour language

@triblondon to raise these as issues in their repo.

This is a bit a of a strange question - while the spec mentions that you the network cache clearing works on origin level, how would one deal with the case of a CORS request to lorem.com from ipsum.com which then gets cached within the lorem.com bucket, but would then like to clear all related cache from ipsum.com?

Would that be completely out of scope?

Discussing at Nice F2F.

Alex is going to comment on w3c/webappsec-clear-site-data#33. Andrew will follow up on other issues with @mikewest.

Hi @mikewest we note that not a lot has happened on the issues we raised and this is being implemented now. Wondering if we could get an update?

ping, @mikewest

Shipped in Chrome 61: https://www.chromestatus.com/features/4713262029471744

Alex is chasing this by email.

My understanding is that we'll get an update by Friday.

Can we ping @mikewest again?

Discussed at Paris f2f. We are still looking for a resolution on w3c/webappsec-clear-site-data#34

Discussed on today's call. @mikewest we are wondering what's going on with this topic. This issue has been open for a bit but it doesn't look like there has been work going on the spec for a while. Has this issue been overtaken by events? Is our feedback still needed? Thanks.

Ping @mikewest.

Blue, @torgo!

Hi! I haven't looked at any of this in months, to be honest. I'll try to find some time in the near future, but this is pretty far down my priority list. Perhaps @msramek has some time to follow up on https://github.com/w3c/webappsec-clear-site-data/issues/34 in particular?

We took the decision to summarily close this issue as it seems the spec in question is not being actively progressed. Please let us know if there is anything we can help with.