Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clear Site Data #62

Closed
mikewest opened this issue Jul 17, 2015 · 32 comments

Comments

@mikewest
Copy link

commented Jul 17, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Jul 22, 2015

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

@diracdeltas diracdeltas self-assigned this Jul 23, 2015

@mikewest

This comment has been minimized.

Copy link
Author

commented Aug 12, 2015

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

This comment has been minimized.

Copy link
Member

commented Aug 17, 2015

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

This comment has been minimized.

Copy link
Author

commented Aug 17, 2015

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

This comment has been minimized.

Copy link
Member

commented Aug 17, 2015

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

This comment has been minimized.

Copy link
Member

commented Aug 17, 2015

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

@mikewest

This comment has been minimized.

Copy link
Author

commented Aug 18, 2015

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

This comment has been minimized.

Copy link
Member

commented Sep 15, 2015

taken up at Boston f2f

@torgo

This comment has been minimized.

Copy link
Member

commented Sep 15, 2015

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

@torgo torgo closed this Sep 15, 2015

@mikewest

This comment has been minimized.

Copy link
Author

commented Mar 23, 2017

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 cynthia reopened this Mar 23, 2017

@cynthia

This comment has been minimized.

Copy link
Member

commented Mar 23, 2017

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 torgo assigned cynthia and unassigned diracdeltas Apr 28, 2017

@torgo torgo added this to the tag-f2f-tokyo-2017-04-27 milestone Apr 28, 2017

@torgo

This comment has been minimized.

Copy link
Member

commented Apr 28, 2017

Discussing in Tokyo F2F.

@dbaron

This comment has been minimized.

Copy link
Member

commented Apr 28, 2017

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 comment has been minimized.

Copy link
Member

commented Apr 28, 2017

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

@slightlyoff

This comment has been minimized.

Copy link
Member

commented Apr 28, 2017

@triblondon triblondon modified the milestones: tag-f2f-london-2017-07-25, tag-f2f-tokyo-2017-04-27 Apr 28, 2017

@torgo

This comment has been minimized.

Copy link
Member

commented Feb 5, 2019

Ping @mikewest.

@mikewest

This comment has been minimized.

Copy link
Author

commented Feb 5, 2019

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

This comment has been minimized.

Copy link
Member

commented May 22, 2019

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.

@torgo torgo closed this May 22, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.