[whatwg] The <iframe> element and sandboxing ideas

[Mike Ter Louw]

Ian Hickson 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 is all HIGHLY EXPERIMENTAL. I am looking for feedback on the general 
> approaches taken.

The approach is good in that it leverages the existing semantics of 
<iframe> as a document / browsing context boundary, and enables tweaking 
of content capabilities using a small number of options.  The options 
are general enough that their effects should not be difficult for web 
authors to understand and put to use.

In the spec, would an example of seamless embedding of untrusted content 
be useful?

"
In this example, the site www.example.com seamlessly embeds untrusted, 
user-generated content such that the untrusted content can not 
instantiate plugins, execute scripts, submit forms, etc..  Note for 
seamless attribute to be used in conjunction with sandbox attribute, 
allow-same-origin keyword must be set and browsing context's active 
document must have the same origin as the nested browsing context.


<iframe src="www.example.com/getBlogComments.cgi?article=123"
         seamless sandbox="allow-same-origin"></iframe>
"

> 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.

There also does not seem to be a way for embedding untrusted content in 
a unique browsing context (i.e., different origin) that allows scripting 
and is seamless with the surrounding document.

The is a constraint placed on use of the seamless attribute: its effects 
are not applied when the <iframe> is of a different origin.  Is this to 
protect web authors from unintentional data leaks, or to prevent 
self-contradiction of the standard in some way?

To me, the exciting thing about content restrictions is the ability for 
a web author, or automated security tools, to define a policy for the 
user agent to enforce.  Toward this end the standards should allow great 
flexibility in how content restriction features can be used.  Maybe we 
can allow the choice to trade "total security lock-down" for "very good 
security, some documented implicit data flows, but greater usability"?

Here's another perspective: Is HTML 5 going to provide sufficient 
flexibility to enable web authors to safely embed untrusted content, or 
will future generations of web apps continue to rely on content 
filtering/sanitization techniques for restricting capabilities of 
untrusted content?

Just to be clear, I think the current proposal is a great improvement 
over current browser support for content restrictions and will enable a 
wave of desperately needed security enhancements on the web.

> This isn't very readable, I'll grant you. I'm thinking of introducing a 
> new attribute. I haven't worked out what to call it yet, but definitely 
> not "src", "source", "src2", "content", "value", or "data" -- maybe 
> "html" or "doc", though neither of those are great. This attribute would 
> take a string which would then be interpreted as the source document 
> markup of an HTML document, much like the above; it would override src="" 
> if it was present, allowing src="" to be used for legacy UAs:

This new attribute, along with some form of content encoding (e.g., data 
URI scheme), could be very important to the usefulness of the seamless 
and sandbox attributes in some applications.  Is the hold up just 
indecision about naming?  How about "text" or "document"?

Mike