- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 13 Jan 2010 11:34:11 -0800
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Leonard Rosenthol <lrosenth@adobe.com>, Ian Hickson <ian@hixie.ch>, "public-html@w3.org WG" <public-html@w3.org>
On Wed, Jan 13, 2010 at 8:31 AM, Maciej Stachowiak <mjs@apple.com> wrote: > On Jan 13, 2010, at 8:14 AM, Leonard Rosenthol wrote: >> Hadn't read that, thanks for the pointer! Agreed, as long as plugins are >> explicitly disabled in a sandboxed page, then there is no need to extend any >> relevant APIs. That said, since the author of the page is the one >> determining the context (as per your black/white list comment), I would >> think they may wish to enable content that is plugin based but "trusted" to >> run in sandbox mode. So the addition of an "allow-plugins" keyword to the >> list of keywords for sandbox mode seems like a logical and reasonable >> extension. Do I need to file a formal "bug report" to see this included? > > If you'd like to have your idea get consideration, then yes, an appropriate > first step would be to file a bug in W3C bugzilla. My own opinion is that it > would be premature to add allow-plugins until we have worked out how plugins > might participate in enforcing the sandboxed iframe restrictions. I think > maybe plugin-futures would be the right forum to work out an API. In some sense, you can argue for including any directive in @sandbox because the author is in control of whether they use that directive. However, we don't want to include every directive because some of them are too complicated or have surprising behaviors or interactions. In this case, with currently existing plug-ins, the allow-plugins directive has a surprising interaction with the rest of the directives (in fact, it trumps them all). Once we have a way for plug-ins to participate in the sandbox security model, it would probably make sense to limit the plug-ins allowed by allow-plugins to those that understand @sandbox. Adam
Received on Wednesday, 13 January 2010 19:35:05 UTC