1609578 - Users shouldn't have to "Block" future permissions to back out of *changing* camera or mic

Status: RESOLVED FIXED

(Firefox :: Site Permissions, defect, P2)

Description

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

Attachment: WherebyBlocked.png

A page may call getUserMedia many times requesting different devices. Hitting "Deny" on any of these prompts temporarily blocks all further gUM permissions on that page. That seems overly severe.

A common use flow is in-content device selection where a user switches camera or microphone:

STR (requires 2 cameras, or use a phone): (Remove persistent permissions first):

1. Open https://whereby.com/room12345 and "Request permission"
2. Hit "Allow" in Firefox's gUM prompt
3. (You realize you wanted to use a different camera and) click the ⚙️ gear icon to change to the other camera (or flip ↻ front/back on phone)
4. Pick your other camera. A Firefox gUM prompt for that device appears.
5. (You change your mind and) hit "Deny" in this second gUM prompt

Expected result:

• The first camera is still chosen and working, and repeating steps 4-5 works (at least on a third camera).

Actual result:

• "Cam and mic are blocked" & the user is stuck until they refresh the page (see image).

Side-bug:

• As the image shows, the page-info drop-down has icons showing permission is blocked, but the text still says "Allowed Temporarily". The text appears to be a refresh bug, as the permission actually appears blocked. In fact, dragging the live tab into its own window causes the text to refresh to show "Blocked Temporarily").

Proposed solution

• Only add temporary blocks from "Deny" in first prompt (but ☑ Remember this decision + "Deny" still adds permanent block even in subsequent ones).
• The definition of "first" may need hashing out. I think it's:
  • The page has not been granted gUM previously in this session, or since the user last revoked permission manually in this session.

Comment 1

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

This is not a new bug, but rather a design flaw we've always had. This is a request for fine-tuning. I doubt many users hit "Deny" at that point, so I don't think it's P1.

Comment 2

[Karl Tomlinson (:karlt)]

The first mention of temporary deny for webrtc that I found was bug 1206232 comment 8.
The problem being solved was permission spamming, which may have been at least partially relevant due to permission requests starting to move keyboard focus and becoming harder to ignore.

I haven't found an explanation of why a permanent permission block was not considered a suitable solution. Permanent permissions were in existence, and considered easy to change. Disabling of permanent blocks for cross-origin subframes was proposed, but not carried out. Perhaps permanent blocks are in a better state now.

Bug 1206232 comment 98 pointed out the lack of a close (cancel) option.

Comment 4

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

I'm renaming the subject to more accurately reflect that today's prompt choices are "Block" and "Allow" (the problem is unchanged).

Comment 5

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

I propose this solution (let's call it the "some trust" solution) outlined by the options given to users in the gUM permission prompt:

1. Block and Allow on pages that don't have Temporarily Allowed permission to any device.
2. Not Now and Allow on pages that have Temporarily Allowed permission to at least one device (of any kind).

Block = Not Now + sets a Temporarily Blocked permission (as today)

Block + ☑ Remember this decision = Not Now + sets a Blocked permission (as today)
Not Now + ☑ Remember this decision = Not Now + sets a Temporarily Blocked permission (same as Block today).

Paul, WDYT?

Comment 6

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

On top of this, we could implement a 3-strikes approach like Safari does in bug 1771335.

Comment 7

[Paul Zühlcke [:pbz]]

Perhaps generally adopting a 3-strikes approach would make it simpler and both address this bug and bug 1771335? I'm worried that we'll make the permission model even more confusing if we add the mechanism you proposed in comment 5.

Comment 8

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

I worry I presented comment 5 poorly. I was trying to be thorough and cover all corner cases. Let me try again:

Comment 5 in a nutshell: replace "Block" with "Not Now" on pages with (Temporarily) Allowed permission to at least one device.

This directly addresses the bug in our trust model:

• Firefox today forces users to "Block" a page they're already trusting with primary devices when the page is asking for access to secondary ones. This isn't buying users any protection, and prevents them from backing out such prompts without breaking the page, which if anything promotes oversharing on their part to avoid this.

This would also fix bug 1771335 since presenters tend to be sharing camera and microphone already.

Perhaps generally adopting a 3-strikes approach would make it simpler

Unless "generally" means also apply this to initial prompts — which would weaken our prompt spamming mitigation for no reason — it doesn't seem simpler to me, since we'd still need to distinguish initial prompts, which is effectively what comment 5 does. I'd be happy to defer 3-strikes for now to simplify. We may not need it.

Comment 9

[Paul Zühlcke [:pbz]]

Thanks for reiterating! Not setting a temporary deny permission if there is already an allow permission sounds sensible to me. It should also be fairly straightforward to implement. We just have to make sure to not stop the currently shared device.

Comment 10

[Hannah Peuckmann]

Attachment: Bug 1609578 - No temporary block permission for trustworthy sites. r=pbz!

Comment 11

[Hannah Peuckmann]

Attachment: Bug 1609578 - Tests for Not now permission option. r=pbz!

Depends on D150723

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ef92e06cdc67
No temporary block permission for trustworthy sites. r=jib,pbz
https://hg.mozilla.org/integration/autoland/rev/853be5adca7d
Tests for Not now permission option. r=pbz

Comment 13

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/ef92e06cdc67
https://hg.mozilla.org/mozilla-central/rev/853be5adca7d