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

Hi, Jonathan!

On Sat, Jun 13, 2015 at 11:47 PM, Jonathan Kingston <jonathan@jooped.com>
wrote:
>
> 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.
>

Ok. We don't generally post messages to the console when things work
correctly, but perhaps this is an interesting enough even to add a message?


> 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.
>

I still don't understand the use-case for a DOM event (though I think we'd
end up triggering a few as a side-effect of clearing things), but it might
make sense to confirm to the server that data was removed by sending a
`Clear-Site-Data: cleared` header along with the reload request. Not sure
if that's worth another round-trip, but it's certainly possible to do.


> 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.
>

Yes, but it would stay in a heavily sandboxed execution context. No script,
no storage, a unique origin, etc. I don't think there would be any way to
read data out of such a context (no script === no response to postMessage,
unique origin === no direct DOM access), nor would explicit exfiltration be
possible (no script === no triggered resource loads, etc).

I might well be missing something, however, which is why I think Alex's
suggestion to hard-reload (which I read as "go all the way to the server")
is appealing. It also makes the story simpler for users to understand ("I
logged out over there, so I'm logged out over here too."), which is a nice
benefit.

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 use case that I think Alex is most concerned with is one in which the
server no longer trusts the data cached on the client (as in
https://mikewest.github.io/webappsec/specs/clear-site-data/#example-killswitch).
If your site is XSS'd, and the attacker is sufficiently clever, then they
can put together persistence mechanisms that can make it difficult for you
to get back to a known-good state. `Clear-Site-Data` basically represents
the server asking for a clean slate.

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.
>

I don't understand why this would be desirable. The use-cases explicitly
distrust the client, positioning the server as the source of truth.
Moreover, origins are already granted control over their data without user
mediation (e.g. there's no permission dialog for `localStorage.clear()`),
and can already clear most of what's being discussed (though it's a good
deal of work to do correctly). What about the functionality we're
discussing here do you think crosses over into something that the user
ought to be involved in?

-mike

--
Mike West <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.)