W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2016

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

From: Michael A. Peters <mpeters@domblogger.net>
Date: Thu, 1 Dec 2016 18:43:58 -0800
To: whatwg@lists.whatwg.org
Message-ID: <b8a2267b-5a9a-d5c5-043c-d68b8ca1e124@domblogger.net>
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

This archive was generated by hypermail 2.3.1 : Friday, 2 December 2016 02:44:29 UTC