[whatwg] postMessage: event.source allows navigation of sender

[Jeff Walden]

I'm a bit late to this party due to turning off list email because I didn't think I could handle it in addition to all the other email I receive.  I just reenabled it to not miss anything; we'll see how this actually goes this time around.   :-\

Adam Barth wrote:
> On Feb 7, 2008 4:32 AM, Hallvord R M Steen <hallvors at gmail.com> wrote:
>> One case I'm still
>> somewhat concerned about is that one is allowed to set the location of
>> any top-level window according to the ancestor policy,
>
> Yes.  I think there is a lot of room for improvement in this part of
> the navigation policy.

While to an extent it seems there's agreement that the ancestor policy works well enough to not worry overly much about postMessage exposing the sender's window, the top-level window thing is a pretty big hole that breaks dumping content in an iframe if that content can't be trusted.  postMessage exposing the sender isn't that meaningful if you can just change the toplevel site, even if the location bar changes correspondingly.  (Really, who looks at the location bar on even dynamic, JSy pages other than after an intentional navigation?  I doubt I do.)

That said, I think a reply() method might be a better idea than a source property.  I'm not sure how meaningful that would be for MessageEvent generically, but I guess source had that problem already for server-sent events.  Do note it's more spec burden due to determining sender identity (could be mitigated by equating reply with calling postMessage on the proposed-hidden source property); dynamic scope-dependent behavior is no fun that way.


> It seems like a better solution is to improve the navigation policy
> for top-level windows.  That way, web sites don't have to fight the
> losing battle of controlling references to their windows.

Agreed.


> One possibility is to prevent one frame from navigating another if the
> frames are in different units of related browsing contexts.

This doesn't help the iframe case, which is something that, say, Facebook or any site that embeds Google Maps would care about -- or, indeed, any site that wanted to display some other site in an iframe.  The subsequent _unrelated proposal would need an extension for frames/iframes for this to be a complete solution.

Jeff