Closed
Bug 1389198
Opened 7 years ago
Closed 5 years ago
Support <iframe allow="camera; microphone"> in sandboxed iframes, or similar
Categories
(Core :: WebRTC: Audio/Video, enhancement, P2)
Core
WebRTC: Audio/Video
Tracking
()
RESOLVED
DUPLICATE
of bug 1497141
Tracking | Status | |
---|---|---|
firefox57 | --- | affected |
People
(Reporter: jib, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: stale-bug)
Sandboxed iframes need a long-term getUserMedia solution to let sites like stackoverflow, jsbin, codepen, jsfiddle etc. decide whether to let user-provided JavaScript code-snippets/bins/pens/fiddles request camera and microphone access from the (sub-)domain they operate in. Right now these sites can't do this without: 1. Effectively turning off sandbox protections. To illustrate: of the four, only https://jsfiddle.net/jib1/hut751ep/ works in Chrome/Firefox (*) today because they use iframe.sandbox = "allow-scripts allow-same-origin"; but it's an unsafe hack, as Firefox points out in web console: "An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can remove its sandboxing." 2. Exposing users to the potentially unsafe option of persistenting permissions across all pages of the domain, which is likely too broad, and at best adds confusion about who's asking. Related: we do a poor job informing users about whom they're trusting in these cases (bug 1369482). The rest of this issue is about #1. FYI Chrome Canary now warns: "[Deprecation] getUserMedia (camera) usage in cross-origin iframes is deprecated and will be disabled in M63, around December 2017. To continue to use this feature, it must be enabled by the embedding document using Feature Policy, e.g. <iframe allow="camera" ...>. See https://goo.gl/EuHzyv for more details." We suspect we'll similarly want to support allow="camera" and allow="microphone" properties on iframes, regardless of whether we end up otherwise adopting the larger Feature Policy spec. --- *) Side-note on current Firefox iframe behavior: We're similar to Chrome only for camera (we still allow mic), and this happened by accident in 53 (see bug 1367805).
Reporter | ||
Comment 1•7 years ago
|
||
Correction: JSBin works as well as JSFiddle, except for bug 1384800.
Reporter | ||
Updated•7 years ago
|
Rank: 21
Priority: -- → P1
Keywords: stale-bug
Comment 2•7 years ago
|
||
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
Reporter | ||
Comment 3•7 years ago
|
||
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #0) > FYI Chrome Canary now warns: Still works in Chrome (62) but in Canary (64) the warning has now changed to: "[Deprecation] VideoCapture permission has been blocked because of a Feature Policy applied to the current document. See https://goo.gl/EuHzyv for more details." I didn't check Chrome 63. We should look at this soon. Maybe in FF 60.
Rank: 21 → 19
Comment 4•6 years ago
|
||
IMO we should just implement Feature Policy to get this for all permissions, the right way. Feel free to add your need for this to https://github.com/mozilla/standards-positions/issues/24...
Reporter | ||
Updated•6 years ago
|
Summary: Support <iframe allow="camera" allow="microphone"> in sandboxed iframes, or similar → Support <iframe allow="camera; microphone"> in sandboxed iframes, or similar
Comment 5•5 years ago
|
||
Is there an ETA on when Firefox can support 'allow' attribute in sandbox iframes?
Reporter | ||
Comment 6•5 years ago
•
|
||
Feature policy is behind the pref dom.security.featurePolicy.enabled
which is enabled in Nightly only atm.
I believe it is scheduled to ride the 68 train.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•