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

Hi Richard, thanks for the feedback!

On Fri, Jun 12, 2015 at 5:25 PM, Richard Barnes <rbarnes@mozilla.com> wrote:

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

For clarity, you're suggesting replacing `retainCookies` with something
like `cookies`, and adding more granular lists of storage mechanisms? So
we'd end up with something like `Clear-Site-Data: cookies idb localstorage
sessionstorage etc`?

My worry there is that it requires developers to keep things up to date as
we add new storage mechanisms. Presumably we could mitigate this by
allowing folks to opt-into "everything" via `*`, and folks who need to
retain specific mechanisms (like cookies) would almost certainly be the
same folks who could be expected to stay up to date.

I think I prefer exclusions as whitelist to inclusions as blacklist, but I
could certainly be persuaded in the other direction.


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

This is mostly a consequence of the trust relationship around the use-case.
Simply put, it's difficult to talk about this in any real sense as a "Get
out of jail after a persistent XSS." card if it relies on JavaScript in the
compromised execution context in order to be effective.

More generally, I wouldn't say that this is unprecedented: Content Security
Policy is one example that seems to fit the bill, as it sets
representation-level policies that take effect inside the execution context
of the document.

To Jake's point, however, an imperative JavaScript API seems like a
reasonable addition. However, I don't think it could _replace_ the HTTP
header (or another mechanism with similar properties... all I can think of
is a well-known kill-switch endpoint, which doesn't seem much better than a
header).


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

I hope the use-cases make it clear that such a system (or at least, the
_outcome_ such a system would provide) is desirable. I'm happy to work
through alternate mechanisms for making it available if you have ideas
about how we could frame it as part of a positive system.


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

The spec does currently require HTTPS. I'm not sure we could reasonably
relax that, for exactly the reasons you point to. It sounds like exactly
the kind of API for which we'd want to require an authenticated and
encrypted connection.

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.
>>
>
I did mention Storage in the document, but it wasn't clear to me how far
along it was, or how much buy-in there was from vendors. If folks agree
that those are the terms we should run with, I'm totally happy to use them.
:)

-mike