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

RE: [whatwg] The <iframe> element and sandboxing ideas

From: Kristof Zelechovski <giecrilj@stegny.2a.pl>
Date: Thu, 22 May 2008 17:13:57 +0200
To: "'Martin Atkins'" <mart@degeneration.co.uk>, "'Ian Hickson'" <ian@hixie.ch>
Cc: <public-webapi@w3.org>, "'whatwg'" <whatwg@whatwg.org>, "'HTMLWG'" <public-html@w3.org>
Message-ID: <A9A38A658E0242C89F1E0E5DD5A137F9@POCZTOWIEC>

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

-----Original Message-----
From: whatwg-bounces@lists.whatwg.org
[mailto:whatwg-bounces@lists.whatwg.org] 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.
Received on Thursday, 22 May 2008 15:26:16 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:33 UTC