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

Disallow plug-ins in text/html-sandboxed? (was: Re: text/sandboxed-html)

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 13 Jan 2010 11:45:37 -0800
Message-ID: <7789133a1001131145o571bbdfale9d58c1678cd8ccd@mail.gmail.com>
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

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