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:39:13 +0000
To: public-media-capture-logs@w3.org
Message-ID: <issue_comment.created-161337256-1449070751-sysbot+gh@w3.org>
> So if you don't have a sandbox attribute, modals (for instance) are 
allowed, but if you have a sandbox attribute with an empty value, 
modals are disallowed?


> Seems that people who use the sandbox attribute would care about 
restricting the capabilities of the iframe, so would be happy (?) to 
see usermedia starting out as default off, while people who don't use 
it would perhaps want the default (with no sandbox attribute) to be 
the status quo - that it's allowed on. Would that be the best of all 
possible worlds?

I think making getUserMedia (and likely, WebRTC) disabled by default 
and reenabled by opt-in in a sandboxed iframe would make sense. But I 
don't think it's sufficient or a "best of all possible" solution.

The problem with `<iframe sandbox>` is that it forces you into a very 
constrained iframe, and the list of constraints on this type of 
iframes can grow over time, so you have to keep adding "allow-foo" 
keywords if you were only interested in disabling a specific feature.

My understanding of the case we're trying to address is to make 
getUserMedia an independent toggle; i.e. an iframe could have or not 
have access to getUserMedia independently of whether that iframe is 

Looking at at the usual suspects for iframes, ads, I think most 
developers would NOT want ads to have access to getUserMedia, and most
 legitimates ads should NOT need it, but I don't think most developers
 would want or would be allowed to serve ads from `<iframe sandbox>`.

There seemed to have been a long discussion in [webappsec on the topic
 back in 
 that's probably exploring as well (or maybe more simply, get some 
input from webappsec on this?)

GitHub Notification of comment by dontcallmedom
Please view or discuss this issue at 
 using your GitHub account
Received on Wednesday, 2 December 2015 15:39:17 UTC

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