- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 12 Jan 2010 18:41:23 -0800
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: Ian Hickson <ian@hixie.ch>, public-html@w3.org, public-web-security@w3.org
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
Received on Wednesday, 13 January 2010 02:41:57 UTC