W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: WebIDL and prototype chains

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 14 Aug 2009 22:52:00 +0000 (UTC)
To: Adam Barth <w3c@adambarth.com>
Cc: Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>, public-webapps <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.62.0908142251280.6420@hixie.dreamhostps.com>
On Sat, 8 Aug 2009, Adam Barth wrote:
> On Fri, Aug 7, 2009 at 5:51 PM, Ian Hickson<ian@hixie.ch> wrote:
> > How should I address this for HTML5?
> 
> We talked over several option in #whatwg.  Here's something that might
> make sense.  The approach below is designed to allow for robust
> implementation and to isolated the "magical" properties in the window
> object.
> 
> Principle: Two distinct origins should have distinct JavaScript object
> graphs.  The only point of contact between the JavaScript objects of
> different origins should be window objects (or, more precisely,
> WindowProxy objects).
> 
> Rules:
> 
> 1) When a script gets a property from a same-origin window object, the
> script gets the same object as the page itself gets.
> 
> 2) When a script gets a property from a cross-origin window object,
> the script gets a *new* object with the appropriate interface.
>   a) This new object is created in context of the accessing script
> (i.e., the current lexical scope).  That means it gets a prototype
> chain as appropriate for the accessing script.
>   b) If two scripts from the same context access the same property,
> they get the same object.  That is, we cache these newly created
> objects per accessing window.  (They will likely be garbage collected
> with that window as well.)
> 
> Corollaries:
> 
> 1) Suppose property foo is visible across origins and a script changes
> it's own window.foo property in some way.  That change is not visible
> to cross-origin viewers (because they get a fresh instance of whatever
> the foo object originally was.)
> 
> Note: This behavior matches Firefox but differs from IE.  In IE,
> cross-origin viewers tend to see the value |undefined| when viewing
> properties that have been modified by the page.  This causes minor
> security issues.
> 
> 2) If two scripts from two same-origin windows get some property from
> the same cross-origin window, the values they obtain will not be ===.
> This is to avoid having different behavior based on which script
> accesses the property first.
> 
> 3) If one script grabs some property from a cross-origin window and
> then later because same-origin with that window (e.g., via
> document.domain tricks), then that script will get a different object
> (the "real" one) if it access the property again.

I've tried to spec this.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 14 August 2009 22:52:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT