RE: text/sandboxed-html

Hadn't read that, thanks for the pointer!   Agreed, as long as plugins are explicitly disabled in a sandboxed page, then there is no need to extend any relevant APIs.  That said, since the author of the page is the one determining the context (as per your black/white list comment), I would think they may wish to enable content that is plugin based but "trusted" to run in sandbox mode.  So the addition of an "allow-plugins" keyword to the list of keywords for sandbox mode seems like a logical and reasonable extension.   Do I need to file a formal "bug report" to see this included?

Also, from what I can see about disabling of scripting, that applies to ALL scripts run in the context of the page.  This would include use the Canvas/2D API, the proposed 3D APIs, SVG-embedded DOM manipulation, etc.  Correct?  

Leonard

-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com] 
Sent: Wednesday, January 13, 2010 10:57 AM
To: Leonard Rosenthol
Cc: 'Ian Hickson'; public-html@w3.org; public-web-security@w3.org
Subject: 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 16:14:55 UTC