Re: text/sandboxed-html

On Jan 12, 2010, at 6:29 PM, Boris Zbarsky wrote:

> On 1/12/10 9:21 PM, Maciej Stachowiak wrote:
>> That does seem like a potential improvement, so long as
>> "text/html-sandboxed" has the same effect of load failure in legacy  
>> UAs
>> (I haven't tested).
>
> In Gecko both types (text/html-sandboxed and text/sandboxed-html)  
> put up the helper app prompt.  In Opera they both show an error page  
> with a "download default" link.  In Safari both are treated as text/ 
> plain.  In Chrome they both seem to cause the content to be silently  
> ignored.
>
> The Gecko behavior and possibly the Safari/Opera behavior seems like  
> it might be a problem for this approach in the near term, no?
>
> I don't have IE to hand right this second, or anything more  
> interesting (amaya, lynx, etc).

Safari treats all otherwise unknown text/* types as text/plain.

I don't think it is a problem. My understanding is that a major goal  
for text/html-sandboxed is to protect against an attacker loading a  
resource that is only meant to be served sandboxed in a non-sandboxed  
context. Without some way to defend against that, it's not safe to  
serve untrusted content via http from your own origin for purposes of  
living in a sandboxed iframe. The key is that it has to fail when not  
sandboxed, it's not essential for there to be a good user experience  
for the failure.

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.

Regards,
Maciej