[whatwg] Iframe dimensions

On Mon, Jul 5, 2010 at 1:13 PM, Markus Ernst <derernst at gmx.ch> wrote:
> Some content from an external specialized content provider is included in
> an existing web site via an iframe. This cannot be seamless, as the links
> in the iframe must point to the original domain of the included document.
> But in order to avoid double scroll bars, it would be desirable to have the
> height of the iframe adjusted to it's content.

This use-case is inherently insecure.  An iframe's height cannot
depend on the contents of a cross-origin page unless that origin
explicitly opts in somehow.

> I found that the dimensions of the iframe element are handled along with
> those of other embedded content such as img, video and others:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#attr-dim-width
>
> There is no indication about what a UA should do when dimension attributes
> are not specified.

I can't find it either.  If it's really not specced anywhere, that's a
bug that should be fixed.

On Mon, Jul 5, 2010 at 3:37 PM, Markus Ernst <derernst at gmx.ch> wrote:
> I can't imagine how the information about the computed width and height can
> be abused - would you mind giving an example?

For a basic example, suppose that a page on some site is reliably a
different height depending on whether you're logged in or not (this is
usually true).  Then when you visit my site, I could create a hidden
iframe with the other site inside, and measure the height from
JavaScript.  Then I'd know whether you're logged in on that site.
There are lots of other conditions that would change the height of a
page, and they could leak a large amount of information to arbitrary
third-party sites.  No site should be able to find out anything about
your use of another site, to the extent possible.

> A possible workaround to security issues could be an element to be set in
> the included document, such as a meta tag that contains a comma separated
> list of domains that are allowed to include the document, and also get
> informations about dimensions and such. Some kind of:
> <meta name="allow-embedding" content="whatwg.org, mozilla.com">

This could be handled by seamless using CORS or whatever, sure.

> Also, if this is a potential danger, should the 2 list paragraphs about
> width and height in the part on @seamless be removed at all? As far as I
> understand, the effects of @seamless require the iframe source to be from
> the same origin as the parent document, thus I think that width and height
> of an iframe should be computed independent from @seamless. Else, the whole
> page layout is likely to change if the iframe source is navigated from a
> same-origin document to one from another origin.

You're correct: if you navigate the iframe to a different origin, the
iframe will no longer be seamless, and all the effects of seamless
will cease to apply.  This means it will change height and width, CSS
rules won't apply, etc., etc.  The presence of seamless="" does
definitely change the width and height computations, and many other
things.

> I don't think the 2 solutions I proposed would do any BC harm:
> - Inventing a new attribute does not affect legacy browsers (as they will
> ignore it), nor legacy pages (as they don't have it).

Yes, this is why the seamless attribute works.

> - Interpreting the CSS declaration display:block as the author's wish to get
> the iframe rendered like a block element is nothing but consistent. There
> has been no reason for authors to apply this declaration so far, but if
> anyone did, he/she wanted the rendering I suggest. If not (for example if
> the iframe is floating), he/she also applied dimensions, be it in the HTML
> or the CSS code.

The author might or might not originally have wanted the behavior you
said, but in the end, the site doesn't render that way, and changing
the rendering like that would make the site look very different from
the way it looked before (= the final product that the author was
satisfied with and released).

Received on Monday, 5 July 2010 13:50:20 UTC