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: Tue, 14 Jan 2014 10:46:26 -0800
Message-ID: <CAA=myAtEau7na8uCzpzXVxOag3gO_fbyEmJDB=DdovzOf==FVA@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 Sat, Jan 11, 2014 at 8:43 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Fri, Jan 10, 2014 at 6:09 PM, Nasko Oskov <nasko@chromium.org> wrote:
> > We have actually attempted implementing such isolation based on ideas in
> a
> > paper [ http://www.charlesreis.com/research/publications/ccs-2011.pdf ]
> > by Charlie Reis, Adam Barth, et al.
> Nice!
> > The example scenario that is confusing for the user is a
> > news site with social networking buttons, which when clicked lead to
> > authentication prompts, even though the user is already logged into the
> > social network.
> Yeah, this feature does not seem ideal for that kind of site. I guess
> the way iOS deals with this scenario is providing elevated access to
> Facebook and Twitter, which works fine, but does not really scale well
> and would not be a suitable solution on the web.
> > Our decision was to try and achieve the same end result though different
> > means, due to how we implement and enforce partitioning. We are currently
> > working on the first piece needed to get us there.
> Could you elaborate on this?

Sure. The Chromium security model supports different storage partitions
with the restriction of having only one per renderer process. As such, if
we were to restrict different origins to different partitions, this won't
work with iframes. The first step in solving this is supporting
out-of-process iframes, which is what we are currently working on. When
complete, we can isolate origins even on the same page.

> > If you are interested in glory details of why it didn't work as users
> expect
> > it, let me know and I'll be happy to explain.
> Assuming that once the user clicked the social network button that
> would lead to some inline popup and not a top-level navigation, I
> think I understand.

In a pop-up window, the navigation is actually top level. The reason for it
not working though is that windows with synchronous scripting relationships
must stay in the same renderer process, hence they cannot use different
storage partitions. This causes the user to have to login in a pop-up for
each isolated origin, which defeats the purpose of origin isolation.
While a this, I should mention that we do not isolate on the basis of
origins, rather on the concept of "site". It includes the scheme and the
registered domain name, so relaxing origin through document.domain is not
broken. It excludes subdomains and port numbers.
Received on Tuesday, 14 January 2014 18:46:54 UTC

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