W3C home > Mailing lists > Public > public-html-media@w3.org > June 2015

Fwd: Proposal: a "clear site data" API.

From: Joe Steele <steele@adobe.com>
Date: Fri, 12 Jun 2015 15:28:41 +0000
To: "public-html-media@w3.org" <public-html-media@w3.org>
Message-ID: <6270320D-2A52-4774-8D2F-C9625853D571@adobe.com>
Probably a good effort for us to be tracking.

> Begin forwarded message:
> 
> From: Mike West <mkwst@google.com>
> Subject: Proposal: a "clear site data" API.
> Date: June 12, 2015 at 7:25:51 AM PDT
> To: "public-webappsec@w3.org" <public-webappsec@w3.org>
> Cc: Brad Hill <hillbrad@gmail.com>, Tanvi Vyas <tanvi@mozilla.com>, Jake Archibald <jakearchibald@google.com>, Alex Russell <slightlyoff@google.com>, Jonas Sicking <jonas@sicking.cc>
> Resent-From: <public-webappsec@w3.org>
> 
> TL;DR: Strawman spec at https://mikewest.github.io/webappsec/specs/clear-site-data/ <https://mikewest.github.io/webappsec/specs/clear-site-data/>. Feedback welcome!
> 
> Hello, lovely denizens of public-webappsec and public-webapps!
> 
> # Use Cases
> 
> In some conversations with some application developers, the idea of allowing an origin some declarative mechanism of clearing out all locally stored data has come up a few times in various contexts. Folks see such a mechanism as a step towards recovering from annoyingly persistent XSS attacks, or as a mechanism for ensuring that user data doesn't persist on disk after logout.
> 
> # Workarounds
> 
> Site authors can remove data from a number of storage mechanisms via JavaScript, but others are difficult to deal with reliably. Consider cookies, for instance, which can be partially cleared via JavaScript access to `document.cookie`. `HttpOnly` cookies, however, can only be removed via a number of `Set-Cookie` headers in an HTTP response. This, of course, requires exhaustive knowledge of all the cookies set for a host, which can be complicated to ascertain. Cache is still harder; no imperative interface to a browser’s network cache exists, period.
> 
> # Proposal
> 
> I've taken a stab at sketching out what such an API might look like, and I'd appreciate any feedback you might have: https://mikewest.github.io/webappsec/specs/clear-site-data/ <https://mikewest.github.io/webappsec/specs/clear-site-data/>.
> 
> It's intentionally quite simple: an (authenticated and encrypted) HTTP response that contains a `Clear-Site-Data: *` header will trigger clearing. Cookies may be excluded via `Clear-Site-Data: retainCookies`. Subdomains may be included via `Clear-Site-Data: *; includeSubdomains`. More examples are available at https://mikewest.github.io/webappsec/specs/clear-site-data/#examples <https://mikewest.github.io/webappsec/specs/clear-site-data/#examples>.
> 
> My hope is that this functionality maps pretty cleanly onto the kinds of data-clearing functionality that user agents already offer to users, and so won't be a terrible stretch for implementers.
> 
> WDYT? Is something like this strawman appealing as work that either WebAppSec or WebApps could take on?
> 
> CCing a few folks who I've poked at about these topics in the recent past.
> 
> --
> Mike West <mkwst@google.com <mailto:mkwst@google.com>>, @mikewest
> 
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)


Received on Friday, 12 June 2015 15:29:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:49:02 UTC