Re: [w3ctag/design-reviews] Clear Site Data (#62)

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/62#issuecomment-318402748