W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2014

[whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)

From: James M. Greene <james.m.greene@gmail.com>
Date: Tue, 2 Dec 2014 09:46:50 -0600
Message-ID: <CALrbKZgHYecHfUShS-pyr9UsN6JUuSB36e3w8w0uHaOPRSjZuw@mail.gmail.com>
To: WHATWG <whatwg@lists.whatwg.org>
I have recently begun receiving issue reports about my JavaScript library,
ZeroClipboard, not working in some common developer websites such as
JSFiddle, CodePen, etc.  The common thread here is that the problematic
sites all host their snippets within sandboxed iframes... but ZeroClipboard
relies on a seamless integration of a small Flash object.

I eventually tracked this back to the iframe's `sandbox` attribute not
allowing plugins to be instantiated [1] due the always-on sandboxed plugin
browsing context [2].  When reviewing the HTML spec on both W3C and WHATWG,
I found that this is *supposedly* not 100% accurate as there is a
*suggestion* that a plugin can *somehow* identify itself as *secured* and
thus still be allowed to instantiate within a sandboxed iframe [3][4][5].
However, from practical experience, I also believe that none of today's
existing browser vendor implementations of iframe sandboxing take such a
concept into consideration.


>From [5]:

A plugin can be *secured* if it honors the semantics of the sandbox
> attribute.



        *For example, a secured plugin would prevent its contents from
> creating pop-up windows when the plugin is instantiated inside a sandboxed
> iframe.*




So, back to today's reality, my questions for clarification are:

 1. Is there any existing way or guidance for browser vendors on how to
confirm that a plugin can be "secured" and thus allowed to be instantiated
within a sandboxed iframe?

 2. Is there any existing way or guidance for library/plugin developers on
how to provide appropriate metadata to the browser in order to allow a
plugin to be considered "secured" and thus allowed to be instantiated
within a sandboxed iframe?

 3. Is this really just confusing/misleading text that may never actually
correlate to a real implementation?  I tend to think not as I did manage to
find some revision history that shows that the spec used to say that
plugins were outright prevented/disabled rather than "secured" within
iframe sandboxes.  However, I also have not found any related
discussion/guidance/etc. about how to move forward with "secured" plugins.


*References*
[1]:
http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/#granular-control-over-capabilities
[2]:
https://html.spec.whatwg.org/multipage/browsers.html#sandboxed-plugins-browsing-context-flag
[3]:
https://html.spec.whatwg.org/multipage/embedded-content.html#sandboxPluginEmbed
[4]:
https://html.spec.whatwg.org/multipage/embedded-content.html#sandboxPluginObject
[5]:
https://html.spec.whatwg.org/multipage/infrastructure.html#concept-plugin-secure


Sincerely,
    James Greene
Received on Tuesday, 2 December 2014 15:47:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:32 UTC