[whatwg] Objects in external security contexts

On Wed, 22 Feb 2006, Martin Atkins wrote:
> 
> My proposal is to allow client-side scripts to do something like this:
> 
> window.instantiateRemoteObject(
>     "http://www.othersite.com/script",
>     function (obj) {
>         // Do something with obj here
>     }
> )
> 
> The idea here is that some script object gets instantiated based on the 
> code at that URL. The code is retrieved asynchronously and, once it has 
> been retrieved and compiled, passed into the callback function provided 
> in the form of an object.
> 
> The key thing here is that the remote object's code runs in the security 
> context of the remote site, not the calling site. The site which owns 
> the object has no direct access to the calling site's DOM. The calling 
> site has access only to the methods and properties explicitly exposed by 
> the remote site.
> 
> This allows two sites to exchange data client-side while ensuring that 
> each party can only access what the other party wishes to share.

Given that the remote script has to be given a whole new browsing context 
to do this, it seems simpler to simply reuse the <iframe> mechanism with 
the new cross-frame communication stuff to do this. (It effectively has 
the same features.)

This also gets around the problem of the security risks of passing around 
objects created in different contexts, which have plagued certain UAs.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 24 May 2007 20:18:37 UTC