Intent to Implement: Clear-Site-Data header

[Martin Sramek]

Contact emails

msr...@chromium.org, mk...@chromium.org

Spec

https://w3c.github.io/webappsec-clear-site-data/

Summary

We implement a ‘Clear-Site-Data’ HTTP header which prompts the user agent to clear browsing data associated with the requesting website. The supported browsing data types are cookies, storage (i.e. “site data”), and cache. Data will be deleted for the requesting origin, except for cookies and channel IDs (part of storage) which are more broadly scoped, and will be deleted for the entire eTLD+1.

Motivation

This is a privacy and security enhancing feature. A sensitive website can trigger local data deletion after the user signs out. A website dealing with a persistent XSS attack can use this to ‘reset’ itself to a clean state. See examples.

Interoperability and Compatibility Risk

There is a demand for such feature from developers.

Discussions on w3c mailinglists give feedback on details, but no pushback on the feature itself.

It is conceivable that vendor implementations differ (e.g. interpret some data as part of ‘cache’ instead of ‘storage’), what can be addressed by refining the storage specification. However, given this feature’s use case as a last line of defense, this does not pose a risk.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

crbug.com/607897

Link to entry on the feature dashboard

https://www.chromestatus.com/features/4713262029471744

Requesting approval to ship?

No.

[Chris Harrelson]

This sounds a bit dangerous. Are you planning to implement it only for secure connections?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Charlie Reis]

+1 to concern about abuse, and possibly limiting this to secure connections.  A MITM on an HTTP page can do many of these things already (e.g., modify cookies), but forcing a reload of all frames (as mentioned in the spec) is a more disruptive and destructive operation.

Forcing a reload of all frames is also tricky to implement correctly.  Have you thought about pages with beforeunload handlers, which might try to survive this action?  Will you bypass such unload handlers, possibly losing data?  Also, be sure to consider the effective origin of about:blank pages, which might be inherited from another frame.

Charlie

[Harald Alvestrand]

Will the reset also be able to apply to stored permissions (geolocation, cameras, microphones)? We have a statement in the Mediacapture spec that permissions for devices should be cleared at the same time as cookies, without specifying UI in detail; it's unclear from the spec if this was considered for this option.

I'm nervous about whether spoofing will be easy or hard; if it's not hard, it is a disruptor function. But I guess the W3C discussions have covered that in some detail.

[Martin Šrámek]

Thanks for the feedback!

On Fri, Apr 29, 2016 at 6:33 PM, Harald Alvestrand <h...@google.com> wrote:

Will the reset also be able to apply to stored permissions (geolocation, cameras, microphones)? We have a statement in the Mediacapture spec that permissions for devices should be cleared at the same time as cookies, without specifying UI in detail; it's unclear from the spec if this was considered for this option.

No, we didn't consider deleting content settings. We can include this if it is desirable, but it is already true that the user clearing cookies (through chrome://settings/cookies, chrome://settings/clearBrowserData or the site info dialog) does not revoke permissions, nor does deleting cookies by JavaScript, so this is new to me. But given that our goal is to "reset the site to a clean state", it does sound like a reasonable step.

I'm nervous about whether spoofing will be easy or hard; if it's not hard, it is a disruptor function. But I guess the W3C discussions have covered that in some detail.

On Fri, Apr 29, 2016 at 6:04 PM, Charlie Reis <cr...@chromium.org> wrote:

+1 to concern about abuse, and possibly limiting this to secure connections.  A MITM on an HTTP page can do many of these things already (e.g., modify cookies), but forcing a reload of all frames (as mentioned in the spec) is a more disruptive and destructive operation.

The current version of the spec talks about secure connections, precisely for the reason that this is a powerful destructive feature.

However, we got previous feedback that this might not be necessary; as Chris notes himself, cookies can already be meddled with by a MITM, and in fact, there is a movement to make cookies less persistent on HTTP. In that sense, making it harder to delete cookies on HTTP would be a step in the opposite direction. It is also already possible for a MITM to inject JavaScript to access other storage backends, and delete data from them selectively, which is strictly more powerful than complete wipe. One difference is that some backends, e.g. cache, currently cannot be directly accessed and cleared by JavaScript.

I can also imagine a MITM injecting JavaScript into all instances of the site as the user loads them on multiple tabs, and that JavaScript will use the clock to time reloads, to approximate this simultaneous reload.

Personally, it seems to me that supporting this on insecure connections makes it possible for a MITM to annoy the user with one line of code, but does not really increase attack surface. But I might easily be overlooking something, or we might decide that this annoyance protection is still worth it.

Forcing a reload of all frames is also tricky to implement correctly.  Have you thought about pages with beforeunload handlers, which might try to survive this action?  Will you bypass such unload handlers, possibly losing data?  Also, be sure to consider the effective origin of about:blank pages, which might be inherited from another frame. 

The plan is to stop all execution contexts, i.e. just freeze the page. That means that not even beforeunload handlers would fire. In the use case when we're protecting against an XSS attack, we do not want to give it a chance to carry over any data.

Perhaps we could find a way to delay the action and give the user a chance to copy their filled form data out of the page so that they don't lose them, but we haven't thought this out for the first version. In our use cases, it is not necessary. But admittedly, if we end up allowing insecure connections, we have to expect that this could be called anytime.

 

Charlie

Martin

Google Germany GmbH

Dienerstrasse 12

80331 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

[Anne van Kesteren]

On Fri, Apr 29, 2016 at 6:33 PM, 'Harald Alvestrand' via blink-dev
<blin...@chromium.org> wrote:
> Will the reset also be able to apply to stored permissions (geolocation,
> cameras, microphones)? We have a statement in the Mediacapture spec that
> permissions for devices should be cleared at the same time as cookies,
> without specifying UI in detail; it's unclear from the spec if this was
> considered for this option.

Do you recall the rationale for that grouping? I'm slowly trying to
formalize the various ways of storage
https://storage.spec.whatwg.org/#infrastructure and it would be nice
if we had a consistent approach for this across APIs. One API out of
many stating that its permissions should be UI-grouped with cookies
and other kinds of storage is probably not sufficient. Needs a more
principled approach.


--
https://annevankesteren.nl/

[Harald Alvestrand]

I misremembered, unfortunately - the spec says that persistent device IDs should be cleared when cookies are, but is silent  on device permission lifetimes.

I remember having that discussion on the WebRTC team, but it seems that per M50, we did not clear permissions when you delete a site's other items.

[Anne van Kesteren]

On Mon, May 2, 2016 at 12:32 PM, Harald Alvestrand <h...@google.com> wrote:
> I misremembered, unfortunately - the spec says that persistent device IDs
> should be cleared when cookies are, but is silent on device permission
> lifetimes.

That makes a little more sense to me, like credentials, it does not
seem like we should clear permissions, though we should enable users
to do so easily.

That persistent device IDs (hopefully minted per-origin) should be
cleared also makes sense. Hopefully at some point they'll be described
as being persisted in a "box" at which point all clearing behavior
would fall out automatically.


--
https://annevankesteren.nl/

[Harald Alvestrand]

Once you have a box we can point to, I'm sure we can provide the pointer :-)

[Anne van Kesteren]

On Mon, May 2, 2016 at 1:11 PM, Harald Alvestrand <h...@google.com> wrote:
> Once you have a box we can point to, I'm sure we can provide the pointer :-)

Heh, https://storage.spec.whatwg.org/#box exists. It's not entirely
clear to me whether that is sufficient yet for everyone. E.g.,
IndexedDB will need some hook to cancel ongoing transactions when a
box is cleared.
https://w3c.github.io/webappsec-clear-site-data/#clear-dom seems to
address those concerns to some extent for this header, though it
assumes all those storages areas are cleared synchronously across
browsing contexts, which seems a little naive. (And it invokes methods
which could have been overridden by scripts.)


--
https://annevankesteren.nl/

[Harald Alvestrand]

what's the political status of the storage spec? as you know we're trying to live with w3c for the time being.

I see it's just passed its 1-year birthday..... but I can't figure out where multiple boxes for an origin belongs (it doesn't seem to exist).

[Anne van Kesteren]

On Mon, May 2, 2016 at 3:26 PM, 'Harald Alvestrand' via blink-dev
<blin...@chromium.org> wrote:
> I see it's just passed its 1-year birthday..... but I can't figure out where
> multiple boxes for an origin belongs (it doesn't seem to exist).

Multiple boxes per origin for site storage, if that's what you mean,
is still under discussion. It's a potential v2 feature, but the first
priority is to agree on the fundamentals (what's included in site
storage and what should exist elsewhere (permissions)) and ship a
minimal API for persistent storage and quota information. I think
we're getting closer to that with at least Google and Mozilla
implementing.


--
https://annevankesteren.nl/

[Harald Alvestrand]

Anne, then I don't understand your comment upthread ("That persistent device IDs (hopefully minted per-origin) should be

cleared also makes sense. Hopefully at some point they'll be described
as being persisted in a "box" at which point all clearing behavior

would fall out automatically.") - I guess it's more useful to wait for a more complete proposal than to guess what you were thinking.

(BTW, getusermedia's persistent device-IDs are indeed minted per origin.)

[Anne van Kesteren]

On Mon, May 2, 2016 at 4:52 PM, Harald Alvestrand <h...@google.com> wrote:
> Anne, then I don't understand your comment upthread ("That persistent device
> IDs (hopefully minted per-origin) should be
> cleared also makes sense. Hopefully at some point they'll be described
> as being persisted in a "box" at which point all clearing behavior
> would fall out automatically.") - I guess it's more useful to wait for a
> more complete proposal than to guess what you were thinking.

What I mean is that if your API at some point says "store this in
/x/'s box" with the appropriate reference to
https://storage.spec.whatwg.org/#box it would be clear what happens
for these scenarios:

* When we create a new clear() API to clear all "site storage" for an origin
* What the effect of this header is
* What the effect of any UI for clearing that box would be (for which
it's already recommended that cookies are cleared along with it to
avoid persistence)

Without any of those having to know about your API.

There is however the question as to whether that is specific enough.
We might want to define what "store in /x/'s box" means in more detail
and for some APIs we'll need hooks to tell them the box is being
cleared so transactions can be canceled and such. (There's a couple
open issues on the Storage Standard that discuss this. It might be
best to follow up there if you have any particular requirements.)


--
https://annevankesteren.nl/

[Lucas Garron]

Note Chrome currently persists permission rejections so that a site cannot keep asking once a user has blocked the permission for the site.

Clearing permissions using this mechanism would allow a site to keep making permission requests even if the user has rejected it.

»Lucas

[Anne van Kesteren]

On Mon, May 2, 2016 at 10:46 PM, Lucas Garron <lga...@google.com> wrote:
> Note Chrome currently persists permission rejections so that a site cannot
> keep asking once a user has blocked the permission for the site.
>
> Clearing permissions using this mechanism would allow a site to keep making
> permission requests even if the user has rejected it.

This was not about permissions. I already argued that we should keep
permissions separate from site storage. This was about a per-device
identifier.


--
https://annevankesteren.nl/

[Martin Šrámek]

Yes, Lucas is probably just addressing my initial excitement, quote "it does sound like a reasonable step". But now that I think about it a bit more, it doesn't. So I'm happy that Harald just misremembered :)

In cases where the user allowed geolocation by default, just blocked it on evilsite.com, that site could use the header to clear the rejected permission, thus effectively granting it to itself. That's not something we want to do.

We could only clear granted permissions, not rejected ones, but given how hierarchically permissions can be set in Chromium (blocked by default, allowed on "https://*", blocked on "https://example.com:*", allowed on "https://example.com:443"...), it would be fairly complicated to do the right thing.

[Lucas Garron]

Indeed, all I wanted was to point out that clearing (blocked) permissions should not be seen as a reasonable step. :-)

We're working on making all permissions origin-scoped, which should make it easier consider clearing granted permission if that becomes desirable.

»Lucas

[Martin Šrámek]

Hello everyone!

After a long silence on this thread I'm happy to announce that we have the first version ready behind the "Experimental web platform features" flag for M54.

The Clear-Site-Data header allows the requesting secure origin to ask for deletion of any of its own data from the three buckets: cookies, storage and cache. In Chromium, these buckets translate to:

"cookies": Cookies, LSOs (i.e. "Flash cookies"), Channel IDs, safe-browsing cookies, password manager auto sign-in, domain reliability service contexts.

"storage": Storage partition = {app cache, file systems, Indexed DB, local storage, service workers, cache storage, WebSQL}, site usage data, Android installed webapps registry, offline pages.

"cache": Http and media cache, Quic crypto client config.

The deletion is synchronous, i.e. when the header is encountered, the navigation is delayed until the deletion finishes.

Almost all datatypes are deleted per origin, except the first three in the "cookies" bucket. Channel IDs are defined for eTLD+1, and cookies can be visible up to eTLD+1, so they are deleted in that scope. LSOs are defined for domain, but in order not to introduce a third scoping, and for consistency with regular cookies, we also delete them for eTLD+1.

In the next version, we will look into:

- improving the scoping - we have to see if this combination of origin and eTLD+1 scoping is reasonable, and we already have a feature request to selectively include subdomains

- stopping execution contexts - this is needed for the feature to work properly if the website is running in more than one tab etc.

Best regards,

Martin

[PhistucK]

On Mon, Aug 22, 2016 at 5:35 PM, Martin Šrámek <msr...@chromium.org> wrote:

password manager auto sign-in

What is this?​ Google-specific on Android?

☆PhistucK

[Martin Šrámek]

Sorry, when I said "password manager", I meant "credential manager". Specifically, it's this bit.

It's grouped with cookies because it has similar semantics to sign-in cookies - if it exists when you visit the site, you'll be signed in.