[whatwg] Objects in external security contexts

[Martin Atkins]

Hi folks. I'm new here on the mailing list, but I've been following
progress with the various WHATWG specs for a while now.

The following proposal doesn't really have any relationship to any
particular specification currently being considered by WHATWG, but after
much consideration I decided that this was the best forum to propose it,
since it is certainly related to web applications.

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.

The use-case that immediately springs to mind is Google's text ads.
Currently sites embed Google's ads by simply referencing a script file
on Google's server. This script then runs in the calling site's security
context, which gives Google complete access to the calling document's
DOM. This also means that Google mandates the presentation of the ads,
rather than the embedding site. Finally, it requires that parameters be
passed as global variables, which isn't very "clean".

A better way, perhaps:

window.instantiateRemoteObject(
    "http://www.googlesyndication.com/pagead",
    function (adManager) {
        var adbox = document.getElementById("adbox");
        var adlist = adManager.getAdverts();
        // Generate some stuff inside the adbox element
    },
    {
        clientid: "4534523465243564",
        channel: "cheese"
    }
);
(the third parameter here is an arbitrary parameter to be passed to the
object somehow. Here I've used a JavaScript object containing some named
parameters.)

(NB. I'm ignoring the fact that Google probably *wants* to control the
presentation here; feel free to think of other use-cases where the
mighty buck isn't involved and people are just sharing data for its own
sake.)

It's also possible that certain de-facto standard interfaces would
emerge for doing a particular job, which several sites could then
implement and inter-operate with one another.

The important characteristics are:
* The remote object runs in its own global scope and can't do anything
at all to the DOM or other objects in the caller unless the caller
explicitly passes data to one of the methods or properties of the object.
* Likewise, the caller can't access anything in the remote object's
scope unless it's explicitly returned from a property or method of the
object. (This implies that the remote object can use "private"
functions/data by simply creating global variables in its own scope)
* The remote object can do anything that would normally be allowed of a
page on the remote site, such as use XMLHttpRequest to call back to its
own domain to fetch data.
* Each party makes data available explicitly. Nothing is available by
default.

A few details remain to be worked out:
* What should happen if the remote script cannot be retrieved, or can't
be executed for some other reason? The caller needs to be informed of
this case somehow.
* The specifics of how this remote object is described and how it is
instantiated remain to be seen. I'm open to suggestions.

This could be very useful when used in conjunction with XBL. For
example, imagine an XBL-powered news ticker that gets its news from an
exposed object on another site, which might itself fetch the news from
an RSS feed using XMLHttpRequest. Of course, the calling site doesn't
need to care where the data comes from as long as the API stays consistant.

In fact, I'd probably be inclined to use such a thing even with scripts
that live on the same site, since it keeps the code compartmentalised
nicely and avoids filling the global scope with loads of junk.

Comments, suggestions and other thoughts are welcome.

Cheers,
-Martin