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

Trimming. If I've missed something interesting, please do resurface it.

On Tue, Jun 16, 2015 at 3:16 AM, Jonathan Kingston <>

> On Sun, Jun 14, 2015 at 11:06 AM, Jonathan Kingston <>
>> 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!

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:
> - loads a payment gateway triggers
> a clear, does not get cleared?

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

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

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

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.

> - triggers a clear on their own site, iframes on
> 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.


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