Clear Site Data

[mikewest]

WebAppSec will likely be publishing Clear Site Data as a FPWD in the somewhat near future: https://w3c.github.io/webappsec/specs/clear-site-data/. It would be lovely if you folks could take a look from a layering and architectural point of view.

/cc @mnot @slightlyoff @diracdeltas

[diracdeltas]

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).

[mikewest]

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

[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.

[mikewest]

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?

[mnot]

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.

[mnot]

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

[mikewest]

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.

[torgo]

taken up at Boston f2f

[torgo]

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

[mikewest]

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?

[cynthia]

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.

[torgo]

Discussing in Tokyo F2F.

[dbaron]

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

[torgo]

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

[slightlyoff]

Feedback provided here: w3c/webappsec-clear-site-data#22 (comment)

[torgo]

Ping @mikewest.

[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 w3c/webappsec-clear-site-data#34 in particular?

[torgo]

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.