[whatwg] The <iframe> element and sandboxing ideas

On Tue, 22 Jul 2008, Frode B?rli wrote:
>
> I like the proposal of adding a "seamless" attribute to the iframe 
> element, though it should perhaps be added using CSS since it applies to 
> styling?

It doesn't seem CSS-specific; it would apply to any styling mechanism.


> I also want the following:
> 
> <span sandbox=1> </span>
> 
> This is because a typical Web 2.0 usage is to have a list of comments 
> with a thumbs up/thumbs down for each message. This requires more fine 
> grained control of what is user generated content and what is scripted 
> content.
> 
> The problem is 1: that the user can easily write </span> in his comment 
> and bypass the sandbox and 2: it is not backward compatible.
> 
> This is prevented by requiring anything inside a sandbox being entity 
> escaped:
> 
> <span sandbox=1> &lt;/span&gt; </span>
> 
> If the browser finds unescaped content inside a sandbox it should refuse 
> to display the page - thereby forcing the author to fix this 
> immediately.

I don't really follow. Why can't you have the non-user-created content 
outside the iframe and the user-created-content inside?


On Mon, 21 Jul 2008, James Ide wrote:
> 
> Overall, I'm seeing sandbox elements to be weak safety nets. AFAIK, 
> there is no way for a UA alone to perfectly determine what is author- or 
> developer-generated and what is user-submitted; user input must go 
> through some santizing process to be completely safe.

Agreed.


On Tue, 22 Jul 2008, James Ide wrote:
> 
> Thanks for the clarification. As mentioned previously by other poster, I 
> think this could work iff UAs can be passed a set of safe tags, 
> attributes, and whatnot (i.e., a whitelist), defaulting to the empty set 
> if no such set is specified. UAs can then unescape permitted elements, 
> filter out disallowed attributes, and then handle the code as normal.

Providing such a set would be really complex (e.g. you'd have to decide 
how to pass through URI schemes, CSS rules, DOM API limitations maybe, 
etc). I don't think that's simple enough for a securit feature.


There were other e-mails on this thread, but they repeated points made in 
earlier threads that I replied to earlier today, so I didn't reply here. 
Please let me know if I missed some important point that should affect the 
spec in some way.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 17 February 2009 17:47:31 UTC