- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 13 Jan 2010 11:24:01 -0800
- 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