[whatwg] Making cross-origin <iframe seamless=""> (partly) usable

[Ian Hickson]

On Mon, 3 Dec 2012, Mikko Rantalainen wrote:
> > 
> > It seems to me like the best solution is to have a new HTTP header, 
> > with the four following values being allowed:
> > 
> >    Seamless-Options: allow-shrink-wrap
> >    Seamless-Options: allow-styling
> >    Seamless-Options: allow-shrink-wrap allow-styling
> >    Seamless-Options: allow-styling allow-shrink-wrap
> 
> Not that I fancy for expendable advertisement, but I fail to see how 
> that is supposed to work with those headers. Basically I think that in 
> such case, the host document should be able to specify something like 
> following:
> 
> (1) I want to embed a seamless untrusted iframe here, and
> (2) iframe should have maximum size of e.g. 480x240 pixels (or any size
> set via CSS max-width/max-height). However, if user interacts (I guess
> moving focus inside the iframe is enough) with the iframe, then
> max-width and max-height are set to "expanded state" (whatever that means).

It's not clear to me why the host would need to control this with the UA's 
help. If you trust the embedded page to say when it needs to expand, which 
it seems you must for any but the most trivial of interaction models, then 
you can just trust the page to expand any time it wants. If you don't 
trust the page at all, it seems dangerous to embed it at all, since it can 
spoof you (it's a seamlessly embedded page, after all).

(You can set maximum dimensions using CSS, in any case -- the iframe is 
still just a regular block, so max-height applies.)


> Does there need to be any support for expendable seamless iframe without 
> scripting?

I doubt it, but in principle I don't see why scripting would be needed.


On Mon, 3 Dec 2012, Adam Barth wrote:
> 
> Yeah, I can see how you ended up with an HTTP header.  I wonder if it 
> would make sense to align this stylistically with CORS.  For example:
> 
> Access-Control: allow-shrink-wrap, allow-styling

I don't know. Using CORS-like headers seems misleading to authors, they 
might think that they work together.


> > Then for the per-origin control, we would extend CSP to have a flag 
> > for limiting who is allowed to embed you (subsuming X-Frame-Options, 
> > essentially).
> 
> That's already planned for CSP [...]

What progress has there been on the CSP front in terms of allowing a page 
to list which origins can embed it? That's the main missing link here; I'd 
really rather not reinvent CORS just for seamless iframes. (We can't use 
CORS itself, obviously, since that would grant reading privileges.)

The proposed solution for cross-origin iframes is still the solution 
proposed at the bottom of this e-mail:

   http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0006.html


On Sat, 15 Dec 2012, Jonas Sicking wrote:
> 
> One solution would be not not render the contained document in the 
> <iframe seamless=""> until we hit the element that opts in to 
> cross-origin seamless rendering.
> 
> If the document never opts in, it'll never get rendered, but is still 
> loaded.
> 
> This might be non-trivial to implement though since I believe that 
> unrendered documents is not something that exists in the platform today. 
> The simplest way to emulate it would be to make the <iframe> act as if 
> it was display:none.

The other problem with markup is that it's mutable, which means we'd have 
to define how and when it takes effect and how to react to changes, and 
there's typically difficulties with dealing with race conditions and it 
can be vulnerable to injection attacks. Working around these is possible; 
we did so to a great extent with manifest="", but it requires deep 
integration into things like the parser and navigation algorithms.


On Mon, 14 Jan 2013, Nasko Oskov wrote:
>
> We are currently working on a new security policy in Chrome, which will 
> separate each site into its own renderer process. More information can 
> be found at:
>    http://www.chromium.org/developers/design-documents/site-isolation
> 
> One of the requirements of this model is that cross-origin iframes will 
> be rendered in a separate process from the main document. Since seamless 
> iframes are currently allowed only if they are same-origin, this works 
> fine. If we move to a mode where seamless iframes are allowed for 
> cross-origin pages, it makes our isolation model very difficult to 
> implement correctly. An example would be input events, which according 
> to our reading of the spec for seamless should cross the iframe 
> boundary. This means that we have to maintain synchronous model for 
> event capture/bubble phases across multiple processes, which is prone to 
> either deadlocks or environment inconsistency.
> 
> Based on the existing security concerns listed in the proposal and the 
> fact that it might prevent a useful new security architecture in 
> browsers, I would suggest this not be added to the web platform.

How would you propose to address the use cases instead?

   http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0006.html

(Having said that, if we don't forward events and styles, I don't think 
there's any problem with the rest of this relying on message passing. At 
that point it's only sizing, after all.)


On Mon, 14 Jan 2013, Nasko Oskov wrote:
> 
> The input events was just one example. There are other cases where 
> having an asynchronous boundary can lead to unexpected behavior for 
> developers.
> 
> * The current spec (
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-seamless)
> calls
> for merging the collection of links between seamlessly nested documents:
> "For example if the user agent supports listing all the links in a
> document, links in "seamlessly" nested documents would be included in that
> list without being significantly distinguished from links in the document
> itself."
> If the parent document is trying to access the set of links, while the link
> has been removed from the nested document, there will be a race condition.

I think you're misreading this. It's only referring to user interface, not 
to DOM APIs.


On Tue, 15 Jan 2013, Markus Ernst wrote:
> 
> The allow-seamless mechanism is to be triggered at the side of the 
> embedded resource, which would also be the one affected by possible 
> security risks (if I get this right). The developer of this resource 
> will have to be aware of these risks, and avoid to expose critical stuff 
> in pages that allow seamless embedding.

Both sites would be made vulnerable to each other, but if we make it so 
both sites have to explicitly opt-in to accepting the other site before 
the embedding could be seamless, this seems somewhat safe to me. It's 
unlikely that one site is going to want to be embedded in a hostile site, 
or vice versa, and explicitly allow it.

Unless we allow wildcard embeddings, in which case the embedded resource 
is at the mercy of hostile sites.


On Fri, 18 Jan 2013, Markus Ernst wrote:
>
> I did not mean to merge origins, but to completely detach the included
> resource from its origin, and allocate it to the origin of the including
> document:
> 
> - Document from A domain-A.com includes resource B from domain-B.com
> - Resource B has set AllowSameOrigin="domain-A.com"
> -> Document A and resource B can access each other as same-origin
> 
> - Now Resource B tries to access resource C from domain-B.com
> - Resource C does not have AllowSameOrigin specified for domain-A.com
> -> Resource B cannot access resource C, as it would violate the same-origin
> policy. Resource B is treated as of origin domain-A.com.
> 
> I don't know whether this is possible, but I think if yes, it would be 
> an elegant solution to this topic.

This would violate all kinds of assumption in the platform. For example, 
what localStorage could they read? What XMLHttpRequests could they 
perform? What domain would a WebSocket have to accept connections from?
Having the URL of the page not match its origin would lead to all kinds of 
issues, also. This sounds like a disaster waiting to happen.

But anyway, none of this is necessary. Even if the embedded page is in the 
same process, it can still be cross-origin, even in a system that usually 
isolates origins.

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