Re: text/sandboxed-html

I spent some time this morning reading the paper by Wang et. al. upon which the 
proposal is based (link in Ian's original message on this thread).  I'm still 
thinking about my response, but my thoughts revolve around the extent to which 
the browser itself is becoming a trusted platform.  To the extent that plugins 
are an extension of the browser, then trust in the browser must extend to trust 
in the plugins as well.

I hope all this gets a really good review by security experts - the world is 
littered with cases of failed half-baked security measures, and the illusion of 
security could be worse than no security.  I'm not saying that applies here; the 
starting point seems to me to be sound, but one needs to be careful about taking 
a security measure from one context and deploying it in another.

#g
--


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

Received on Wednesday, 13 January 2010 18:47:24 UTC