- From: Simon Pieters <simonp@opera.com>
- Date: Thu, 14 Jun 2012 09:59:21 +0200
- To: "Charlie Reis" <creis@chromium.org>, "Michal Zalewski" <lcamtuf@coredump.cx>
- Cc: whatwg@whatwg.org, Glenn Maynard <glenn@zewt.org>, Bjartur Thorlacius <svartman95@gmail.com>, Adam Barth <w3c@adambarth.com>
On Thu, 14 Jun 2012 01:44:12 +0200, Michal Zalewski <lcamtuf@coredump.cx> wrote: >> Any feedback on this revised approach? > > My vague concern is that the separation is a bit fuzzy, beyond saying > that window.opener will be null... if that's the only guaranteed > outcome, then maybe that should be spelled out more clearly? rel=noreferrer already has this feature, FWIW. http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer "This keyword also causes the opener attribute to remain null if the hyperlink creates a new browsing context." > The > degree of separation between browsing contexts is intuitive in the > case of Chrome, given the underlying implementations, but will it be > the same for Internet Explorer or Firefox or Safari? > > Let's assume that there is no Chrome-style process isolation, and that > this is only implemented as not giving the target=_unrelated document > the ability to traverse window.opener. If the document's opener lives > in an already-named window (perhaps unwittingly), it won't be > prevented from acquiring the handle via open('', > '<name_of_that_window>'), right? That may be unexpected. > > The same goes the other way - the spec subtly implies that because > window.open('foo', '_unrelated') returns null, the opener will not be > able to mess with the opened window, but that's not guaranteed given > that the reference may be leaked by other means, right? > > /mz -- Simon Pieters Opera Software
Received on Thursday, 14 June 2012 07:58:51 UTC