[whatwg] Cross-domain components

[Henrik Gulbrandsen]

On Sat, 2007-04-28 at 02:43 +0000, Ian Hickson wrote:

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

The keyword here is "multiple". I was imagining a scenario where this
kind of integration becomes popular, and the user has not only the given
calendar widget, but also an email launcher, a spreadsheet manipulation
widget, a website preference negotiation component, a payment service
provider widget, and a context-sensitive application toolbar integrated
with the main menu of a given site.

All of these might not be used on a single site, but it would still be
very annoying to have a separate login for each and every component.
That is why I mentioned the "global login" option in my original post.
With a single login per browser session, this generalized mashup would
actually scale; it's also useful as a general cross-site login method.

One way to do this would be to have a URI-Specific Profile ID that acts
as the combined username/password secret for a specific web resource.
Let's say that the client looks for a string like "(*URISPID*)" in all
loaded URLs. If the string is found, it is replaced with an MD5 hash of
a local user secret (username/password) combined with a part of the URL.
If the client doesn't support this feature, the "(*URISPID*)" part is
left unchanged, so the server can fall back to a traditional login page.

For example, an access to

  https://www.example.com/interfaces/calendar/v1?id=(*URISPID*)&option=1

could have its "(*URISPID*)" part replaced by

  hash(hash(username + ":" + password) + ":" + base_url)

where base_url = "https://www.example.com/interfaces/calendar/v1".


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

Well, in principle you don't want those messages to be exposed to the
redirecting domain either, but I suppose that the interface publisher is
more trusted than the other domains. Since the interface is central, any
attempt to pass private data back to the server would be noticed quickly
by someone. Besides, if the redirecting domain isn't trusted, it can use
the proxy iframe anyway, although we are actually expecting a redirect.

This means that your workaround is most likely acceptable for this case,
although I'm slightly worried that it might not cover other scenarios.
In general, it's probably safer if the author must request to have the
domain visible when it should be checked, rather than the other way
around, since he may not remember to hide it when that is needed.

However, I don't feel strongly about this, since I don't know if domain
hiding will ever be strictly necessary. Let's just keep it in mind, so
we don't make this hole in the same-origin policy bigger than it needs
to be. Perhaps a hide/show flag argument to postMessage() is worth the
extra trouble, just to stay on the safe side.

/Henrik