1250872 - No way to grant persistent camera permission

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Audio/Video, defect, P2)

Description

[Gian-Carlo Pascutto [:gcp]]

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

Comment 1

[Blake Wu [:bwu][:blakewu]]

Munro is working on this one.
Thanks!

Comment 2

[Munro Mengjue Chiang [:mchiang] Be Mozillian since 1/19/2018]

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.

Comment 3

[Munro Mengjue Chiang [:mchiang] Be Mozillian since 1/19/2018]

Attachment: WIP-01-grant-persistent-camera-microphone-permission.patch

Comment 4

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

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.

Comment 5

[Munro Mengjue Chiang [:mchiang] Be Mozillian since 1/19/2018]

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

Comment 6

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

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

Comment 7

[Munro Mengjue Chiang [:mchiang] Be Mozillian since 1/19/2018]

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

[Sebastian Kaspari (:sebastian; :pocmo)]

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.

Comment 9

[Gian-Carlo Pascutto [:gcp]]

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.

Comment 10

[Maire Reavy [:mreavy]]

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.

Comment 11

[Munro Mengjue Chiang [:mchiang] Be Mozillian since 1/19/2018]

Attachment: Screenshot_20160415-110508.png

Comment 12

[Munro Mengjue Chiang [:mchiang] Be Mozillian since 1/19/2018]

Attachment: Screenshot_20160415-110636.png

Comment 13

[Munro Mengjue Chiang [:mchiang] Be Mozillian since 1/19/2018]

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])

Comment 14

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(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 :)

Comment 15

[Munro Mengjue Chiang [:mchiang] Be Mozillian since 1/19/2018]

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

Comment 16

[Barbara Bermes [:barbara] - NI please!]

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?

Comment 17

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

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

[:Margaret Leibovic]

(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

[:Margaret Leibovic]

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

Comment 20

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

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

Comment 21

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

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.

Comment 22

[Maire Reavy [:mreavy]]

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.

Comment 23

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

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.

Comment 24

[Maire Reavy [:mreavy]]

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?

Comment 25

[:Margaret Leibovic]

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.

Comment 26

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

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:

Comment 27

[Maiya Shur]

I wanted to comment on this, despite of how old it is.  We've just created a JS library that relies on camera to do scanning and decoding of barcodes directly in the browser.   Because of recent improvements made by Mozilla to how WebAssembly is handled, we are seeing off-the-charts better performance on Firefox than on other browsers.  

Unfortunately, since the user is unable to grant persistent camera permissions, the resulting experience is often a deal-breaker and the end users are encouraged to use less-performant Chrome instead.  An app user doing scanning may need access to camera several times in a browser session, and is likely to use the site daily.  As such, it's a huge inconvenience to keep asking them for camera permissions.  

Not sure if this moves the needle for you guys, but wanted to let you know that we're not able to recommend that our users use Firefox on mobile as a result.

Comment 28

[Charles Nepote]

I would like to give you a quick feedback about this very good (non official) Open Food Facts PWA app, see https://pwascanit.com/

The app is very hard to use with Firefox. It is understandable that the app ask for permission once, at the launch of the app. But it is very annoying to have to repeat this process for each scan. This app is clearly unusable with Firefox for some usages:

• scanning multiple products in a market when you suffer from allergies
• scanning products at home when you get back from the market
• scan party with a local group
• ...

We are disapointed because our projects (PWA Scanit and Open Food Facts) share the same values as Mozilla projects (open source, open data). But for the moment we will have to recommand other browsers for our users. Open Food Facts differents apps are used by 1 million users monthly.
https://world.openfoodfacts.org/

Comment 29

[Maxime Lambrecht]

I just wanted to add my two cents : this bug is a huge deal-breaker for my scanning webapp; for the exact same reasons as Charles above.
As a staunch free software advocate, I'd love to recommend Firefox for Android to my users, especially since it generally provide better support for the features we implemented (notably the use of getusermedia)
However, since Firefox for android keeps asking permission between each call, rendering the experience borderline unusable, I will have no other option than to to recommend my users to use chrome.

It is also a pity that such hurdles are created for the webapps model, as was also mentionned above. Webapps are more in line with the commitment of the Mozilla community to free software and open standards, but this sort of bug keep getting in the way, undermining the work of the (increasingly few) developpers committed to that vision on mobile.

Anyway, it would be great if someone could spend 30 minutes to fix this. Thank you.

Comment 30

[adrianehrsam]

Hi there, any news on this one? This is a dealbreaker for my company, too

Comment 31

[adrianehrsam]

To be very clear: Our customer will be using Chrome instead if this gets not fixed

Comment 32

[tom]

Same here. Can't use Firefox with my PWA because of this. I would expect Firefox to be at the forefront of PWA support given the implications of PWAs for an open internet. Sending deep gratitude for the FFox project and a kind request to prioritize this one.

Comment 33

[sebastian]

I just came accross this issue and, as this doesn't seem to get any attention, I will also advise my customer to switch to Chrome. This issue is VERY problematic for modern webapps and since PWAs will get more important from year to year, you should really have a look at it.

Comment 34

[Paul Adenot (:padenot)]

Jan-Ivar, this seem to be still valid. What would be a good route to fix this?

Comment 35

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

This is already fixed in Firefox Preview (geckoview), so I wouldn't expect it in Fennec. Checking with snorp, but I suspect this can be closed.

Comment 36

[Paul Adenot (:padenot)]

It's not fixed on Fennec, but we're also not investing in Fennec. Closing this.