W3C home > Mailing lists > Public > public-media-capture-logs@w3.org > December 2015

Re: [mediacapture-main] Iframe sandboxing options for gUM

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
Message-ID: <issue_comment.created-161327557-1449069055-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:28 UTC