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

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

From: Mike West <mkwst@google.com>
Date: Tue, 16 Jun 2015 08:26:44 +0200
Message-ID: <CAKXHy=e4Dz61Tja+c6DD5bSJaCq3mCxT05g_EhMfvTUH+30Y1Q@mail.gmail.com>
To: Jonathan Kingston <jonathan@jooped.com>
Cc: Alex Russell <slightlyoff@google.com>, 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>, Martin Thomson <martin.thomson@gmail.com>, Jonas Sicking <jonas@sicking.cc>
Trimming. If I've missed something interesting, please do resurface it.

On Tue, Jun 16, 2015 at 3:16 AM, Jonathan Kingston <jonathan@jooped.com>
wrote:

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

https://github.com/mikewest/webappsec/commit/61a7d83f02413d73f277dcdc913288328c340bed

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

I don't understand. Why does the certificate need to be EV to mitigate the
risk of injection?

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

Storage is origin-based, so yes: two distinct origins would be cleared
separately. If a resource from `example.com` delivered the header, `
example.com` (and not `example.bank`) would be cleared out.


> - example.bank scripts loaded within example.com should not be able to
> trigger a clear on example.com either right?
>

If we add a JavaScript API to the strawman, then any script (including
third-party scripts) loaded into an `example.com` document would be able to
clear `example.com`.

Loading a third-party script into your origin executes it with all the
privileges of your origin. There's no distinction between "first-party" and
"third-party" script once it's running.


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

I don't see how this would happen. The strawman is fairly clearly scoped to
a host (and potentially its subdomains). Framing a site doesn't create any
relationship that would allow you access (positive or negative) to its data.

-mike
Received on Tuesday, 16 June 2015 06:33:29 UTC

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