- 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
> 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? Yes. > 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 sandboxed. 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 February](https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/thread.html#msg225); 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 https://github.com/w3c/mediacapture-main/issues/268#issuecomment-161337256 using your GitHub account
Received on Wednesday, 2 December 2015 15:39:17 UTC