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

I appreciate the objective here, but the approach strikes me as a little
off.  I'm having a little bit of trouble putting my finger on exactly why,
but I suspect it has to do with:

* The level of abstraction.  In general, I have a pretty strong preference
in protocol design for granular mechanisms, vs. a single command that does
a whole bunch of things.  The latter risk rapid obsolescence as needs
change.  So I wonder if we might be better off if we were to fix the
individual storage modalities than providing one big switch -- rather than
building the switch, make it easy for developers to do it.

* The layering.  This is HTTP reaching up into a bunch of other layers of
the stack.  You can't set, say, IndexedDB from HTTP -- but you can clear it?

* The negative header.  In a related vein, most of the state-discard
mechanisms that we have around the Internet are treated as degenerate cases
of storage mechanisms, with lifetime 0.  See, e.g., HSTS.  I can't think of
a precedent for a pure-discard system, probably as a result of the above
layering issue.

* Adversarial possibilities. It seems like this could be a very easy way
for a MitM to be annoying.  E.g., if Verizon wants to blow away existing
tracking cookies to increase its own value.  Maybe this is just an argument
for it to be limited to HTTPS (though of course that's no panacea).

Hope this is helpful,

On Fri, Jun 12, 2015 at 10:46 AM, Anne van Kesteren <>

> On Fri, Jun 12, 2015 at 4:25 PM, Mike West <> wrote:
> > WDYT? Is something like this strawman appealing as work that either
> > WebAppSec or WebApps could take on?
> Should maybe be part of or at least
> use its terminology.
> --

Received on Friday, 12 June 2015 15:25:35 UTC