Hi Alex, Jonathan!
On Sat, Jun 13, 2015 at 8:23 AM, Alex Russell <slightlyoff@google.com>
wrote:
> i also don't understand how this will help us in the situation of an XSS
> where there's a SW and live tabs. I.e., where there's a compromised
> document that stuffs crap values into storage to defeat a server or SW's
> attempts to clean things up. Without a variant that pauses and forces
> refresh of all documents at the origin, it doesn't solve my big problem.
>
The strawman deals with this by sandboxing any active documents whose
origins match the header's scope (see
https://mikewest.github.io/webappsec/specs/clear-site-data/#neuter-contexts).
It's not at all clear to me that this is the _right_ way to deal with the
problem as it has a number of strange side-effects, so I look forward to
suggestions. :)
On 12 Jun 2015 5:54 pm, "Jonathan Kingston" <jonathan@jooped.com> wrote:
>
>> Does all data stored in the file system and IndexedDB count as a cache
>> always? Would these be worthy exclusion directives?
>>
>
The strawman lumps those in with "DOM-accessible storage". Since they
seemed to me to be the crux of the issue, it didn't make much sense to me
to add exclusions (e.g. no one would use them). If we decide that Richard's
suggestion to move to a blacklisting model (or a more extensive exclusion
model) is the right way to go, then I agree that we'd want to add granular
selection capability.
I'm also a little worried of giving this power to clear http only cookies
>> and opaque data to a JavaScript API also.
>>
>
If we were giving the ability to _set_ this kind of data, I'd be worried. I
might even be worried if we gave the ability to clear _specific_ pieces of
data. Clearing _everything_, on the other hand, is purely destructive, and
seems pretty safe.
> Can the specification have an advisory to add a console message or similar
>> reporting to ease debugging.
>>
>
When would you expect to see a console message? What would you expect it to
say?
> A post data clear event might be useful also so JavaScript can know to
>> clean up interfaces to show the user is logged out.
>>
>
Given that this is (in the strawman) attached to an HTTP response, I'd
expect the logout landing page to be something the site could build without
such an event. What's the use-case you see?
When all contexts are neutered how will they handle stale user input?
>>
>
They won't handle it well. The idea is to give the origin a kill-switch for
open contexts in order to prevent them from re-poisoning the well after we
clean it up. Sandboxing them removes their access to things like local
storage and IDB, but also prevents them from persisting any state they
might _want_ to persist (because "good" data and "bad" data are
indistinguishable from the UA).
--
Mike West <mkwst@google.com>, @mikewest
Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)