[Bug 9851] Allow plugins in @sandbox via "allow-plugins" option

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9851

Artur Adib <arturadib@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|LATER                       |

--- Comment #2 from Artur Adib <arturadib@gmail.com> 2010-11-04 14:24:41 UTC ---
Ian,

I'm sorry but I'm still not convinced.  

If such thing as a "sandbox-aware" plugin is ever designed, it should *always*
be allowed in a sandbox context (because, by definition, they respect the
sandbox restrictions).  So there is no need to talk about a white-list option
in this case.

The allow-plugins option I'm arguing for refers to *any* plugin, whether or not
it respects the sandbox restrictions.

Of course this introduces risks, but no more so than existing white-list
options.  For example, the HTML5 draft states explicitly:

"Warning! Setting both the *allow-scripts* and *allow-same-origin* keywords
together when the embedded page has the same origin as the page containing the
iframe allows the embedded page to simply remove the sandbox attribute."

Source:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox

That's exactly the same concern you raised against allow-plugins.  In my view,
the point of white-list options is to give authors *control* over a hierarchy
of safety levels.

The utility of the option "allow-plugins" is to offer protection against other
(non-plugin-based) types of attack, while allowing users to enjoy plugin-based
content.  (From our experience serving literally thousands of sites via iframe
content, most attacks come via Javascript.)

To emphasize the points above, perhaps the white-list option should be named
"allow-any-plugin" or "allow-unsafe-plugins"?

Thanks in advance for reconsidering this decision.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 4 November 2010 14:24:43 UTC