[whatwg] Cross-domain components

Hi,

Thanks for your input.

On Sun, 25 Mar 2007, Henrik Gulbrandsen wrote:
> 
> 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.

We have a cross-frame messaging interface which I hope address this need:

   http://www.whatwg.org/specs/web-apps/current-work/#crossDocumentMessages

Let me know if it needs improving to address your needs.


> 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.

You could do this today using DNS and/or HTTP redirects. That is, someone 
can set up a service where you go and pick your preferred calendar, then 
<iframe>s can point to that service and the service will HTTP redirect you 
to the preferred calendar based on your settings.


> 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.

I believe this is indeed also possible today.


> 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.

Right.


> 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.

Right.


> 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?

This could work, you just need the original iframe to show a login page 
instead of the widget, and then once the user has logged in, use the 
preferred widget.


> 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.

Hm, interesting. It's true that the current design leaks the domain. You 
could get around that by having messages proxied through the original 
redirecting domain, though; no privacy leak there since the original 
domain is know to the embedding page and the chose widget provider has to 
be known to the middleman already.

We need the domain to be present in the general case for security (so that 
you can make sure you're not being driven by unexpected content). I'm not 
sure we can remove it. Given the existence of the workaround by using a 
proxy iframe, I think we can punt on the problem for now -- if it turns 
out to be a major problem, we can address in future, e.g. by having an 
argument to postMessage() that hides the domain.

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

Received on Friday, 27 April 2007 19:43:13 UTC