Re: The iframe element and sandboxing ideas
proposal via typical ugly Ajax hacks, such as passing messages via postMessage (or the even uglier fragment identifer approach). Jon [image removed] Martin Atkins [EMAIL PROTECTED] Martin Atkins [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 05/22/08 05:20 AM [image removed] To [image removed] Ian Hickson [EMAIL PROTECTED] [image removed] cc [image removed] whatwg [EMAIL PROTECTED], HTMLWG [EMAIL PROTECTED], public-webapi@w3.org [image removed] Subject [image removed] Re: The iframe element and sandboxing ideas [image removed] [image removed] Ian Hickson wrote: Summary: * I've added a sandbox= attribute to iframe, which by default disables a number of features and takes a space-separated list of features to re-enable: [snip list] Unless I'm missing something, this attribute is useless in practice because legacy browsers will not impose the restrictions. This means that as long as legacy browsers exist (i.e. forever) server-side filtering must still be employed to duplicate the effects of the sandbox. One alternative would be to use a different element name so that fallback content can be provided for legacy browsers. In the short term, this is likely to be something like this: sandbox src=/comments/blah iframe src=/comments/blah?do-security-filtering=1/iframe /sandbox Once a large percentage of browsers support sandbox authors can start to be less accommodating with their fallback content, either by filtering out HTML tags entirely (which I'd assume is easier than just filtering out script) or at the extreme just setting the fallback content to be Your browser is not supported. This comment does not address seamless, which seems to be orthogonal and can thus be equally applied to both sandbox and iframe as currently specified. [image removed]
Re: The iframe element and sandboxing ideas
Ian Hickson wrote: Summary: * I've added a sandbox= attribute to iframe, which by default disables a number of features and takes a space-separated list of features to re-enable: [snip list] Unless I'm missing something, this attribute is useless in practice because legacy browsers will not impose the restrictions. This means that as long as legacy browsers exist (i.e. forever) server-side filtering must still be employed to duplicate the effects of the sandbox. One alternative would be to use a different element name so that fallback content can be provided for legacy browsers. In the short term, this is likely to be something like this: sandbox src=/comments/blah iframe src=/comments/blah?do-security-filtering=1/iframe /sandbox Once a large percentage of browsers support sandbox authors can start to be less accommodating with their fallback content, either by filtering out HTML tags entirely (which I'd assume is easier than just filtering out script) or at the extreme just setting the fallback content to be Your browser is not supported. This comment does not address seamless, which seems to be orthogonal and can thus be equally applied to both sandbox and iframe as currently specified.
Re: The iframe element and sandboxing ideas
FYI - We have had some discussion in and around the topic of better iframes at OpenAjax Alliance: http://www.openajax.org/runtime/wiki/Better_IFrames_Better_Sandboxing However, people see shortcomings with all proposals listed on that page. Our hope was that the HTML5 leaders would figure out a good approach, so I am glad to see that Ian has started discussion on this topic. Regarding Martin's comments, I think it is a correct objective to find a bridge between what exists with today's browsers and what we hope will exist in future browsers. The Ajax community usually needs to get the desired result in both legacy browsers and new browsers. If you need to sandbox in today's browsers, what the community tends to use one of two approaches: (1) require that sandboxed components be expressed in a restricted subset of HTML and/or JavaScript, such as Caja or ADSafe or the markup restrictions for portlets, (2) place the sandboxed components into an IFRAME whose domain or subdomain differs from everything else on the page (ie, leveraging the browser same-domain policy to achieve sandboxing). The problem with approach #1 is that some functionality (potentially critical) is disabled and developers have to in effect learn a new language. The problem with approach #2 is that isolation is an all-or-nothing proposition and there are shortcomings with IFRAMEs, such as lack of automatic content sizing. Ian's proposal below addresses these IFRAME shortcomings directly, which is great. If I had time to think extensively about this issue (which I don't), I would attempt to craft a proposal that used an approach where an Ajax library performed the mapping between what exists today (i.e., IFRAME) and what would exist in the future, where Ajax libraries could be eliminated once older browsers were put out of commission. My initial thought would be to put a 'sandbox' attribute on a DIV rather than on an IFRAME. That way, you end up with more powerful sandboxing, along the lines of what Doug Crockford proposed with his module tag. Newer browsers would deliver the sandboxing features that Ian is proposing below. For older browsers, someone could author an Ajax library that looked for DIV elements with a 'sandbox' attribute, and under the hood transformed the DOM such that it achieved sandboxing via IFRAMEs and implements the flexibility that Ian describes in his proposal via typical ugly Ajax hacks, such as passing messages via postMessage (or the even uglier fragment identifer approach). Jon Martin Atkins [EMAIL PROTECTED] n.co.uk To Sent by: Ian Hickson [EMAIL PROTECTED] public-webapi-req cc [EMAIL PROTECTED] whatwg [EMAIL PROTECTED], HTMLWG [EMAIL PROTECTED], public-webapi@w3.org 05/22/08 05:20 AM Subject Re: The iframe element and sandboxing ideas Ian Hickson wrote: Summary: * I've added a sandbox= attribute to iframe, which by default disables a number of features and takes a space-separated list of features to re-enable: [snip list] Unless I'm missing something, this attribute is useless in practice because legacy browsers will not impose the restrictions. This means that as long as legacy browsers exist (i.e. forever) server-side filtering must still be employed to duplicate the effects of the sandbox. One alternative would be to use a different element name so that fallback content can be provided for legacy browsers. In the short term, this is likely to be something like this: sandbox src=/comments/blah iframe src=/comments/blah?do-security-filtering=1/iframe /sandbox Once a large percentage of browsers support sandbox authors can start to be less accommodating with their fallback content, either by filtering out HTML tags entirely (which I'd assume is easier than just filtering out script) or at the extreme just setting the fallback content to be Your browser is not supported. This comment does not address seamless, which seems to be orthogonal and can thus
Re: 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
Re: The iframe element and sandboxing ideas
Ian Hickson wrote: Summary: * I've added a sandbox= attribute to iframe, which by default disables a number of features and takes a space-separated list of features to re-enable: ... Makes sense, Ian. Additionally to this, what about adding meta tag that disables or limits features of the page if it is running inside frame or iframe? Say something like this: html head meta name=allowed-context value=standalone-only / /head ... /html That may prevent some types of malicious uses. -- Andrew Fedoniouk. http://terrainformatica.com
