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

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

From: Mike West <mkwst@google.com>
Date: Tue, 16 Jun 2015 08:31:38 +0200
Message-ID: <CAKXHy=ft8g30VLD6zVc+aLg48nEMds-cGGyJKQeD72DO6Augdg@mail.gmail.com>
To: Richard Barnes <rbarnes@mozilla.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, "public-webappsec@w3.org" <public-webappsec@w3.org>, 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>
On Fri, Jun 12, 2015 at 5:25 PM, Richard Barnes <rbarnes@mozilla.com> wrote:

> * The layering.  This is HTTP reaching up into a bunch of other layers of
> the stack.  You can't set, say, IndexedDB from HTTP -- but you can clear it?

I had a quick conversation with Richard yesterday, and he offered two
suggestions here:

1. Framing the feature as "resetting" an origin's state made more sense to
him than "clearing".

2. Tying the feature to CSP made more sense to him than a separate header.

I think the suggestion he ended up with was `Content-Security-Policy:
reset-site-state *`.

I can get behind #1, as "clearing" might have connotations I didn't intend.
Though I agreed with him while we were chatting, I'm less convinced on #2
the more I think about it. This seems to be to be less of a policy that's
applied to a particular resource representation, and more of a one-off,
origin-wide action triggered in response to a server-side request. I think
it makes sense to split out from other headers into its own thing.

Received on Tuesday, 16 June 2015 06:32:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:13 UTC