- From: Dominique Hazael-Massieux via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Dec 2015 15:10:56 +0000
- To: public-media-capture-logs@w3.org
there are two types of sandboxing: * [`<iframe sandbox="allow-foo allow-bar">`](https://html.spec.whatwg.org/multipage/embedded-content.html#attr-iframe-sandbox) * [`<iframe allow-foo>`](https://html.spec.whatwg.org/multipage/embedded-content.html#attr-iframe-allowfullscreen) The first one has for effect that by default, you get an iframe that has many features cut-off, and get specific features re-enabled via the keywords `allow-foo` and `allow-bar` in my example. The currently recognized features are: `allow-forms, allow-modals, allow-pointer-lock, allow-popups, allow-popups-to-escape-sandbox, allow-same-origin, allow-scripts, and allow-top-navigation`. The second one has only been defined for fullscreen at the moment; in that model, fullscreen is disabled by default in any iframe, and can only be enabled specifically by adding that attribute. While I think it would be useful to think about both getUserMedia and WebRTC impact on the sandbox attribute, I think in this particular case, we're really thinking about the second model, and whether to take the lenient backwards-compatible appraoch (which would require a `disallowusermedia` attribute) or to take the more stringent likely not bw-compatible approach, with an `allowusermedia` attribute. I personally think the latter is cleaner, but we would need visibility on the deployment reality to determine if that's still an option. -- GitHub Notification of comment by dontcallmedom Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/268#issuecomment-161327557 using your GitHub account
Received on Wednesday, 2 December 2015 15:10:58 UTC