This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The white-list option "allow-plugins" for sandboxed iframes has been discussed before: http://lists.w3.org/Archives/Public/public-html/2010Jan/0675.html The option was dismissed on grounds that: (a) plugin APIs are not currently compliant with @sandbox restrictions, and (b) it's not clear authors want this option to go with iframes. The ensuing discussion in the thread focused on how to address (a), which I suppose was considered a pre-condition for the option. I have revived the discussion on the "allow-plugins" option after working with a concrete application that is being crippled by the lack of plugin support, arguing that the option is useful even if plugin APIs are not yet @sandbox-compliant: http://lists.w3.org/Archives/Public/public-html/2010Jun/0047.html Additional concerns were raised related to (a), but it was also agreed that the allow-plugins option and plugin API compliance can make progress in independently: http://lists.w3.org/Archives/Public/public-html/2010Jun/0059.html http://lists.w3.org/Archives/Public/public-html/2010Jun/0060.html http://lists.w3.org/Archives/Public/public-html/2010Jun/0068.html Since the present HTML5 specs already specify a "sandboxed plugins browsing context flag", it's a simple matter of allowing the flag to be manipulated with a white-list option. (Perhaps a temporary warning in the specs can be added to alert authors of possible lack of plugin API compliance).
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: We can't allow plugins to be used in sandboxed content until plugins are aware of the sandboxing mechanism, such that browsers can only enable plugins that respect the sandboxing. Right now, enabling plugins would be essentially equivalent to just removing the sandbox attribute (possibly literally -- there's no reason that I can see why a plugin couldn't just go ahead and remove the attribute and reload the iframe). Once the plugin APIs are sandbox-aware, it would make sense to provide such a feature.
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.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Allowing plugins that don't respect the sandbox is as pointless as enabling scripts and same-origin at the same time. The latter is only possible because you can enable scripts separate from enabling same-origin. However, there's no time that enabling unsafe plugins makes sense in a sandbox. You might as well just not have the sandbox. If plugins _were_ sandbox-aware, you might _still_ want to disable them, for the same reason you might want to disable scripts (i.e. because you don't want any active content). That's why it might make sense to add this once plugins are sandbox aware.