- From: Michael A. Peters <mpeters@domblogger.net>
- Date: Thu, 1 Dec 2016 18:43:58 -0800
- To: whatwg@lists.whatwg.org
On 12/01/2016 06:14 PM, Elliott Sprehn wrote: > On Wed, Nov 30, 2016 at 10:53 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > >> On 12/1/16 1:41 AM, Chris Holland wrote: >> >>> I think the devil would be in implementation detail. Slapping a >>> "rel/noopener" attribute on a specific link is very deterministic and >>> straightforward from a logic standpoint ---- Whichever window was created >>> from this link can't control the parent. >>> >> >> It's a much stronger guarantee. The guarantee is that the parent and the >> created window have no way to see each other at all. Neither one can read >> any state from the other, or even know the other one exists. >> >> In particular, the idea is that rel="noopener" allows the new window to be >> opened in a separate process, or even a separate browser if desired. The >> only difference between it and the user copying the link and then pasting >> it into some other tab or other program is that a referrer header is sent. >> >> Note that this guarantee makes for fairly simple implementation. >> >> Having a header that opts in all links targeted at anything other than >> _parent, _self, and _top have the noopener behavior would be doable. Having >> a header that opts in some links based on the origin of the link href or >> something would probably be doable. Having a header that tries to add some >> sort of new mode wherein the two windows _can_ see each other but can't do >> some things that they can normally do would be a snake pit of complexity >> that is best avoided. > > > I would like us to think about adding a mode where you get a MessageChannel > between the two windows. There's no synchronous access, and no ability to > navigate it, but you can talk back and forth with it. I haven't tried but I don't see why service workers couldn't be used for that.
Received on Friday, 2 December 2016 02:44:29 UTC