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, --Richard On Fri, Jun 12, 2015 at 10:46 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Fri, Jun 12, 2015 at 4:25 PM, Mike West <mkwst@google.com> wrote: > > WDYT? Is something like this strawman appealing as work that either > > WebAppSec or WebApps could take on? > > Should maybe be part of https://storage.spec.whatwg.org/ or at least > use its terminology. > > > -- > https://annevankesteren.nl/ > >
Received on Friday, 12 June 2015 15:25:35 UTC