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

Re: Origin-scoped cache/cookie/storage context

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 16 Jan 2014 10:15:38 +0000
Message-ID: <CADnb78g8tKm5vRNGDDkZteFCvDS3UNfZqNZpFgAp8mEBNEvTVQ@mail.gmail.com>
To: Nasko Oskov <nasko@chromium.org>
Cc: Mike West <mkwst@google.com>, WebAppSec WG <public-webappsec@w3.org>, TAG <www-tag@w3.org>, Charlie Reis <creis@chromium.org>
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

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

Received on Thursday, 16 January 2014 10:16:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:37 UTC