[whatwg] window.opener and security

[Gareth Hay]

On 20 Mar 2007, at 15:45, Hallvord R M Steen wrote:

>> 1) Either it is your responsibility to handle the nulling of the
>> property *or*
>> 2) It is the UA's.
>
> The UA can not do this. It would break legacy pages by resetting
> window.opener if content comes from a different server.
>
If this is a security point, which I take from the subject  
"window.opener and security" it is, there is no problem with a UA  
breaking an implementation that relied on insecurity.
I can't think of a single reason that when a user navigates to  
another domain, you would want that domain to access your  
window.opener, so the UA clearly could do this.

>> I personally think the UA should handle it (as stated previously)
>> **BUT** if they do not, you *ARE* responsible for programming
>> correctly and using an unload to null the property when someone
>> navigates away.
>
> Wouldn't it then be cleaner to be able to tell the UA in advance that
> the window should not have an .opener property?
>
Isn't this about security?
There is no security risk allowing your own window to access .opener.
When you switch domains, the UA either nulls it, or as is the current  
case, on WebKit at least, it throws exceptions when you try to access  
it.

I don't see the need for this property at all.

>> **AND** you seem to want this extension to cure a problem, that is
>> also cured by window.opener.opener
>
> You mean window.top.opener . No, that issue is in no way related to
> the suggested extension.

i didn't mean window.top.opener

> document.getElementsByTagName('iframe') 
> [0].contentWindow.opener=self.opener;