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 
* [`<iframe 

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 
 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