[whatwg] The <iframe> element and sandboxing ideas
ian at hixie.ch
Fri Feb 13 15:06:25 PST 2009
(Please pick one mailing list when replying, so as to reduce
On Thu, 22 May 2008, Boris Zbarsky wrote:
> 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
My summary was under-precise, my apologies. The spec itself seems to be
unambiguous here, though let me know if I missed anything.
> > 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
> the sandbox iframe? Does the script run? If so, in which browsing context?
If the "allow-scripts" flag is not set, uh, *fixes error in the spec*.
> > 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?
No need to assume. :-)
The spec text is at:
Please do let me know if that is suboptimal.
> > 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?
It's as if the style sheets were imported directly by the inner frame.
> > 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.
Indeed. If someone can come up with a way of making this work in legacy
UAs, I'd certainly be happy to change the spec to do that.
> > 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.
You would only have to escape two characters (" and &, and in fact only
the " is needed to be safe). Base64 would indeed be safer. (Right now it's
the only option, as I haven't introduced doc='' yet.) But escaping just
one character seems like a pretty low bar.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg