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

Status: VERIFIED FIXED

(Firefox :: Site Permissions, defect, P2)

Description

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: Bug 1703674 - Revoking cam or mic permission revokes both if either is capturing. r?pbz

Comment 2

[Paul Zühlcke [:pbz]]

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?

Comment 3

[Paul Zühlcke [:pbz]]

(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.

Comment 4

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: 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?

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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?

Comment 7

[Paul Zühlcke [:pbz]]

(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.

Comment 8

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Patch updated. PTAL.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/abc615e5574f
Revoking cam or mic permission revokes both if either is capturing. r=pbz

Comment 10

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/abc615e5574f

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 12

[Oana Botisan, Desktop QA]

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.

Comment 13

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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.

Comment 14

[Oana Botisan, Desktop QA]

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