Bugzilla

### Beta/Release Uplift Approval Request
* **User impact if declined**: If there's just one vulnerable semi-popular room-based WebRTC site out there that allows itself to be iframed AND throws its users into meetings using deep-links with persisted camera/mic on, without gating them on some "Join meeting" button, THEN the following exploit seems doable (so far the only vulnerable site we've identified, Jitsi, has added mitigations by joining users without camera/mic on in this case, but we haven't done an extensive search. Many other sites like appear.in typically use CSP to prevent iframing, and are not affected. But there may be product reasons why a site allows iframing. See comment 4).

The exploit is that any web site—even an iframed third-party banner ad, could embed the vulnerable site in a hidden iframe away from view, and specify an attacker's room in the URL. This could connect a victim's system to an attacker's room without their knowledge, potentially enabling the attacker to spy on the victim using camera or microphone or both. There might not be any hardware light indication if only microphone is used.

Victims vulnerable to this unprompted snooping are limited to users who have previously checked `☑ Remember this decision` in the permission prompt in a previous visit to the vulnerable site.

There's a potentially larger pool of vulnerable users who've never visited the vulnerable site, who may get a prompted, but be confused since the wrong domain is listed in the permission prompt, and accept it for that reason, but in my view that risk is less severe, since such an exploit would probably be spotted pretty quickly.
* **Is this code covered by automated tests?**: Yes
* **Has the fix been verified in Nightly?**: Yes
* **Needs manual test from QE?**: No
* **If yes, steps to reproduce**: 
* **List of other uplifts needed**: None
* **Risk to taking this patch**: Low
* **Why is the change risky/not risky? (and alternatives if risky)**: The risk is low because the patch is simple. It simply disables persistent permissions in cross-origin (third-party) iframes.

There's some backlash risk in the sense that legitimate end-users of WebRTC services embedded in iframes (e.g. Jitsi partners—not Jitsi itself) will now be prompted by Firefox for camera and microphone every time on desktop, and longer be able to persist their camera and mic permissions in Firefox for that site (this matches Firefox for Android today where we never persist camera and microphone). Fixing this requires more work in the future (see comment 11).
* **String changes made/needed**: None

### ESR Uplift Approval Request
* **If this is not a sec:{high,crit} bug, please state case for ESR consideration**: See above.
* **User impact if declined**: See above.
* **Fix Landed on Version**: 
* **Risk to taking this patch**: Low
* **Why is the change risky/not risky? (and alternatives if risky)**: See above.
* **String or UUID changes made by this patch**: None

### Beta/Release Uplift Approval Request
* **User impact if declined**: If there's just one vulnerable semi-popular room-based WebRTC site out there that allows itself to be iframed AND throws its users into meetings using deep-links with persisted camera/mic on, without gating them on some "Join meeting" button, THEN the following exploit seems doable (so far the only vulnerable site we've identified, Jitsi, has added mitigations by joining users without camera/mic on in this case, but we haven't done an extensive search. Many other sites like appear.in typically use CSP to prevent iframing, and are not affected. But there may be product reasons why a site allows iframing. See comment 4).

The exploit is that any web site—even an iframed third-party banner ad, could embed the vulnerable site in a hidden iframe away from view, and specify an attacker's room in the URL. This could connect a victim's system to an attacker's room without their knowledge, potentially enabling the attacker to spy on the victim using camera or microphone or both. There might not be any hardware light indication if only microphone is used.

Victims vulnerable to this unprompted snooping are limited to users who have previously checked `☑ Remember this decision` in the permission prompt in a previous visit to the vulnerable site.

There's a potentially larger pool of vulnerable users who've never visited the vulnerable site, who may get a prompted, but be confused since the wrong domain is listed in the permission prompt, and accept it for that reason, but in my view that risk is less severe, since such an exploit would probably be spotted pretty quickly.
* **Is this code covered by automated tests?**: Yes
* **Has the fix been verified in Nightly?**: Yes
* **Needs manual test from QE?**: No
* **If yes, steps to reproduce**: 
* **List of other uplifts needed**: None
* **Risk to taking this patch**: Low
* **Why is the change risky/not risky? (and alternatives if risky)**: The risk is low because the patch is simple. It simply disables persistent permissions in cross-origin (third-party) iframes.

There's some backlash risk in the sense that legitimate end-users of WebRTC services embedded in iframes (e.g. Jitsi partners—not Jitsi itself) will now be prompted by Firefox for camera and microphone every time on desktop, and no longer be able to persist their camera and mic permissions in Firefox for that site (this matches Firefox for Android today where we never persist camera and microphone). Fixing this requires more work in the future (see comment 11).
* **String changes made/needed**: None

### ESR Uplift Approval Request
* **If this is not a sec:{high,crit} bug, please state case for ESR consideration**: See above.
* **User impact if declined**: See above.
* **Fix Landed on Version**: 
* **Risk to taking this patch**: Low
* **Why is the change risky/not risky? (and alternatives if risky)**: See above.
* **String or UUID changes made by this patch**: None