[whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)
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
Re: [whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)
On 12/2/14, 7:46 AM, James M. Greene wrote: 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? As far as I know, there is not. For Gecko there definitely is not. 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? Again, as far as I know there is not. 3. Is this really just confusing/misleading text that may never actually correlate to a real implementation? The text is intended to allow people to develop such systems if they want to. I don't think any current UAs particularly want to. Note that making sure something with the API surface of Flash is secured would be quite an undertaking... -Boris
Re: [whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)
OK, those answers are all about what I expected, particularly the note about securing the API surface of Flash. So, it sounds like sandboxed iframes will probably *never* support plugin instantiation -- even if such a plugin were hosted on the same origin as both the iframe page *and* top-level page. This mostly makes sense to me as you would only infrequently want to sandbox an iframe of your own site, though it does seem to present a gap as, if I *did* want to sandbox an iframe of my own site, it would probably be to do something more like preventing top-level navigation and/or popups rather than to prevent the instantiation of personally-built plugins... but I cannot achieve the former without implicitly suffering the latter. Not critical but slightly frustrating until the HTML Clipboard API (for which ZeroClipboard is the best interim solution) eventually gets polished and implemented more widely. Sincerely, James Greene On Tue, Dec 2, 2014 at 9:49 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/2/14, 7:46 AM, James M. Greene wrote: 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? As far as I know, there is not. For Gecko there definitely is not. 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? Again, as far as I know there is not. 3. Is this really just confusing/misleading text that may never actually correlate to a real implementation? The text is intended to allow people to develop such systems if they want to. I don't think any current UAs particularly want to. Note that making sure something with the API surface of Flash is secured would be quite an undertaking... -Boris
Re: [whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)
On 12/2/14, 8:01 AM, James M. Greene wrote: So, it sounds like sandboxed iframes will probably /never/ support plugin instantiation -- even if such a plugin were hosted on the same origin as both the iframe page /and/ top-level page. For Gecko it depends. For example, we plan to ship a PDF viewer plugin (based on pdf.js) that we may decide to allow in sandboxed iframes. Will need to audit it a bit. For third-party plug-ins, I suspect the never answer is a good assumption for now. This mostly makes sense to me as you would only infrequently want to sandbox an iframe of your own site Actually, sandboxing iframes of your own site is one of the main sandbox use cases: it allows limited user upload of content without creating security holes, in theory. -Boris
Re: [whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)
Actually, sandboxing iframes of your own site is one of the main sandbox use cases: ... Oh, hehe. ... it allows limited user upload of content without creating security holes, in theory. Then let us hope that such content creation/collection/uploading doesn't require the use of Flash/Java/etc., eh? :) Sincerely, James Greene On Tue, Dec 2, 2014 at 11:04 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/2/14, 8:01 AM, James M. Greene wrote: So, it sounds like sandboxed iframes will probably /never/ support plugin instantiation -- even if such a plugin were hosted on the same origin as both the iframe page /and/ top-level page. For Gecko it depends. For example, we plan to ship a PDF viewer plugin (based on pdf.js) that we may decide to allow in sandboxed iframes. Will need to audit it a bit. For third-party plug-ins, I suspect the never answer is a good assumption for now. This mostly makes sense to me as you would only infrequently want to sandbox an iframe of your own site Actually, sandboxing iframes of your own site is one of the main sandbox use cases: it allows limited user upload of content without creating security holes, in theory. -Boris
