[whatwg] The <iframe> element and sandboxing ideas

[Kristof Zelechovski]

1. Nested browsing contexts in a sandboxed frame cannot be created
dynamically but they can be defined by the inner markup.
2. If the frame is not allowed to execute scripts, setting location to
script should have no effect.
3. There is a potential discrepancy between applying parent width, which is
characteristic to block-level elements, and the declared element level in
that the level of a frame depends on an attribute.  This is unprecedented:
the elements in HTML have a fixed level by design.  Introducing a new
element should be reconsidered in view of that IMHO.
4. Percentage in height scales to the container's height, not to the initial
dimensions of the current element.  It is an error if the container's height
is left implicit or if the sum of percentages exceeds 100%.
5. The argument against SANDBOX is that the user could inject /SANDBOX.  The
argument against code attribute is that the user could inject a quote.
Aren't these similar enough to reconsider SANDBOX?  
It seems it is easier to sanitize quotes because the burden of quoting is on
the user.
Compare '<SANDBOX ><SANDBOX ></SANDBOX ></SANDBOX >' to '<SPAN
TITLE=""" ></SPAN >' that must be converted to '"<SPAN
TITLE="&quot;" ></SPAN >'.  The quoting required seems
straightforward.  I agree that using a data URL is simpler and cannot be
viewed as an obstacle to productivity since the author's text must be
processed anyway, so why not just encode it?  And it is more consistent with
contemporary technology.
HTH,
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Boris Zbarsky
Sent: Thursday, May 22, 2008 6:27 PM
To: Ian Hickson
Cc: public-webapi at w3.org; whatwg; HTMLWG
Subject: Re: [whatwg] The <iframe> element and sandboxing ideas

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