[whatwg] Cross-domain components

[Henrik Gulbrandsen]

Hello,

I've been trying to find a solution to a general cross-domain component
integration problem. Unfortunately, I have to conclude that not only is
this mostly unsupported by the existing generation of browsers, but even
the current WA1 draft misses the mark. Comments on this are welcome!

Basically, this is the scenario I imagined:

1. A website includes an iframe that holds a third-party widget loaded
   as HTML from another domain. All communication between this widget
   and the main page takes place entirely via client-side JavaScript
   through a well-defined interface. For example, let's say that the
   widget is a calendar application and that the provided interface
   allows a page to request that an event is added to the calendar.

2. Here's the twist: the site does not explicitly ask for a particular
   calendar widget to be loaded. Instead, it simply gives a URI that
   identifies a publicly available interface definition. The user may
   therefore change the mapping of this URI to the calendar service
   that best serves her needs. This means that the same calendar can
   be available on many visited sites, collecting different events.

3. Finally, since the website and its widget are loaded from mutually
   untrusted domains, no information should leak from one to the other,
   except for what is needed to use the interface. In particular, it
   must NOT be possible for one side to learn the identity of the other
   domain, unless this info is explicitly provided. The calendar choice
   is a user's private business, and so is her history of visited sites.

Now, let's see how this fits with current and imagined browsers. Item 1
simply introduces a need to break the same-origin policy in a controlled
manner. This is currently hopeless to do in a browser-independent way,
but the current WA1 draft adds cross-document messaging to fix it.

Item 2 can in principle be done today, for instance by using an ordinary
URL as the "interface defining" URI and make it redirect to the calendar
site based on a cookie. This could work for a single widget service, but
breaks down if we imagine multiple popular components of this type that
should follow a user's preferences even when surfing from a cybercafé.

There may be existing solutions for that. Otherwise, one possible way is
to add a global login for the browser session. A quick MD5 or SHA-1 hash
of email address, password, and the interface URL would give a unique
string that can be added to the interface URL instead of the cookie.
Including the URL in the hash ensures that a user's identity string for
one widget service is not identical to that used for another service,
which may be a useful feature from a privacy point of view.

Item 3 highlights a privacy leak in the cross-document messaging API
specified in the current WA1 draft. It's clear that postMessage() was
not intended for this kind of scenario, since the domain attribute will
completely break any attempt to hide the two domains from each other.

OK. I'll stop here. Please comment and let me know if I'm a fool! :-)

/Henrik