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

Hi Mike,

On Sun, Jun 14, 2015 at 6:33 AM Mike West <mkwst@google.com> wrote:

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

It could be made generic, I'm not sure if advising the user agent to use
console is the right idea however something like: "User agents SHOULD offer
developer debug once the site data is cleared."
This could be in the form of a stop icon on the network debug panel or a
fatal exception style message in console.
I think developers should be able to pick up and old tag and work out why
it reloaded to check it isn't a bug etc.


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

The use-case is a plugin handles a logout request to the server and a
separate single page app framework isn't able to view the response from the
server to the plugin. The framework might have a hard time showing to the
user that they are now logged out.
However the more I think about it, I think the page should freeze all
execution in all tabs and then do a hard reload. This fixes the use case
without exposing events that could be abused.


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

I struggle to see the point of keeping the data at all if it essentially
becomes unusable to the app. Unless perhaps on tabs other than the current
you could potentially show "This tab has been deactivated please back up
any user input" style message.

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

My worries are:
- Increasing the risks of proxying on the server side to other external
services. If a service was sanitising the body of the message rather than
the headers then this could be another issue (Obviously this is a bad
practice anyway but it does happen).
- Single page app user experience. I'm browsing the app and all of a sudden
one of my tabs receives a response to clear. The interface freezes then
refreshes. As user experiences go that could be confusing / lose data.
- Passive network attackers have a nice attack vector to clear all user
data. On wifi/stolen base unit where DNS could be poisoned perhaps.
- Misconfigured servers send out the header. Due to the need to clear
service workers, I can see that a server may be over zealous in sending out
the header. If a service needs to manage state of when old state needs
removing I can already see this happening.
- Increased attack vector for CSRF scripts to abuse - loss of user data and
simple way to create a bad user experience. This could perhaps be mitigated
by only allowing first-party scripts the access to this clearing API.
- Retain cookies or contexts suffer from the same risks as retaining
indexedDB and files.

However I think these concerns could be addressed in the security concerns
section also.

Thanks