Re: [whatwg] The iframe element and sandboxing ideas
On Mon, 23 Apr 2007, Jonas Sicking wrote: There's a big difference to that and to what I'm proposing. With what's in bug 80713 you're still limited to a box that basically doesn't take part of the outer page at all. For example in the table example in my original post the headers of the table would not resize to fit the column sizes in the includeed table. Woah. That's far more radical. I have no idea how to do that. How would you make the parser not generate the implied elements and switch straight to the in table mode? How would you make the CSS model work with this? How would you define conformance for the document fragments? The parser questions here are interesting for sure, but I believe they could be solved. One way to solve the don't make the parser switch into mode X when it hits the iframe would be to teach the parser about include (or iframe seamless, or iframe include, or whatever it'll be called). That is pretty ugly though. One way to solve the fragment issue would be to say that the inner document always has to be a full document, and then use a fragment identifier to point to the contents of a table. The CSS model is simpler. XBL deals with exactly the same problem of combining multiple DOMs into a single flattened tree on which CSS is applied. I'm still intending to do some testing with this idea once I get more time. A lot of the implementation details have to be solved for XBL anyway. / Jonas
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: [whatwg] The iframe element and sandboxing ideas
On Wed, May 21, 2008 at 3:30 PM, Ian Hickson [EMAIL PROTECTED] wrote: * I've added a seamless= boolean attribute to iframe, which, if the content's active document's URI has the same origin as the container, causes the iframe to size vertically to the bounding box of the contents, and horizontally to the width of the container, and which causes the initial containing block of the contents to be treated as zero height. In addition, styles on the root element of the content must inherit from the iframe instead of being the initial values, and the style sheets that apply to the iframe must also apply to the contents. In addition, any time the browsing context navigates itself, the parent browsing context gets navigated instead. This looks awesome. So, the whole point of these is defining elements that are isolated from their surrounding context on different axes. Same origin iframes currently just give you CSS isolation. sandbox affords script isolation. seamless affords the ability to turn off the CSS isolation. Seems to me that we need a third property which controls event isolation. Currently events don't propagate in/out of iframes and event coordinates are all relative to the iframe's viewport (e.g. on mouse events). My first intuition was that seamless should also just propagate events and have mouse coordinate be relative to the parent browsing context. But I can think of cases where you would want to control the two separately. For example, if you are especially concerned about performance and don't want events in the parent browsing context to be handled by the iframe's contents. Ojan
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: [whatwg] The iframe element and sandboxing ideas
Legacy browsers will use @SRC which must be filtered. They will ignore the new content (whatever the attribute name will be) altogether so it need not be filtered. Fallback @SRC can contain a URL to an error page saying Sorry, not in your browser. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Thursday, May 22, 2008 2:21 PM To: Ian Hickson Cc: public-webapi@w3.org; whatwg; HTMLWG Subject: Re: [whatwg] 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.
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: [whatwg] The iframe element and sandboxing ideas
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=quot; /SPAN ' that must be converted to 'SPAN TITLE=quot;amp;quot;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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Boris Zbarsky Sent: Thursday, May 22, 2008 6:27 PM To: Ian Hickson Cc: public-webapi@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
Re: [whatwg] The iframe element and sandboxing ideas
Kristof Zelechovski wrote: 1. Nested browsing contexts in a sandboxed frame cannot be created dynamically but they can be defined by the inner markup. There was no mention of dynamically in Ian's proposal. My assumption was that cannot create browsing contexts meant just that. If it doesn't, the wording needs some changes. 2. If the frame is not allowed to execute scripts, setting location to script should have no effect. OK. Again, that was not clear in the original proposal. 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 It's not an error in CSS. Or are you suggesting a different algorithm? or if the sum of percentages exceeds 100%. Again, not a problem in CSS. Percentages of auto just get treated as auto. If you're suggesting a totally different algorithm, it needs a lot of fleshing out. 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? SANDBOX and the non-base64 attribute thing seem pretty similar in a lot of ways to me, except that the iframe (having a separate Window and such) might be easier to secure in existing implementations. -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