No way to grant persistent camera permission

REOPENED
Assigned to

Status

()

Firefox for Android
Audio/Video
P2
normal
REOPENED
2 years ago
2 years ago

People

(Reporter: gcp, Assigned: mchiang, NeedInfo)

Tracking

({feature, uiwanted, ux-control})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

2 years ago
There's no equivalent to "Always Allow" in the Android gUM dialog.

If you're implementing this, take a look at this bug and its dependencies: https://bugzilla.mozilla.org/show_bug.cgi?id=1212501
Priority: -- → P2
Munro is working on this one.
Thanks!
Assignee: nobody → mchiang
Keywords: uiwanted, ux-control
(Assignee)

Comment 2

2 years ago
Per jib's suggestion in mail, I will leave the constraint violation issue to be handled in bug 1212501.
The patch I will submit contains these fixes:
1) implement the permission parts and achieve parity with desktop
2) Fix the bug 1145525 in fennec. Since most android devices have two cameras, bug 1145525 is easily reproduced on fennec. I solve this problem via putting more information in permission manager.
(Assignee)

Comment 3

2 years ago
Created attachment 8740807 [details] [diff] [review]
WIP-01-grant-persistent-camera-microphone-permission.patch
Attachment #8740807 - Flags: review?(jib)
Attachment #8740807 - Flags: review?(gpascutto)
Comment on attachment 8740807 [details] [diff] [review]
WIP-01-grant-persistent-camera-microphone-permission.patch

Review of attachment 8740807 [details] [diff] [review]:
-----------------------------------------------------------------

Works well, but I see some problems.

1. The checkbox defaults to ON. It should probably default to OFF
   to not vastly alter the existing experience, and to match desktop.

2. The permission appears remembered per URL. Should be per origin.

3. Once I've granted or blocked permission permanently, how can I remove it?

Lastly, someone who knows the android doorhanger setup should probably look at the code as well, in case there are any gotchas I'm not familiar with it.
Attachment #8740807 - Flags: review?(jib)
Attachment #8740807 - Flags: review-
Attachment #8740807 - Flags: feedback?(s.kaspari)
(Assignee)

Comment 5

2 years ago
(In reply to Jan-Ivar Bruaroey [:jib] from comment #4)
> Comment on attachment 8740807 [details] [diff] [review]
> WIP-01-grant-persistent-camera-microphone-permission.patch
> 
> Review of attachment 8740807 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Works well, but I see some problems.
> 
> 1. The checkbox defaults to ON. It should probably default to OFF
>    to not vastly alter the existing experience, and to match desktop.
[Munro] OK, I will change this to default off

>
> 2. The permission appears remembered per URL. Should be per origin.
> 
[Munro] May I know if there is any spec requiring this? (grant permission to the origin instead of URL). For example, there are several different samples in the webpage https://github.com/webrtc/samples, all of them share the same origin (webrtc.github.io), users may want to grant different cameras & microphones permission to different sample.

> 3. Once I've granted or blocked permission permanently, how can I remove it?
[Munro] User can remove the granted or blocked persistent permission by clearing the browser data in Settings / Apps / Firefox / Storage. On Desktop, user can remove a granted persistent permission via an icon, but he needs to clear the cache to remove a blocked persistent permission.

> 
> Lastly, someone who knows the android doorhanger setup should probably look
> at the code as well, in case there are any gotchas I'm not familiar with it.
[Munro] I will try to find someone who is familiar with the doorhanger to help review my code.
(In reply to Munro Chiang [:munro_chiang] from comment #5)
> [Munro] May I know if there is any spec requiring this? (grant permission to
> the origin instead of URL).

See originIdentifier in http://w3c.github.io/mediacapture-main/archives/20160222/getusermedia.html#dom-mediadevices-getusermedia

> > 3. Once I've granted or blocked permission permanently, how can I remove it?
> [Munro] User can remove the granted or blocked persistent permission by
> clearing the browser data in Settings / Apps / Firefox / Storage.

In Android Settings? Doesn't that nuke everything? If so, then that seems quite poor. Maybe enough to block this feature.

> On Desktop, user can remove a granted persistent permission via an icon, but he
> needs to clear the cache to remove a blocked persistent permission.

Both granted and blocked permissions can be removed in the Page Info dropdown in desktop. Is anything similar planned in Fennec?

> [Munro] I will try to find someone who is familiar with the doorhanger to
> help review my code.

I asked sebastian for feedback in comment 4, as he seems around and has touched the code.
Flags: needinfo?(mreavy)

Updated

2 years ago
Keywords: feature
(Assignee)

Comment 7

2 years ago
(In reply to Jan-Ivar Bruaroey [:jib] from comment #6)
> (In reply to Munro Chiang [:munro_chiang] from comment #5)
> > [Munro] May I know if there is any spec requiring this? (grant permission to
> > the origin instead of URL).
> 
> See originIdentifier in
> http://w3c.github.io/mediacapture-main/archives/20160222/getusermedia.
> html#dom-mediadevices-getusermedia
> 
> > > 3. Once I've granted or blocked permission permanently, how can I remove it?
> > [Munro] User can remove the granted or blocked persistent permission by
> > clearing the browser data in Settings / Apps / Firefox / Storage.
> 
> In Android Settings? Doesn't that nuke everything? If so, then that seems
> quite poor. Maybe enough to block this feature.
> 
> > On Desktop, user can remove a granted persistent permission via an icon, but he
> > needs to clear the cache to remove a blocked persistent permission.
> 
> Both granted and blocked permissions can be removed in the Page Info
> dropdown in desktop. Is anything similar planned in Fennec?
> 
> > [Munro] I will try to find someone who is familiar with the doorhanger to
> > help review my code.
> 
> I asked sebastian for feedback in comment 4, as he seems around and has
> touched the code.

Update the status.
I have changed my patch to grant permission to the origin instead of URL.

For the remaining efforts, I will consult Sebastian for advice.
1) set the checkbox to default off
2) create a UI for user to revoke the granted / blocked persistent permission.
Comment on attachment 8740807 [details] [diff] [review]
WIP-01-grant-persistent-camera-microphone-permission.patch

We just spoke on IRC. The summary is:

1) It actually seems like it's not possible to set the default state for the checkbox. However this is fairly easy to fix. Let's file a bug for it.
2) We don't have any of that. :antlam should be able to help with that (maybe even :barbara for priorization if this needs resources from the fennec team)

Please make sure that this still works with Android 6 runtime permissions (I can do that too if you don't have a 6+ device). Somewhere in this code we ask for the Android permission if we need it. The Scenario I’m thinking of:
* User accepts camera permission for website A permanently.
* User goes to Android’s settings and revokes camera permission from Firefox.
* User opens Firefox and goes to website A: We shouldn’t show the doorhanger but we should prompt for the runtime permission.
Attachment #8740807 - Flags: feedback?(s.kaspari) → feedback+
(Reporter)

Comment 9

2 years ago
Comment on attachment 8740807 [details] [diff] [review]
WIP-01-grant-persistent-camera-microphone-permission.patch

Review of attachment 8740807 [details] [diff] [review]:
-----------------------------------------------------------------

r- for reasons jib already pointed out.

::: mobile/android/chrome/content/WebrtcUI.js
@@ +157,5 @@
>            allowedDevices.AppendElement(audioDevices[audioId]);
> +          if (checked) {
> +            let perms = Services.perms;
> +            perms.add(aUri, "microphone", perms.ALLOW_ACTION, perms.EXPIRE_NEVER);
> +            perms.add(aUri, "microphone" + aUri.path + audioDevices[audioId].name, perms.ALLOW_ACTION, perms.EXPIRE_NEVER);

This doesn't work. See for example bug 1177242 and the bugs it spawned. Permissions are granted per origin (as jib pointed out).

We want to grant as little persistent permissions as possible, see https://bugzilla.mozilla.org/show_bug.cgi?id=1177242#c8 for the reasoning why. So default=off definitely.
Attachment #8740807 - Flags: review?(gpascutto) → review-
I agree with jib and gcp.  We need to be very careful how we handle the granting and revoking of permissions.  Given the sensitivity of this, we should get a privacy review before landing to make sure our solution is in keeping with our policies, etc.  We can reach out to dveditz and/or rbarnes for help with a privacy review.
Flags: needinfo?(mreavy)
(Assignee)

Updated

2 years ago
Depends on: 1264835
(Assignee)

Comment 11

2 years ago
Created attachment 8741612 [details]
Screenshot_20160415-110508.png
(Assignee)

Comment 12

2 years ago
Created attachment 8741613 [details]
Screenshot_20160415-110636.png
(Assignee)

Comment 13

2 years ago
antlam, may I have your opinion about the UI for user to 1) grant / block persistent permission 2) revoke the granted & blocked permission?

For item 1, my proposal is to add a checkbox (default off) in the doorhanger (Attachment 8741612 [details])
For item 2, my proposal is to utilize the notification bar. When user press the notification bar, we will show the doorhanger for user to modify their decision. (Attachment 8741613 [details])
Flags: needinfo?(alam)

Updated

2 years ago
Flags: needinfo?(alam)
(In reply to Munro Mengjue Chiang [:mchiang] from comment #13)
> antlam, may I have your opinion about the UI for user to 1) grant / block
> persistent permission 2) revoke the granted & blocked permission?
> 
> For item 1, my proposal is to add a checkbox (default off) in the doorhanger
> (Attachment 8741612 [details])
> For item 2, my proposal is to utilize the notification bar. When user press
> the notification bar, we will show the doorhanger for user to modify their
> decision. (Attachment 8741613 [details])

Hey :mchiang,

I'm going to take a step back here and loop in Barbara to get her Product experience. I'd like to understand why we're doing this work and what the goal is here.

It's a bit unclear to me that we actually need this change and I can't seem to find that context in this bug. 

Let's get Barbara's thoughts before we move forward :)
Flags: needinfo?(bbermes)
(Assignee)

Comment 15

2 years ago
(In reply to Anthony Lam (:antlam) from comment #14)
> (In reply to Munro Mengjue Chiang [:mchiang] from comment #13)
> > antlam, may I have your opinion about the UI for user to 1) grant / block
> > persistent permission 2) revoke the granted & blocked permission?
> > 
> > For item 1, my proposal is to add a checkbox (default off) in the doorhanger
> > (Attachment 8741612 [details])
> > For item 2, my proposal is to utilize the notification bar. When user press
> > the notification bar, we will show the doorhanger for user to modify their
> > decision. (Attachment 8741613 [details])
> 
> Hey :mchiang,
> 
> I'm going to take a step back here and loop in Barbara to get her Product
> experience. I'd like to understand why we're doing this work and what the
> goal is here.
> 
> It's a bit unclear to me that we actually need this change and I can't seem
> to find that context in this bug. 
> 
> Let's get Barbara's thoughts before we move forward :)

This bug is about a feature which is already supported on desktop Firefox.
When you visit a webpage using the web API getusermedia, e.g., https://webrtc.github.io/samples/src/content/getusermedia/record/, browser will prompt a dialog to ask for permission. On desktop Firefox, user can choose "Always Share" and then browser will grant permission automatically hereafter for the same website. On Android Firefox, user need to grant the permission every time she visits the website, which can be bothering for some heavy user.
Do we have any concrete user complaints or are we guessing here that this is blocking more engagement? On that note, do we have any telemetry on Desktop that tells us how many users have this on permanently?

If privacy/policy is ok with this change (assuming they are since it's available for Desktop, but please verify), this could be done. 

Is this something somebody in this bug, other than the Android frontend team, can do?

Looping in Sebastian as he's done a lot around permissions. Any concerns from an eng perspective?
Flags: needinfo?(s.kaspari)
Flags: needinfo?(mbest)
Flags: needinfo?(bbermes)
This setting is per site, so there is no yes/no telemetry answer on who has it on. The choice is also buried one level lower in UX than the default choice (i.e. you have to find it), which should be taken into account when comparing numbers.

We all have apps and sites we use almost every day that we've decided we trust. Not being able to inform our browser of this trust, is a problem of usability.

Consider that the major competing mobile browser supports IMPLICIT persistent permission, as the ONLY option. In other words, the optional functionality asked for in this bug is the SOLE mandatory functionality offered on the competing browser.

Comment 18

2 years ago
(In reply to Munro Mengjue Chiang [:mchiang] from comment #7)

> 2) create a UI for user to revoke the granted / blocked persistent
> permission.

(In reply to Sebastian Kaspari (:sebastian) from comment #8)

> 2) We don't have any of that. :antlam should be able to help with that
> (maybe even :barbara for priorization if this needs resources from the
> fennec team)

We do already have a UI for this, it's the "Edit site settings" item in the site identity popup. Although it's not great, this is currently the UI we have in place for revoking site permissions (e.g. geolocation).

While we do need to make sure things aren't totally broken if users revoke runtime permissions, this bug isn't about runtime permissions.

To fix this bug, we can utilize the checkbox functionality that we already support in similar permissions notifications, and then make sure that these permissions also appear in the site settings dialog.

Improving the site settings dialog (and our site permissions UI overall) is a separate issue that should be handled in different bugs.

Comment 19

2 years ago
(In reply to :Margaret Leibovic from comment #18)

> Improving the site settings dialog (and our site permissions UI overall) is
> a separate issue that should be handled in different bugs.

That being said, as Maire pointed out above, camera/microphone permissions are more sensitive than other permissions we grant, so we may want to block on a better permissions UI before we actually allow permanent access.
Chatted about this with Harly and Munro over email.

It seems like the UX here isn't the hardest thing to figure out. If we can have an easy way to both "enable-always" AND "revoke" the permission.

But the model on Desktop is very different to the Mobile context. 

On Mobile, having a site have permanent access to the camera and speaker could create a host of issues. But it's also just very scary. If visiting a URL was all I needed to turn on my speaker, mic, and camera, I'd be really cautious of when and where I visit that URL. 

So I think having an extra "confirmation" step in this process isn't a huge price to pay. Especially given that our doorhangers are front and center and easy to interact with (comparatively).
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(s.kaspari)
Flags: needinfo?(mbest)
Resolution: --- → WONTFIX
Anthony, I hesitate to disagree in public, but your stated reasons doesn't seem well informed, and your action unilateral. Have you use Android apps? Their permission model is inherently persistent, including for cameras and mic. Why is visiting a familiar URL more "scary" than opening an app? If web apps are going to succeed, then we need to remove perceived artificial barriers like this.

About "mobile context", have you used Chrome for Android? It grants sites *permanent access* if you share a camera or mic with a site just once. While I agree we want to offer users more choice than that, lets offer that choice inside our browser, rather than mandate our values on users, which just reduces users to have to choice between "Firefox or Chrome", which is not what we want I don't think.

While there seem to be obstacles to implementing this right now, lets not say never.
Flags: needinfo?(mreavy)
Flags: needinfo?(alam)
Jan-Ivar makes several good points -- the most important IMO being, "While there seem to be obstacles to implementing this right now, lets not say never."  

I can understand that this is not a high priority bug to solve on Android today, but as mobile WebRTC usage increases (very likely late this year and into next year), I'm concerned (as jib points out) that not having this choice for users will drive users away from Firefox and toward other mobile browsers that offer less hassle and/or more choices.  

So I ask that we not kill this bug but rather set a target date (or target release or target sprint) to tackle this problem and solicit input and feedback from the privacy folks and WebRTC team members (like jib and myself) during the design phase.  I think a good target date would be within the next 6 months (give or take).

Thanks for all the comments and interest in improving the experience of WebRTC on mobile.
Flags: needinfo?(mreavy)

Updated

2 years ago
Flags: needinfo?(alam)
Thanks for your very helpful input :Jib, we'll look at revisiting this down the line. 

But, I never said "never" - just not right now.
Anthony -- Thanks for understanding.  I think both jib and I thought "never" when we saw this bug marked as "wontfix". Any objection to reopening this -- or opening a fresh bug -- and making a plan to revisit this discussion & design in a few months?
Flags: needinfo?(alam)

Comment 25

2 years ago
I'm going to reopen this bug. Let's figure out what other work is required for this and get that on file.

In order to prioritize this, we need to understand how much work this would involve. I want to go digging around for whatever old bugs we have about site permissions, since I know that this issue has come up in the past.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
To consider: An obvious use-case on mobile is switching between front and back camera using an in-content [flip] button or similar. Because we treat front and back as separate cameras, without this patch, users have no way to avoid being re-prompted for permission each time they flip. Try it:
You need to log in before you can comment on or make changes to this bug.