W3C home > Mailing lists > Public > public-html@w3.org > May 2008

Re: The <iframe> element and sandboxing ideas

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 22 May 2008 11:27:00 -0500
Message-ID: <48359ED4.6080501@mit.edu>
To: Ian Hickson <ian@hixie.ch>
CC: whatwg <whatwg@whatwg.org>, HTMLWG <public-html@w3.org>, public-webapi@w3.org

Ian Hickson wrote:
>      - by default, content in sandboxed browsing contexts, and any
>        browsing contexts nested in them

How do those nested browsing contexts come about, given that later you say:

 >     - content in those browsing contexts cannot create new browsing
 >       contexts or open modal dialogs or alerts

?

>        have a unique origin
>        (independent of the origin of their URI); this can be overriden
>        using the "allow-same-origin" keyword

So the parent page cannot script the contents of the iframe by default, right?

>      - by default, script in those browsing contexts cannot run; this can
>        be overriden using the "allow-scripts" keyword

What happens if the parent page sets window.location to a javascript: URI on the 
sandbox iframe?  Does the script run?  If so, in which browsing context?

>    causes the iframe to size vertically to the bounding box
>    of the contents, and horizontally to the width of the container

I assume that the bounding box is computed after setting the width?

By "the width of the container" do you mean that the iframe computed width 
should be equal to its containing block's computed width?  Or that the 
display:block non-replaced width algorithm from CSS should be used?

>    and which causes the initial containing block of the contents to be
>    treated as zero height.

So percentage heights would end up being 0, while the iframe would be whatever 
height is needed if one assumes they're auto?

>    and the style sheets that apply to the <iframe>
>    must also apply to the contents.

But the ' ' and '>' combinators don't cross the iframe boundary, right?

> This is all HIGHLY EXPERIMENTAL. I am looking for feedback on the general 
> approaches taken.

As someone else pointed out, this doesn't seem like it would be usable without 
some UA sniffing or something, as things stand.

> There are various things that this doesn't address yet; e.g. there's no 
> way to force (or even allow) a non-seamless iframe to open links in the 
> parent window.

This could be an @sandbox keyword value.

> This attribute would 
> take a string which would then be interpreted as the source document 
> markup of an HTML document, much like the above

This seems very prone to security issues (injection of the closing quote in the 
content) to me...  The base64 approach is nice in that you can't shoot yourself 
in the foot with it.

-Boris
Received on Thursday, 22 May 2008 16:28:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:55 UTC