W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

XHR and sandboxed iframes (was: Re: XHR without user credentials)

From: Anne van Kesteren <annevk@opera.com>
Date: Wed, 17 Jun 2009 13:29:38 +0200
To: "Mark S. Miller" <erights@google.com>
Cc: "Tyler Close" <tyler.close@gmail.com>, "Adam Barth" <w3c@adambarth.com>, public-webapps <public-webapps@w3.org>
Message-ID: <op.uvn17ojk64w2qv@annevk-t60>
On Wed, 17 Jun 2009 01:52:36 +0200, Mark S. Miller <erights@google.com> wrote:
> I've now read the relevant portions of <
> http://dev.w3.org/html5/spec/Overview.html#the-iframe-element>. Looks  
> like a
> great start on the right direction! I'm genuinely enthused. Some  
> questions:

FWIW, I may be wrong in which case I hope Ian will correct me.

> The second example says "[...] and the origin sandbox restrictions are
> lifted, allowing the gadget to communicate with its originating  
> server."  I
> don't understand this. Given the cors this document assumes, couldn't the
> gadget do a cross-domain xhr to the originating server anyway?

HTML5 does not assume CORS at this point I believe. Having said that, the "sandboxed origin browsing context flag" does more. It forces the content of the <iframe> into a unique origin. A number of features are disabled because of this:

 * storage
 * same-origin communication channels
 * document.cookie
 * communicating with the document that hosts the <iframe> if they're same-origin

And maybe more.

> Does an xhr from a sandboxed unique origin iframe carry any credentials  
> in the sense in which we've been using in this thread:
> * HTTP auth info
> * cookies (I think the text implied not, but I'd like to check.)

I don't think these are impacted though XMLHttpRequest cannot be used to read or set cookies. (They will still be included in the request as currently drafted.)

> * client-side certs

I don't have sufficient knowledge about these to answer :/


I think Referer is still included. This may have been an oversight.

> * identified Origin (clearly not if I understand the spec)

Unless same-origin is set the origin is a unique identifier. That equals the string "null" in requests.

> * Anything else I forgot?

I don't think so.

> If it does transmit any of these currently, are there any objections to
> revising the spec so that it doesn't?

Not necessarily. I'd like to know what Ian thinks about this.

> What happens if a data: URI appears as the value of the src attribute?  
> Would this allow the containing page to construct and provide the source  
> directly? Or is this what the document="..." you mention above is for?

The document="" or doc="" idea is to have something simpler than data URLs. Basically all you'd have to escape is the double or single quotes used around the attribute value and inside could be a complete HTML document. data URLs accomplish the same but are tricker with respect to escaping rules.

> How does a sandboxed, unique origin iframe communicate with its  
> containing page? My guess is postMessage, which is necessarily asynchronous.  
> However, the useful functionality of the GuestXHR we've been discussing would be
> async as well. (Unless html5 has separate provisions to make sync xhr
> practical, which would be surprising.)

If you spawn worker threads as detailed in 


synchronous XMLHttpRequest is somewhat usable again. Though not ideal if you also care about things such as progress events etc.

> So async GuestXHR would play well
> with async postMessage as follows:
> Given the above elements including the removal of all credentials and the
> acceptance of either document="..." (if I have that right) or
> src="data:...", then it seems we may be able to build the GuestXHR we've
> been talking about as an object in the containing page that uses  
> postMessage
> to relay requests to a sandboxed unique origin iframe acting as a  
> credential removal laundry. Is this analysis right? What am I missing? In what ways
> would these not be equivalent?

postMessage reveals the origin of the containing page. On the other hand, if a sandboxed <iframe> restricts XMLHttpRequest in various ways XMLHttpRequest is GuestXMLHttpRequest in a sense unless I'm missing something.

> If the above speculations are on the right track, it could be the basis  
> for something much simpler than cors for enabling cross origin xhr requests:
> Only allow cross origin xhrs from browsing contexts that have the  
> "sandboxed origin browsing context flag" set. These xhrs are credential-free and not
> associated with any other origin, and so can safely go cross-origin. For  
> any browsing context without this flag set, its xhr is restricted by the
> conventional old same-origin policy. If it want to issue a cross origin
> request, it can use a sandboxed unique origin iframe to launder out any
> credential confusion.

I followed you so far, but I don't think we want this :-) Besides that this causes issues for sites based on IP-authentication it seems that having credentialed XMLHttpRequest is a useful thing to have.

> The recommended server behavior would then be to allow or deny an  
> "Origin: null" request based only on authorization information explicitly placed  
> into the payload, avoiding confused deputy confusions.
> All redirect-path origin accumulation problems disappear as unnecessary,  
> as would server-side origin-based ACLs.
> Thanks for your patience and my apologies for taking so long for  
> following up on your question.

It is certainly an interesting thought, but I don't think we can out of server acknowledgment of cross-origin requests in one way or another. Intranets outside the typical IP-range. Sites using IP-based authentication.

Anne van Kesteren
Received on Wednesday, 17 June 2009 11:30:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 14:36:35 UTC