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

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

From: Alex Russell <slightlyoff@google.com>
Date: Fri, 12 Jun 2015 23:23:09 -0700
Message-ID: <CANr5HFW2frcPK_wHoWugBGbQy-bhD2OpHP=3UfuKg+6gbabBYA@mail.gmail.com>
To: Jonathan Kingston <jonathan@jooped.com>
Cc: Tanvi Vyas <tanvi@mozilla.com>, Brad Hill <hillbrad@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Richard Barnes <rbarnes@mozilla.com>, Jake Archibald <jakearchibald@google.com>, Anne van Kesteren <annevk@annevk.nl>, Mike West <mkwst@google.com>, Martin Thomson <martin.thomson@gmail.com>, Jonas Sicking <jonas@sicking.cc>
i also don't understand how this will help us in the situation of an XSS
where there's a SW and live tabs. I.e., where there's a compromised
document that stuffs crap values into storage to defeat a server or SW's
attempts to clean things up. Without a variant that pauses and forces
refresh of all documents at the origin, it doesn't solve my big problem.
On 12 Jun 2015 5:54 pm, "Jonathan Kingston" <jonathan@jooped.com> wrote:

> 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 06:23:38 UTC

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