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

Re: text/sandboxed-html

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 13 Jan 2010 11:24:01 -0800
Message-ID: <7789133a1001131124j22386a2bndcffcbcb92b1d0d1@mail.gmail.com>
To: Graham Klyne <GK@ninebynine.org>
Cc: Leonard Rosenthol <lrosenth@adobe.com>, Ian Hickson <ian@hixie.ch>, "public-html@w3.org" <public-html@w3.org>, "public-web-security@w3.org" <public-web-security@w3.org>
Indeed.  That's why we have the public-web-security list now.  :)

Adam


On Wed, Jan 13, 2010 at 9:00 AM, Graham Klyne <GK@ninebynine.org> wrote:
> I spent some time this morning reading the paper by Wang et. al. upon which
> the proposal is based (link in Ian's original message on this thread).  I'm
> still thinking about my response, but my thoughts revolve around the extent
> to which the browser itself is becoming a trusted platform.  To the extent
> that plugins are an extension of the browser, then trust in the browser must
> extend to trust in the plugins as well.
>
> I hope all this gets a really good review by security experts - the world is
> littered with cases of failed half-baked security measures, and the illusion
> of security could be worse than no security.  I'm not saying that applies
> here; the starting point seems to me to be sound, but one needs to be
> careful about taking a security measure from one context and deploying it in
> another.
>
> #g
> --
>
>
> Leonard Rosenthol wrote:
>>
>> How would this work for content that references resources that require the
>> use of a plugin to view?
>> How would a UA know if the specific plugin can run sandboxed or not?  How
>> would the UA communicate to the plugin that is should be running sandboxed?
>> I would think that these problems would need to be addressed otherwise the
>> usefulness of "sandboxed" is significantly reduced since it wouldn't
>> actually mean anything in such contexts.
>>
>> Leonard Rosenthol
>> Adobe Systems
>>
>> -----Original Message-----
>> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
>> Behalf Of Ian Hickson
>> Sent: Tuesday, January 12, 2010 8:52 PM
>> To: public-html@w3.org
>> Cc: public-web-security@w3.org
>> Subject: text/sandboxed-html
>>
>>
>> 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.
>>
>> This feature can also be used with <iframe sandbox=""> to force the
>> desired behaviour in legacy UAs -- fallback to either no sandbox is possible
>> as before (for the case where sandbox="" is being used for
>> defence-in-depth), and fallback to load failure is now possible by serving
>> the content with this type (for the case where legacy UAs are not intended
>> to be supported and sandbox="" is being used for first-line security).
>>
>> This is somewhat experimental, and so feedback (especially implementor
>> feedback) regarding this proposal is encouraged.
>>   [1]
>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024732.html
>> [2]
>> http://research.microsoft.com/en-us/um/people/helenw/papers/sosp07MashupOS.pdf
>>
>
>
>
Received on Wednesday, 13 January 2010 19:25:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:12 UTC