W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2014

Re: Origin-scoped cache/cookie/storage context

From: Nasko Oskov <nasko@chromium.org>
Date: Thu, 16 Jan 2014 10:13:22 -0800
Message-ID: <CAA=myAucpYGk=jfK-iT4pWPSUuwQsL6p-GC9BeQ3zZwBboYLvA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Mike West <mkwst@google.com>, WebAppSec WG <public-webappsec@w3.org>, TAG <www-tag@w3.org>, Charlie Reis <creis@chromium.org>
On Thu, Jan 16, 2014 at 2:15 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Jan 15, 2014 at 6:52 PM, Nasko Oskov <nasko@chromium.org> wrote:
> > It will have to be a new API or modification to window.open, otherwise we
> > risk breakage. There is a hack we have in Chromium to work around this,
> but
> > having a proper API will be best. We have proposed this in the past, but
> > didn't go far:
> > http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts.
>
> Maybe as part of a bigger push towards site isolation it could work out.
>
> >> It seems that if a site opts into this better security model, we could
> >> go and disable document.domain...
> >
> > While it does sound good in theory, I wonder how well it will fare in
> > practice. If a site wants the protection, but cannot refactor in
> reasonable
> > timeframe to avoid document.domain, then they will be missing on a very
> > useful protection.
>
> Do we have usage statistics on document.domain? Everyone that is using
> it is doing themselves a disservice. How did you manage to convince
> Adam Barth to introduce a new feature that depends on
> publicsuffix.org?


As far as I know, this has been the security model for Chromium from the
very get go.


> > Another issue is how the UI messages this to the user, without very
> quickly
> > bringing confusion with "multiple partitions". This is one of the
> reasons we
> > decided not to implement partitions for the open web.
>
> It seems that as long as top-level navigation works as expected,
> there's no UI needed. I doubt many users grasp the concept of <iframe>
> and such.
>

The UI is for managing cookies and stored data. Today there is one storage
location. Once you introduce partitions, the UI becomes way more tricky and
messaging to users what it all means. They have hard time with just one
partition as it is.

Since this thread is starting to stray away from where it started, it might
be good to formulate exactly what the problem such isolation is trying to
solve.
We have documented our site isolation efforts at
http://www.chromium.org/developers/design-documents/site-isolation and have
an explicit threat model of what we are trying to protect and what we are
not.
Received on Thursday, 16 January 2014 18:13:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:04 UTC