- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 13 Jan 2010 11:45:37 -0800
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Leonard Rosenthol <lrosenth@adobe.com>, Ian Hickson <ian@hixie.ch>, "public-html@w3.org" <public-html@w3.org>
On Wed, Jan 13, 2010 at 7:57 AM, Maciej Stachowiak <mjs@apple.com> wrote: > On Jan 13, 2010, at 6:38 AM, 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? > > At present, content running in a sandboxed iframe cannot use plugins at all. > See the sandboxed plugins browsing flag: > <http://dev.w3.org/html5/spec/Overview.html#attr-iframe-sandbox>. There are actually two things going on here, and we should be careful to make sure each works correctly: 1) Content loaded in an iframe with the @sandbox attribute. Here, Maciej is correct that plug-ins are disabled. 2) Content loaded with the media type text/html-sandboxed. Here, as described by Ian in his email, I think plug-ins are still allowed. We probably should disallow plug-ins in case (2) for the same reason we disallow them in case (1): Existing plug-ins likely won't respect the unique origin of the document. For example, I bet Gears would let a "text/html-sandboxed" document access the database for it's normal origin. Of course, once we have an API for plug-ins to understand these security restrictions, we can lift the prohibition in case (2) for plug-ins that understand the security model. Adam
Received on Wednesday, 13 January 2010 19:48:07 UTC