[whatwg] Proposal for Links to Unrelated Browsing Contexts

[Charlie Reis]

On Wed, Jun 13, 2012 at 4:44 PM, Michal Zalewski <lcamtuf at coredump.cx>wrote:

> > Any feedback on this revised approach?
>
> My vague concern is that the separation is a bit fuzzy, beyond saying
> that window.opener will be null... if that's the only guaranteed
> outcome, then maybe that should be spelled out more clearly? The
> degree of separation between browsing contexts is intuitive in the
> case of Chrome, given the underlying implementations, but will it be
> the same for Internet Explorer or Firefox or Safari?
>

That's a fair point, since those browsers have a global namespace for
windows.  You're right that the main change would be not setting
window.opener or returning a value from window.open, even though the
windows might find each other through other means in those browsers.


>
> Let's assume that there is no Chrome-style process isolation, and that
> this is only implemented as not giving the target=_unrelated document
> the ability to traverse window.opener. If the document's opener lives
> in an already-named window (perhaps unwittingly), it won't be
> prevented from acquiring the handle via open('',
> '<name_of_that_window>'), right? That may be unexpected.
>
> The same goes the other way - the spec subtly implies that because
> window.open('foo', '_unrelated') returns null, the opener will not be
> able to mess with the opened window, but that's not guaranteed given
> that the reference may be leaked by other means, right?
>
> /mz
>

Correct.  In that example, the new window could give itself a name, and the
opener would then be able to find it (in browsers with a global namespace
for windows).

I'm not sure how easy it would be to create a different namespace for the
unrelated window in other browsers, and I don't expect that to change.  I
still think this proposal can be useful, though, especially for an unnamed
window trying to open an untrusted link.

It's worth noting that pages that don't want to be found already either
have to clear their name or use an unpredictable one, and that wouldn't
change here.

I can call this issue out more explicitly in the proposal if you'd prefer.

Charlie