Re: text/sandboxed-html

On Jan 13, 2010, at 6:38 AM, Leonard Rosenthol wrote:

> How would this work for content that references resources that  
> require the use of a plugin to view?
>
> How would a UA know if the specific plugin can run sandboxed or  
> not?  How would the UA communicate to the plugin that is should be  
> running sandboxed?

At present, content running in a sandboxed iframe cannot use plugins  
at all. See the sandboxed plugins browsing flag: <http://dev.w3.org/html5/spec/Overview.html#attr-iframe-sandbox 
 >.

You are correct that without changes to the plugin API to allow  
plugins to participate in the sandbox security model, there would be  
no safe way to allow plugins. If we come up with such a mechanism for  
popular plugin APIs, then we could consider whether to have an allow- 
plugins keyword for the sandbox attribute in addition to the existing  
ones like allow-forms, allow-scripting and allow-same-origin. I think  
it would only make sense to respect allow-plugins if allow-scripting  
is on, and to only let it enable plugins that know how to enforce the  
sandbox restrictions against their embedded plugin content.

> I would think that these problems would need to be addressed  
> otherwise the usefulness of "sandboxed" is significantly reduced  
> since it wouldn't actually mean anything in such contexts.

Right now its usefulness is only restricted in that you can't use  
plugins in a sandboxed context. However, we expect the main use cases  
for sandboxed iframes to be cases where site authors are already using  
blacklists or whitelists to filter out plugin content.

Regards,
Maciej


>
> Leonard Rosenthol
> Adobe Systems
>
> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org]  
> On Behalf Of Ian Hickson
> Sent: Tuesday, January 12, 2010 8:52 PM
> To: public-html@w3.org
> Cc: public-web-security@w3.org
> Subject: text/sandboxed-html
>
>
> In response to implementor feedback regarding the sandbox="" feature  
> of
> <iframe> in the WHATWG list [1], and based in part on a 2007 research
> paper from Microsoft [2], I have introduced a new MIME type for HTML
> (text/sandboxed-html) that is identical to text/html in every way  
> except
> one critical aspect: resources served with this MIME type are forced  
> into
> a unique security origin context.
>
> This feature can also be used with <iframe sandbox=""> to force the
> desired behaviour in legacy UAs -- fallback to either no sandbox is
> possible as before (for the case where sandbox="" is being used for
> defence-in-depth), and fallback to load failure is now possible by  
> serving
> the content with this type (for the case where legacy UAs are not  
> intended
> to be supported and sandbox="" is being used for first-line security).
>
> This is somewhat experimental, and so feedback (especially implementor
> feedback) regarding this proposal is encouraged.
>
> [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024732.html
> [2] http://research.microsoft.com/en-us/um/people/helenw/papers/sosp07MashupOS.pdf
>
> -- 
> Ian Hickson               U+1047E                ) 
> \._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _ 
> \  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'-- 
> (,_..'`-.;.'
>
>

Received on Wednesday, 13 January 2010 15:57:41 UTC