1697284 - Don't prompt web conference lurkers on unmute when they want to ask a question

Status: VERIFIED FIXED

(Firefox :: Site Permissions, enhancement, P2)

Description

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

+++ This bug was initially created as a clone of Bug #1693677 +++

Use case

Lurkers in medium-to-large meetings who spend most of their time facemuted and micmuted, only to unmute when called on to ask some question. They may lurk for nearly an hour to ask a question at the end.

Don't prompt them for permission if they granted permission at the start of the meeting.

"Unmute" here may refer to only faceunmute on some sites (Meet, WebEx), or both faceunmute and micunmute on others (MeetEcho?). This is because some web conferencing sites (the former group) asymmetrically stop camera on facemute to work around crbug 642785, but never stop the mic on micmute (so they can implement the "Are you speaking? you should unmute" feature).

Proposal

To address this use case directly, we might want to significantly increase the grace period considered in bug 1693677 to minutes not seconds, for as long as the page is not navigated (then trim it down to seconds on navigation).

This could manifest as a second pref setting, and some conditional code on top of bug 1693677.

Comment 1

[Johann Hofmann [:johannh]]

TBH I don't really understand the threat model behind not just granting for, say, 60 minutes immediately after user consent. Why do we need to make this so complicated (and in the process introduce a bunch of bugs and edge cases, I'm sure)

Comment 2

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

Change it from 50 seconds to 60 minutes? That would indeed be simpler, and would cover this use case better, e.g. when the user grants camera+mic in the lobby only, and enters (navigates into) the meeting completely muted, only to unmute 50 minutes later with a question.

Would this order of magnitude change in timeout change anyone's opinion on related decisions? E.g. that we decided not to clear grace periods on page refresh (even user page refresh)? The only way to clear them will be explicitly from the URL bar's permission dropdown, or by closing the tab.

Comment 3

[Martin Thomson [:mt:]]

I could tolerate a much longer grace period, but only if we kept the indicators on screen for that time. Is that the plan?

Comment 4

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

Attachment: CurrentPlan.png

It wasn't. Here's the current plan (there's only the "settings" 🎛️ indicator). But we could change that.

Comment 5

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

Attachment: WithGrayMediaIndicator.png

Here's what we could do. It's existing art for a similar state of a site holding onto a live track the site has decided to temporarily disable and could re-enable at any time.

The reason we stopped short of adding it, was that it kept begging the question about why we don't always leave it there for sites with persistent permission. But I think the answer to that is just don't.

The worry of overusing it is people can grow too used to seeing it, reducing its signal effect when it goes from gray to blinking red, which is a smaller transition than going from not being there to being there, diluting its value.

But if we go to 60 minutes, it may make sense to use it for grace periods only. The folks who persist are on their own. After all, my car's seatbelt alarm stops after a minute (don't ask me how I know).

Comment 6

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

Filed media indicator as bug 1697487 to keep things separate.

Comment 7

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

(In reply to Johann Hofmann [:johannh] from comment #1)

I don't really understand the threat model behind not just granting for, say, 60 minutes

I didn't want to leave this unanswered: Camera and microphone are used outside of web conferencing. The threat model is non-curated sites spying on users long after they've finished the related activity that prompted camera and microphone use in the first place. Activities may include seemingly temporal ones like taking a photo, scanning a bar code, or recording a voice greeting. Firefox has no reliable hook to know when these activities have ended, other than track.stop() and tab close.

To compound the problem, getUserMedia, for web compat reasons, does not require user gesture, so a malicious tab left open and visible may turn on the camera and microphone 59 minutes later to record them or their environment without them even being there.

Safari uses heuristics, which seem to boil down to a long timeout, but we have some indication they might use other signals too like periods without browser focus, laptop wake state, etc. to trigger re-prompt sooner. They also never extend permission past navigation or page refresh, like we're about to.

On the other end of the spectrum is Chrome, which does not appear to attempt mitigating this risk at all. We probably want to be closer to Safari.

So I think bug 1697487 is a good idea.

immediately after user consent.

Tying it to the start of permission would create unnecessary edge cases in long meetings: If they mute after 59 minutes, would they only get a 1 minute grace period? If they mute after 61 minutes, would they get no grace period, or does it reset to another 60 minutes? The amount of time they've been on seems irrelevant.

So tying it to the end of capture, and merely extending the grace period to 60 minutes from then, seems better.

Comment 8

[Johann Hofmann [:johannh]]

Thanks for describing it in more detail jib, maybe I should have said that I do understand what the threat is (though it's good to have it spelled out again), I just don't think that this poses a major risk to users. As you said, the site has to jump through several hoops (being the open, visible tab, though unfortunately not user gesture) and had already been trusted with camera access before. This seems very inconvenient for malicious sites and most would probably instead opt to avoid turning off the camera and distract from the indicators with deceptive UI.

Camera access is quite a powerful permission and while I don't agree with Chrome's TOFU approach we should to a certain extent also trust our users to make the right choice at least in their current temporal context, i.e. if I trust example.com with photographing me now I also trust it to not abuse camera access for the next hour. I would be surprised if any of our users knew about the extended protections we have in place, so it would be unwise for them to give out camera permission to a site that they think might try to spy on them later.

So I think bug 1697487 is a good idea.

I agree

Tying it to the start of permission would create unnecessary edge cases in long meetings: If they mute after 59 minutes, would they only get a 1 minute grace period? If they mute after 61 minutes, would they get no grace period, or does it reset to another 60 minutes? The amount of time they've been on seems irrelevant.

Ok, thanks, that makes sense to me, though I do have to say that outside of fixing this edge case this feels really inconvenient, because it

• creates a lot of additional complexity and overhead for development and maintenance, I'm already very unhappy with the quirks in the initial patches, e.g. https://phabricator.services.mozilla.com/D106279
• shows permission indicators at somewhat random times from a user's perspective (they're clearly connected to a user interaction when granted after the permission prompt was accepted)
• violates an essential piece of the privacy contract of web permissions (permissions are always controlled by the user) by making it possible for websites to control when a permission is set without any user consent or even interaction

The more I'm thinking about this the less I like that approach, to be honest. I feel like being re-prompted after 60 minutes when you haven't given permanent access might actually be a feature in some regards. :|

Comment 9

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

(In reply to Johann Hofmann [:johannh] from comment #8)

Ok, thanks, that makes sense to me, though I do have to say that outside of fixing this edge case this feels really inconvenient, because it

• creates a lot of additional complexity and overhead for development and maintenance, I'm already very unhappy with the quirks in the initial patches, e.g. https://phabricator.services.mozilla.com/D106279

Yes, but that's not the fault of the model, which is simpler than our current implementation. I believe the current implementation is a tradeoff based on incremental design decisions with better short-term risks. I believe we can increment and remove this complexity over time. But I also think bug 1693677 works and can be landed this cycle to start testing and feedback.

• shows permission indicators at somewhat random times from a user's perspective (they're clearly connected to a user interaction when granted after the permission prompt was accepted)
• violates an essential piece of the privacy contract of web permissions (permissions are always controlled by the user) by making it possible for websites to control when a permission is set without any user consent or even interaction

Specifically, the two observations above are wrong. The observable permission model is simpler:

1. Users see temporary permission starting at the point of grant, with a red blinking indicator and the words "Allowed Temporarily". Its duration is infinity while capture is active. Sites see getUserMedia calls succeed unprompted during this time (thanks to webrtcUI.activePerms).
2. When capture ends, users see the red blinking indicator turn gray (with bug 1697487 fixed), but the words "Allowed Temporarily" remain. Its duration is 60 minutes if capture never resumes. Sites see getUserMedia calls succeed unprompted during this time (thanks to SitePermissions.ALLOW, ... SCOPE_TEMPORARY, ... gracePeriodMs).

I feel like being re-prompted after 60 minutes when you haven't given permanent access might actually be a feature in some regards. :|

This I disagree with. I think the heuristics need to cover sustained usage, much like a screen blanker respects movie playback. It might even interfere with some security camera use cases.

Comment 10

[Romain Testard [:RT]]

Marking as P2. Per experience review we agreed to mark as P1 bugs only bugs that will block MR1.

Comment 11

[Timea Cernea [:tbabos][inactive]]

Consider the following scenario as well for fixing this issue:

After the user granted permission for devices A and B and started the webRTC meeting using device A, provide a longer grace period for device B or do not start the grace period countdown for device B while A is still in usage.
As it is now with the 50 seconds, if the user granted permission for device B in the setup screen (very common for webRTC pages) and decides 2 minutes into the meeting that a switch is needed to device B -> the permission panel is toggled again since we are over the grace period for device B.

Comment 12

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

(In reply to Timea Cernea [:tbabos] from comment #11)

As it is now with the 50 seconds, if the user granted permission for device B in the setup screen (very common for webRTC pages) and decides 2 minutes into the meeting that a switch is needed to device B -> the permission panel is toggled again since we are over the grace period for device B.

Yes, this is a good point and adds to the reasons why 50 seconds comes up short.

... provide a longer grace period for device B or do not start the grace period countdown for device B while A is still in usage.

This would be something we'd need to consider if we were to increase the grace period only slightly. But 60 minutes is an order of magnitude larger, and seems sufficient to adequately cover this scenario without special logic, I think.

Comment 13

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

Attachment: Bug 1697284 - Bump privacy.webrtc.deviceGracePeriodTimeoutMs to 60 minutes.

Depends on D111951

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/db7dd88c258e
Bump privacy.webrtc.deviceGracePeriodTimeoutMs to 60 minutes. r=pbz,johannh

Comment 15

[Cosmin Sabou [:CosminS]]

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

Comment 16

[Timea Cernea [:tbabos][inactive]]

NI? myself for QA verification.

Comment 17

[Timea Cernea [:tbabos][inactive]]

Verified-fixed on latest Firefox Nightly 89.0a1 (2021-04-18) on MacOS 10.15 and Windows 10. The grace period is now by default 3600000 ms (60 minutes).