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)

enhancement

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).
Correction: JSBin works as well as JSFiddle, except for bug 1384800.
Rank: 21
Priority: -- → P1
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
(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
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...
Summary: Support <iframe allow="camera" allow="microphone"> in sandboxed iframes, or similar → Support <iframe allow="camera; microphone"> in sandboxed iframes, or similar
Blocks: 1473321
Is there an ETA on when Firefox can support 'allow' attribute in sandbox iframes?

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.