On Wed, Nov 30, 2016 at 10:53 PM, Boris Zbarsky <bzbar...@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. > > > -Boris >
