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

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

From: Jonathan Kingston <jonathan@jooped.com>
Date: Sat, 13 Jun 2015 00:54:29 +0000
Message-ID: <CAKrjaaW=-JjKTy7B9ea98xkE2HjyYJbP+S_rxUON9W-VkHV9JA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>, Mike West <mkwst@google.com>
Cc: Richard Barnes <rbarnes@mozilla.com>, 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>
Does all data stored in the file system and IndexedDB count as a cache
always? Would these be worthy exclusion directives?

I'm also a little worried of giving this power to clear http only cookies
and opaque data to a JavaScript API also.

Can the specification have an advisory to add a console message or similar
reporting to ease debugging. A post data clear event might be useful also
so JavaScript can know to clean up interfaces to show the user is logged
out.

When all contexts are neutered how will they handle stale user input?

Thanks

On Fri, Jun 12, 2015 at 6:51 PM Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 12 June 2015 at 09:41, Mike West <mkwst@google.com> wrote:
> > The spec does currently require HTTPS. I'm not sure we could reasonably
> > relax that, for exactly the reasons you point to. It sounds like exactly
> the
> > kind of API for which we'd want to require an authenticated and encrypted
> > connection.
>
> I actually think that having this on cleartext connections is a
> benefit.  Unless there is persistent data that somehow prevents other
> persistence from happening.  I'm not aware of any such feature.
>
> Elsewhere, Henri Sivonen suggested that we make cookies on cleartext
> origins less persistent by default.  This is seems consistent with
> that philosophy.
>
>
Received on Saturday, 13 June 2015 00:55:10 UTC

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