- From: James M. Greene <james.m.greene@gmail.com>
- Date: Tue, 2 Dec 2014 09:46:50 -0600
- 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