- 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