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                                                 
             <mart@degeneratio                                             
             n.co.uk>                                                   To 
             Sent by:                  Ian Hickson <ian@hixie.ch>          
             public-webapi-req                                          cc 
             uest@w3.org               whatwg <whatwg@whatwg.org>, HTMLWG  
                                       <public-html@w3.org>,               
                                       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 be equally applied to both sandbox and iframe as currently
specified.