W3C home > Mailing lists > Public > public-html@w3.org > May 2008

Re: The <iframe> element and sandboxing ideas

From: Martin Atkins <mart@degeneration.co.uk>
Date: Thu, 22 May 2008 13:20:49 +0100
Message-ID: <48356521.5000206@degeneration.co.uk>
To: Ian Hickson <ian@hixie.ch>
CC: whatwg <whatwg@whatwg.org>, HTMLWG <public-html@w3.org>, public-webapi@w3.org

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.
Received on Thursday, 22 May 2008 12:21:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:17 GMT