- From: Charlie Reis <creis@chromium.org>
- Date: Thu, 14 Jun 2012 10:44:58 -0700
- To: Simon Pieters <simonp@opera.com>
- Cc: whatwg@whatwg.org, Glenn Maynard <glenn@zewt.org>, Bjartur Thorlacius <svartman95@gmail.com>, Adam Barth <w3c@adambarth.com>, Michal Zalewski <lcamtuf@coredump.cx>
On Thu, Jun 14, 2012 at 12:59 AM, Simon Pieters <simonp@opera.com> wrote: > 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<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." > > Right. I mention that in my proposal under "Current Usage and Workarounds," since I'm hoping to get more or less the same behavior but without the Referer blocking. You're correct that rel=noreferrer has the same issues around named windows, so perhaps we should try to get both features to behave the same way (either allowing named but unrelated browsing contexts to be discoverable or not). Charlie
Received on Thursday, 14 June 2012 17:45:38 UTC