[whatwg] window.opener and security
Hallvord R M Steen
hallvors at gmail.com
Tue Mar 20 06:21:16 PDT 2007
On 20/03/07, Gareth Hay <gazhay at gmail.com> wrote:
> Well, window.opener is conceptually a link from child to parent.
> Can you give a valid use-case for adoption of the child to another
Again: We are off-topic. This isn't what I'm trying to discuss in this thread.
However, here are two use cases for you:
1) I don't want the next page to mess with opener:
(basically what sites should do today to work around the phishing
potential issue, but AFAIK none do.)
2) I have contents in an IFRAME that I want to talk directly to MY opener:
What are your "exploit cases" where setting .opener is so dangerous
that it should throw? Note that making it throw also means being
backwards incompatible with
var opener='Once upon a time, ';
which might be far-fetched but certainly will exist somewhere if
browsers haven't thrown exceptions so far.
Now if you have time I'd like some comments on the proposal
> On 20 Mar 2007, at 13:00, Hallvord R M Steen wrote:
> > On 20/03/07, Gareth Hay <gazhay at gmail.com> wrote:
> >> window.opener should be read-only and attempting to write to it
> >> should throw an exception.
> > I don't really see why setting opener would be dangerous, so I
> > disagree that it should throw. Anyway, that is a different issue. What
> > I'm talking about is the built-in behaviour - the browser itself sets
> > window.opener in all popups, and there is currently no way to open a
> > popup that is prevented from changing the location of its opener.
> > (An exception is Opera applying a stricter security policy if the
> > opener is an https page so in this case popup can't set location of
> > its opener, but I'm not sure if the other UAs do this.)
Hallvord R. M. Steen
More information about the whatwg