- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 16 Jan 2014 10:15:38 +0000
- 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 publicsuffix.org? > 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. -- http://annevankesteren.nl/
Received on Thursday, 16 January 2014 10:16:07 UTC