Re: text/sandboxed-html

On Tue, 12 Jan 2010, Roy T. Fielding wrote:
> On Jan 12, 2010, at 5:51 PM, Ian Hickson wrote:
> > 
> > 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.
> 
> I would prefer a media type of "text/html-sandboxed", since that places 
> the two types next to each other in a sorted list and allows easier 
> prefix-matching when desired.

Done.


On Wed, 13 Jan 2010, sird@rckc.at wrote:
>
> this is a great idea! but I think that legacy browsers will prompt a 
> <download file> dialog if they dont support it.

Right, that's the idea.


> why not putting the sandboxed URL inside the sandbox attribute? anyway, 
> it's just a suggestion, the new mime type is a great idea, now sandbox 
> makes sense!

The main reason for this feature is to prevent browsers from ever giving 
this file rights if it is accessed directly (without a sandbox). For 
example, if you host a file you know is hostile, so that you can use it 
like this:

   <iframe src="hostile" sandbox></iframe>

...then you're still letting your users be vulnerable if they just 
navigate straight to the "hostile" file.

However, if the "hostile" file is served as text/html-sandboxed, users 
wouldn't get attacked when they visit it, the file would just be 
downloaded/ignored/etc.


On Wed, 13 Jan 2010, sird@rckc.at wrote:
>
> btw, I have one question
> 
> <iframe sandbox-src="javascript:'in which context does this run?';">

Assuming you just mean:

   <iframe sandbox src="javascript:..."></iframe>

...then it runs in the same context as without the sandbox. What is 
sandboxed is then the return value (which is parsed as HTML, as usual 
for javascript: URLs used for navigating browsing contexts).


On Tue, 12 Jan 2010, Boris Zbarsky wrote:
> 
> My concern was whether sites would choose to use this if it meant that 
> <iframe sandbox> in a browser with no sandbox support would do weird 
> stuff with the content.  I guess doing weird stuff is certainly 
> preferable to it being treated as HTML by said browser.  ;)

Yeah, this is not a feature that is intended to be used exclusively, at 
least not when targetting legacy UAs. It's hard to use any new security 
feature when targetting legacy UAs. :-)


On Tue, 12 Jan 2010, Devdatta wrote:
> >
> > A site wishing to selectively use either <iframe sandbox> or nothing 
> > could feature-detect sandbox support before attempting to load the 
> > text/sandboxed-html resource.
> 
> That seems like an important functionality. How would sites be able to 
> detect support (short of user agent sniffing) ?

   if ('sandbox' in document.createElement('iframe')) {
     // sandboxing supported
   }

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 13 January 2010 03:29:48 UTC