Closed Bug 1703674 Opened 8 months ago Closed 8 months ago

Revoking cam or mic permission doesn't always revoke both.

Categories

(Firefox :: Site Permissions, defect, P2)

defect

Tracking

()

VERIFIED FIXED
89 Branch
Tracking Status
firefox-esr78 --- wontfix
firefox87 --- wontfix
firefox88 --- wontfix
firefox89 --- verified

People

(Reporter: jib, Assigned: jib)

References

Details

(Whiteboard: [proton-door-hangers] [priority:2a])

Attachments

(2 files)

By design, a single click clears both camera and mic together, because it's safer, as users may forget to clear both otherwise.

But it turns out this only works when both camera and microphone are actively capturing. If only the camera or only the microphone is hot, or neither are hot, then users have to click ✖ individually for camera and microphone. This seems inconsistent, and could lead users to think they've revoked both when they didn't, which is a privacy issue, since the site can begin capturing again unprompted from the device that wasn't revoked.

STRs:

  1. Open https://mozilla.github.io/webrtc-landing/enumerate.html
  2. Click Start Both!, check ☑ Remember this decision and click Allow
  3. Click Stop!
  4. (Optional: Click either Start Mic! or Start Cam!, but not both)
  5. Click the 🎛️ in the URL bar to open the permissions drop-down and click the first ✖

Expected result:

  • Both camera and microphone "Allowed" permissions disappear

Actual result:

  • Only the microphone "Allowed" permission disappears. Camera is still there.

Discovered from failing test in bug 1697487:

TEST-UNEXPECTED-FAIL | browser/base/content/test/webrtc/browser_devices_get_user_media.js | no sharing indicator on the control center icon
Assignee: nobody → jib
Status: NEW → ASSIGNED
Priority: -- → P2
Whiteboard: [proton-door-hangers] [priority:2a]

I deliberately kept this behavior (same as in release) when refactoring the WebRTC permission clearing code in Bug 1695615. I think we should clear mic and camera together, but only if they're both being shared. A user may still want to clear persistent mic/camera permissions individually when there is currently no device shared. Removing both permissions in this case seems confusing.
For the "cold" case I don't think there is a privacy issue clearing these permissions individually.

Perhaps we could additionally clear both permissions if the user clears a "hot" permission? For example the site has mic, camera permissions, but only shares microphone. The user clears the active microphone => camera and mic is cleared.
Jib, what do you think about this approach?

Flags: needinfo?(jib)

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #0)

STRs:

  1. Open https://jan-ivar.github.io/dummy/gum_video_button_refresh.html

Did you mean to link a different test page? I don't see a "Start Both!" button on this one.

Did you mean to link a different test page? I don't see a "Start Both!" button on this one.

Yes, sorry. I've updated comment 0 with https://mozilla.github.io/webrtc-landing/enumerate.html

Flags: needinfo?(jib)
Attached image PermissionMix.png

(In reply to Paul Zühlcke [:pbz] from comment #2)

For the "cold" case I don't think there is a privacy issue clearing these permissions individually.

For privacy controls, I like to consider what sites may do rather than what they typically do.

So I consider the potential privacy issue here the same, since sites may resume capture at any point without user intervention.

I also worry it's going to confuse users more that it works one way some of the time and another at other times.

Perhaps we could additionally clear both permissions if the user clears a "hot" permission? For example the site has mic, camera permissions, but only shares microphone. The user clears the active microphone => camera and mic is cleared.
Jib, what do you think about this approach?

In this picture, do you think it should work differently based on which ✖ the user clicks?

That said, I'm sympathetic to users wanting to trim permissions granted a site, since there's no way today to only grant microphone if a site asks for both. So I think this leaves us with no perfect choices.

How about we allow discrete revoke only when neither is capturing?

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #5)

In this picture, do you think it should work differently based on which ✖ the user clicks?

You're right. Our UI doesn't make the sharing state clear enough and I worry not all users understand this mixed state. With the current UI clearing both permissions for the mixed state is more user friendly and safer.

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #6)

How about we allow discrete revoke only when neither is capturing?

This seems like a good compromise.

Patch updated. PTAL.

Attachment #9214229 - Attachment description: Bug 1703674 - Revoking cam or mic permission revokes both. r?pbz → Bug 1703674 - Revoking cam or mic permission revokes both if either is capturing. r?pbz
Pushed by jbruaroey@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/abc615e5574f
Revoking cam or mic permission revokes both if either is capturing. r=pbz
Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch

The patch landed in nightly and beta is affected.
:jib, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(jib)
Flags: needinfo?(jib)
Flags: qe-verify+

I tested this fix using Firefox 89.0b4 on Windows 10 x64, Ubuntu 18.04 x64 and macOS 10.15 and I found out two things:

  • If you click the "Stop!" button, then only one of the permissions is revoked.
  • If you don't click on "Stop!" button, then both permissions are revoked.
    Is this expected behaviour?

I also tested on permissions.site and the issue is not reproducing anymore.

Flags: needinfo?(jib)

Thanks Oana, yes that is expected, and the compromise reached in comment 6 between:

  1. protecting users from accidentally leaving camera or microphone hot (when both devices are hot), and
  2. allowing discrete revocation (when devices are stopped). Privacy benefit: allowing mic-only to a site that wants both.
Flags: needinfo?(jib)

According to comment 12 and comment 13 I will mark this bug as verified fixed.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.