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

Fri Nov 30 18:57:53 PST 2012

This thread discussed solutions for, amongst others, the following use 
cases, provided to me off-list by Steven Wittens:

> A first huge use case is Facebook Apps, which are inserted using
> iframes. They currently use ugly cross-frame communication methods
> to shrink-wrap and auto-size the iframe. As an ex-FB dev, this has
> always been a huge source of frustration and bugs. Facebook Apps
> don't want to inherit CSS from the parent site, it only means the
> layout will break whenever Facebook makes a stylistic change or
> reorganizes their CSS. Replace Facebook with any other service
> provider that allows some form of 3rd party development/integration
> through iframes.
>
> A second use case would be any sort of embeddable widget that comes
> with "pre-baked" styles (think Twitter sidebar widgets). Same
> problem, but in reverse. At my last job, we had a drop-in iframe
> product that provided an entire "contest in a box", with media
> submission, entry browsing/searching, modal dialogs, etc. Inheriting
> styles from the parent page would simply destroy the careful layout
> of what's inside. We shrink wrapped it by requiring people to embed
> a script tag rather than iframe tag, using cross frame communication
> to send a manual measurement from the frame to the parent. Ugly, and
> didn't work in older browsers, and we didn't have the resources to
> come up with an XD-proxy workaround like Facebook has.

Markus Ernst also discussed the use cases:

On Fri, 13 Apr 2012, Markus Ernst wrote:
> 
> I assume that one popular use case for seamlessly embedding cross-origin 
> frame content is: A service provider allows his/her customers to embed 
> the pages provided. In this case, the info needed is a list of domains 
> that are allowed to embed the content, rather than an allowseemless 
> yes/no flag.

On Sun, 27 May 2012, Markus Ernst wrote:
> 
> My use case is a content provider, who provides e.g. a Sudoku 
> application or a weather forecast for wind surfers. Paying customers are 
> allowed to embed the content seamlessly in their web sites. The content 
> can also be embedded for free, but not seamlessly.
> 
> The content provider includes some corporate info, such as his/her own 
> logo, and a "provided by XY" notice and link to his/her own page. The 
> paying customers then can apply their own styling, and set the corporate 
> info to "display:none" in the style sheet of the top document, via 
> seamless embedding.

...and Adam Barth posted some on the wiki:

> Dashboard: A dashboard web site wishes to display status indicators that 
> are hosted on a number of different domains. The size of these status 
> indicators varies depending on the status. For example, if a given 
> domain is having difficulty, the status indicator might list the 
> problems the domain is having.

> Expandable Advertisement: A publisher wishes to display an advertisement 
> that expands when the user interacts with the advertisement. Today, the 
> common practice is for the advertising network to run script in the 
> publisher's page that receives postMessage instructions to resize the 
> advertisement's iframe, but this requires that the publisher allow the 
> advertisement to run script in its page, potentially compromising the 
> publisher's security.

So basically, we're just looking for a way to let cross-origin content 
opt-in to being shrink-wrapped and/or styled on a per-origin basis.

On Thu, 12 Apr 2012, Adam Barth wrote:
> 
> [...] something like an attribute on the <html> element might be a 
> better mechanism [...]

That wouldn't work because you need to know before you start parsing, 
because at any time after you start parsing you might have to render, and 
you need to have decided whether to shrink-wrap or not by then. Also, it's 
probably best if we don't make this something you can dynamically change 
while the page is loaded, at least unless there's a compelling use case.

On Thu, 12 Apr 2012, Anne van Kesteren wrote:
> 
> [...] the enormous growing number of one-off flags developers can attach 
> to resources for various features is starting to get worrisome.

Yes, reusing something that exists already seems like a solid win. It's 
not clear anything suitable exists, though.

On Sat, 26 May 2012, Adam Barth wrote:
>
> [CSP]

CSP doesn't seem to include any features that would let you limit who is 
allowed to iframe you, so I don't think CSP as designed today provides a 
solution for the per-origin part. Could it be extended?

> [X-Frame-Options]

This doesn't let you chose on a per-origin basis whether you can be framed 
either (since you don't get an Origin header in the request, and the X-F-O 
header only gives a thumbs-up or thumbs-down in general).

I'm dubious about extending X-F-O since it lacks a spec and so how exactly 
to change it in a backwards-compatible way is unclear and getting it 
wrong would be very dodgy.

On Thu, 12 Apr 2012, Ojan Vafai wrote:
> 
> we could add a special http header and/or meta tag for this, like 
> x-frame-options, but for the child frame to define it's relationship to 
> the parent frame.

Yeah.

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

(Split on spaces, ignore unknown tokens.)

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

For the case of things that can be embedded by anyone but only seamlessly 
by paying clients, I would recommend putting the origin in the URL, and 
then limiting the embedding to that URL using CSP.

Is this a viable direction?

(There was also some discussion about how it should maybe be possible to 
do cross-origin DOM access, but that isn't really an option, as was 
discussed in the thread, so I haven't explored it further.)

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