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

On Mon, Jun 15, 2015 at 10:32 AM Mike West <mkwst@google.com> wrote:

> Thanks for the continued feedback!
>

Just hope it is useful!


>
> On Sun, Jun 14, 2015 at 11:06 AM, Jonathan Kingston <jonathan@jooped.com>
> wrote:
>
>> 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'll add a note along these lines. It's certainly a reasonable request.
>

Thank you!


> A "plugin" as in Flash? Or a "plugin" as in a browser extension? Or a
> third-party JavaScript component? IFrame?
>

Third party component / installed JavaScript. Where both scripts don't
really interface with each other.

Keeping the data is purely a side-effect of the the simplest mechanism I
> could some up with to safely lock down the various execution contexts I
> think we agree we need to deal with. It's
>
> If replacing the page with a "Hey, we just wiped everything off this
> origin." interstitial is the right thing to do, we can do that as the first
> step. If we tend towards reloading the pages with a request all the way
> back to the server, we'll need to have a two-step mechanism which
> sandwiches the clearing event.
>
> I don't have a strong opinion about which direction to go, so I'd tend
> towards the sandwich, as that seems like less work.
>

The clearing event is less important I feel if the user gets sent back to
the server. The event would be a little odd firing after the reload anyway.
I feel the full reload will behave mostly how a user would expect it
without additional code anyway.


>
>
>> 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 sanitizing 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).
>>
>
> The risk you're suggesting here is that an untrusted third-party resource
> could be proxied through `example.com` with headers intact, thereby
> clearing `example.com`'s data?
>

Yes, low risk but 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.
>>
>
> I don't think this is limited to single-page apps. The user experience
> here is certainly something to worry about.
>

Yeah it isn't but there are worse issues with:
 - Usually cache more
 - Are not used to reloads

As you say the user agent interstitial regarding the clear may be an
approach.


>
>
>> - Passive network attackers have a nice attack vector to clear all user
>> data. On wifi/stolen base unit where DNS could be poisoned perhaps.
>>
>
> Pedantic nit: attackers wouldn't be "passive" if they were injecting
> headers. :)
>

Yup sorry, terminology was never my strong point and this mail was so
cryptic.


> Martin (and Henri?) might claim that this is an advantage, as it makes
> HTTP less viable for persistence. I don't think we're at a point in our
> collective migration where we those claims would outweigh the annoyance to
> users, but it's a discussion worth having.
>
> The strawman limits the feature to HTTPS to mitigate exactly this risk.
>

The attacked base unit / wifi doesn't help much here for a non EV
certificate. As you say though there are probably much easier targets with
this.


>
>
>> This could perhaps be mitigated by only allowing first-party scripts the
>> access to this clearing API.
>>
>
> "First-party" in what sense? Do you mean you'd suggest parsing/reacting to
> the header only in a top-level browsing context? Or that you'd only allow
> requests from the same origin (eTLD+1? something else?) to take effect?
>
> That latter bit sounds like a reasonable restriction, IMO. I think the
> former would be too restrictive, as it would prevent scenarios like
> https://mikewest.github.io/webappsec/specs/clear-site-data/#example-targeted
> .
>

Scripts with the same origin as the top level browsing context should be
the only ones with access right?

I'm also unsure about how the browser would handle data stored in third
party scripts reading the spec.

For example what about these situations:
- example.com loads a payment gateway example.bank. example.com triggers a
clear, example.bank does not get cleared?
- example.bank scripts loaded within example.com should not be able to
trigger a clear on example.com either right?
- example.bank triggers a clear on their own site, that clears all cookies
and storage of example.bank on pages with their storage.
- example.bank triggers a clear on their own site, iframes on example.com
get cleared and reloaded right? (This would likely be a problem for payment
gateways)


>
>
>> - Retain cookies or contexts suffer from the same risks as retaining
>> indexedDB and files.
>>
>
> I don't understand. Would you mind elaborating a bit?
>

The retainCookies and retainContexts have the same risks as you mentioned
regarding abuse by scripts which could stash the data into other browser
contexts or cookies.


>
> Thanks!
>
> -mike
>