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

Re: text/sandboxed-html

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 15 Jan 2010 11:23:03 -0800
Cc: Ian Hickson <ian@hixie.ch>, public-html@w3.org, public-web-security@w3.org
Message-id: <EC31BE79-C542-474C-A9FD-36C91BD5191E@apple.com>
To: Julian Reschke <julian.reschke@gmx.de>

On Jan 15, 2010, at 11:03 AM, Julian Reschke wrote:

> Maciej Stachowiak wrote:
>> On Jan 15, 2010, at 5:33 AM, Julian Reschke wrote:
>>> 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.
>>>> ...
>>> For symmetry, we should also have
>>> application/xhtml-sandboxed+xml
>>> right?
>> This actually would not have the desired behavior in legacy UAs,  
>> because many (well, at least WebKit-based ones) will recognize any  
>> MIME type ending in +xm as an XML type and will parse it as such.
>> ...
> Well, parsing it isn't a problem; right? Do they do more (sniff the  
> namespace?).

I'm not sure what you mean by "sniff the namespace". If content is  
served with an XML MIME type, we will attempt to render it. If there  
are elements in the XHTML namespace, they will be treated as such,  
regardless of the specific XML MIME type used. So for example you can  
serve XHTML as image/svg+xml and it will render fine. All XML MIME  
types are essentially equivalent to us.

Received on Friday, 15 January 2010 19:23:37 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:07 UTC