W3C home > Mailing lists > Public > public-web-security@w3.org > January 2010

Re: text/sandboxed-html

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 12 Jan 2010 18:41:23 -0800
Cc: Ian Hickson <ian@hixie.ch>, public-html@w3.org, public-web-security@w3.org
Message-id: <993AB50C-E439-4BD4-B688-4EDC505D1FAD@apple.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>

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.

Received on Wednesday, 13 January 2010 02:41:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:17 UTC