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

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

From: Leonard Rosenthol <lrosenth@adobe.com>
Date: Wed, 13 Jan 2010 12:33:15 -0800
To: "'Adam Barth'" <w3c@adambarth.com>, Maciej Stachowiak <mjs@apple.com>
CC: Ian Hickson <ian@hixie.ch>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <D23D6B9E57D654429A9AB6918CACEAA97CA33AFF25@NAMBX02.corp.adobe.com>
>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.
>

Why only case #2 and not 1 as well?  As long as the plugins are able to declare their ability to participate in a sandboxed environment - why does it matter whether how that is defined?

It seems to me that the model for sandboxing needs to be consistent (in all aspects) regardless of how you specify it...

Leonard

-----Original Message-----
From: Adam Barth [mailto:w3c@adambarth.com] 
Sent: Wednesday, January 13, 2010 2:46 PM
To: Maciej Stachowiak
Cc: Leonard Rosenthol; Ian Hickson; public-html@w3.org
Subject: Disallow plug-ins in text/html-sandboxed? (was: Re: text/sandboxed-html)

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 20:33:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:57 GMT