W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2014

Cross-origin windows and how to explain them in ECMAScript semantics

From: David Bruant <bruant.d@gmail.com>
Date: Sat, 08 Feb 2014 13:16:11 +0100
Message-ID: <52F6200B.2050606@gmail.com>
To: "public-script-coord@w3.org" <public-script-coord@w3.org>
CC: "Mark S. Miller" <erights@google.com>, Tom Van Cutsem <tomvc.be@gmail.com>, Bobby Holley <bholley@mozilla.com>
[cc'ing MarkM and Tom Van Cutsem in their quality of ES6 Proxy champions 
and Bobby Holley to be sure is in copy of this message and the responses]


The purpose of this message is to get feedback on the currently proposed 
changes for how scripts attached to a WindowProxy sees other 
cross-origin WindowProxy instances. The feedback is especially about 
whether the proposed spec can be expressed with ES6 semantics.

The journey starts at 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701 It is a very long 
line of comments, most of which aren't important anymore at this point.
The latest state of the tentative spec prose is at 
Bobby Holley also wrote tests 

As a disclaimer, I have to say that the only cases that really require a 
review are those where the page changes of origin via setting 
document.domain. Before such a thing happen, both a cross-origin  iframe 
and its parent live in mostly different worlds connected only via 
iframe.contentWindow which only contains a few methods and no way for 
the two parties to communicate besides postMessage and the 'message' event.

The particularly tricky case is the combination of:
1) from the parent, iframe.contentWindow and the global object of the 
iframe are the same object (=== observable after they become 
same-origin). This seems to be required for web-compatibility
2) The .close function each side can [[Get]] is a different value [1] 
(but remains the same if [[Get]] several times from the same context).

This is supposed to be impossible in na´ve ES semantics since the same 
object will always return the same value for a property. This is less 
true with getters and proxies, but even then, they can't decide what to 
return based on who is asking (because they're not supposed to have 
access to such an information).

However, I think that this behavior can be explained if the parent and 
the iframe are in two sides of a slightly modified dry/wet membrane [2].
In effect, the WindowProxy seen on each side of the iframe would be two 
different objects, but the scripts in each membrane could never observe 
it. However, based on which side of the membrane is asking (the handler 
knows if the proxy is wet or dry), a observably different close function 
can be returned.

Does this sound like a possible explanation of the attempted spec 
behavior? (obviously even if it is, it doesn't need to be spec'ed or 
implemented as such)

I may have gone a bit fast in this initial explanation that I tried to 
keep short; I'm happy to answer any question if something isn't clear.



[2] slide 27 of 
https://docs.google.com/file/d/0B9iYRsLxmdqUd1RsdHZtazliWmc/edit for the 
super-short version
Received on Saturday, 8 February 2014 12:16:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC