- 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>
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 :/ > * REFERRER 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 http://dev.w3.org/html5/workers/ 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 http://annevankesteren.nl/
Received on Wednesday, 17 June 2009 11:30:23 UTC