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

On Sat, Jun 13, 2015 at 9:18 AM Mike West <mkwst@google.com> wrote:

> 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?
>>>
>>
> The strawman lumps those in with "DOM-accessible storage". Since they
> seemed to me to be the crux of the issue, it didn't make much sense to me
> to add exclusions (e.g. no one would use them). If we decide that Richard's
> suggestion to move to a blacklisting model (or a more extensive exclusion
> model) is the right way to go, then I agree that we'd want to add granular
> selection capability.
>

That is fair, if such a heavy clear is required I would prefer a handshake
to confirm both sides are happy with all data to be deleted including user
input.


>
> I'm also a little worried of giving this power to clear http only cookies
>>> and opaque data to a JavaScript API also.
>>>
>>
> If we were giving the ability to _set_ this kind of data, I'd be worried.
> I might even be worried if we gave the ability to clear _specific_ pieces
> of data. Clearing _everything_, on the other hand, is purely destructive,
> and seems pretty safe.
>

Ok so long as this is only available to first-party scripts, but again I
think also a handshake would be safer too.


>
>
>> Can the specification have an advisory to add a console message or
>>> similar reporting to ease debugging.
>>>
>>
> When would you expect to see a console message? What would you expect it
> to say?
>

After the event has happened, essentially I want an easy way for developers
to see when their data got deleted for debug purposes.
Message is unimportant besides mentioning the source of the clear perhaps.


>
>
>> A post data clear event might be useful also so JavaScript can know to
>>> clean up interfaces to show the user is logged out.
>>>
>>
> Given that this is (in the strawman) attached to an HTTP response, I'd
> expect the logout landing page to be something the site could build without
> such an event. What's the use-case you see?
>

Plugin vs library etc both might not have access to the response from the
server. However this use case goes away if a hard refresh is going to
happen.


>
> When all contexts are neutered how will they handle stale user input?
>>>
>>
> They won't handle it well. The idea is to give the origin a kill-switch
> for open contexts in order to prevent them from re-poisoning the well after
> we clean it up. Sandboxing them removes their access to things like local
> storage and IDB, but also prevents them from persisting any state they
> might _want_ to persist (because "good" data and "bad" data are
> indistinguishable from the UA).
>

So the current suggestion is that the user input will stay? Obviously this
means that bad scripts could just cache data, it can grab into hidden
fields or whatever it can to avoid the clearing.
I think as mentioned in a later message a hard reload may be better after
all contexts are frozen to prevent this data from still being usable later.

If it is going to be such a heavy weight kill switch it would be nice that
both client and server did a handshake first to remove the data (However
perhaps I am not seeing all the use cases for why a server can essentially
break all user interfaces in such a heavy handed manner).
The logout use case could have the app send a DELETE request to the server
with perhaps a Ok-To-Clear-Site-Data HTTP header, the server could then
respond with the Clear-Site-Data header. The client would only clear when
both have happened.

Thanks