1470833 - Add NSCameraUsageDescription and NSMicrophoneUsageDescription Info.plist Keys for 10.14

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect, P1)

Description

[Haik Aftandilian [:haik]]

Attachment: 10.14 Camera Access Dialog Comparison

In the new macOS 10.14 Mojave, applications accessing the camera and microphone trigger OS dialog prompts allowing the user to allow or deny the permission for the application. The dialog prompts can include some application-specific customized text using NSCameraUsageDescription and NSMicrophoneUsageDescription Info.plist keys as, documented in the WWDC video[1]. This is meant to provide an explanation for why the application is accessing the input device. This doesn't appear to require building with the 10.14 SDK. I tested this[2] on the current 10.14 Beta by only changing Firefox's Info.plist file and that worked. See attached screenshot

1. https://developer.apple.com/videos/play/wwdc2018/702/

2.
$ diff /Applications/Firefox.app/Contents/Info.plist ~/Info.plist.orig 
4a5,9
> 	<key>NSCameraUsageDescription</key>
> 	<string>Firefox needs to access the camera for sites that you allow to use the camera.</string>
> 	<key>NSMicrophoneUsageDescription</key>
> 	<string>Firefox needs to access the microphone for sites that you allow to use the microphone.</string>

Comment 1

[Stephen A Pohl [:spohl]]

Do you plan on tackling this bug?

Comment 2

[Haik Aftandilian [:haik]]

(In reply to Stephen A Pohl [:spohl] from comment #1)
> Do you plan on tackling this bug?
I'm happy to take it.

Romain, are you the right person to recommend/review the text to be displayed in the dialog? See attached screenshot for an example.

Comment 3

[Haik Aftandilian [:haik]]

@bram, could you review the camera/mic dialog text in the attached screenshot?

Comment 4

[Bram Pitoyo [:bram]]

(In reply to Haik Aftandilian [:haik] from comment #3)
> @bram, could you review the camera/mic dialog text in the attached
> screenshot?

While Content Strategy is the right team to work on this dialogue, I’d like to ask a few clarification questions:

1. At what point in time will this dialogue be shown? I’m guessing that it’s when Firefox opens any website that requires camera or microphone access for the very first time.

2. Will this dialogue only be shown once – to be applied to all subsequent sites that request access camera/mic, or will the user see it on every site?

3. Can we pass the site name dynamically to the dialogue, or are we stuck with using the word “Firefox”?

One copywriting idea is to pass the responsibility from Firefox to the website. After all, it’s not Firefox that asks for permission. It’s Firefox asking on behalf of a website.

Something along this line:

> A website that you opened with Firefox wants to access the camera.


Alternatively, we don’t have to pass the responsibility, but can clarify that the global setting doesn’t mean that the camera is auto-allowed to all sites:

> Allow websites that you open with Firefox to access the camera. You will still get to determine whether a specific website will be blocked or allowed.


Thoughts?

Comment 5

[Haik Aftandilian [:haik]]

(In reply to Bram Pitoyo [:bram] from comment #4)
> (In reply to Haik Aftandilian [:haik] from comment #3)
> > @bram, could you review the camera/mic dialog text in the attached
> > screenshot?
> 
> While Content Strategy is the right team to work on this dialogue, I’d like
> to ask a few clarification questions:
> 
> 1. At what point in time will this dialogue be shown? I’m guessing that it’s
> when Firefox opens any website that requires camera or microphone access for
> the very first time.

On Mojave 10.14, it's going to be shown the first time Firefox tries to use the camera and/or mic (and there will be one dialog for each.) So yes it will be as a result of the user visiting a site that tries to use the cam/mic. An OS-user should just see this once, the first time they use the camera/mic in Firefox, regardless of the profile in use.

First, Firefox's own door hanger will be shown if the user hasn't already allowed this site. i.e., the "Will you allow talky.io to use your camera and microphone" door hanger. Once the user clicks OK, these new Mojave prompts will be displayed. Once the user clicks "OK" on the Mojave prompt, they won't be asked again to allow Firefox regardless of the site the user is visiting. (Like how an app gets access to the cam/mic on iOS.) 

> 2. Will this dialogue only be shown once – to be applied to all subsequent
> sites that request access camera/mic, or will the user see it on every site?

Once, to be applied to all subsequent sites, assuming the user clicks "OK" and allows access to the camera. The browser will still ask for permission in the normal way for each site, using the doorhanger.

> 3. Can we pass the site name dynamically to the dialogue, or are we stuck
> with using the word “Firefox”?

We can't make any dynamic changes and the top line of the dialog can't be changed so it will always say '"Firefox" would like to access the camera.' (We have another bug filed bug 1474462 where the name "plugin-container" is used.) It probably wouldn't make sense to use the site name in the dialog because the user is granting access for sites they visit in the future as well. The user will still see the Firefox door hanger prompts we trigger for other sites.

> One copywriting idea is to pass the responsibility from Firefox to the
> website. After all, it’s not Firefox that asks for permission. It’s Firefox
> asking on behalf of a website.
> 
> Something along this line:
> 
> > A website that you opened with Firefox wants to access the camera.
> 
> 
> Alternatively, we don’t have to pass the responsibility, but can clarify
> that the global setting doesn’t mean that the camera is auto-allowed to all
> sites:
> 
> > Allow websites that you open with Firefox to access the camera. You will still get to determine whether a specific website will be blocked or allowed.
> 
> 
> Thoughts?

I agree. Here's an example that mentions the preferences. It might be too wordy for this type of dialog, but I think mentioning the preferences assures the user they're still in control of which sites have access to the camera.

  "Firefox" would like to access the camera.
  
  Firefox needs access to the camera for sites that use the camera.
  Only sites you allow will be able to use the camera. Access to the
  camera can be configured in Firefox's Privacy and Security settings.

Comment 6

[Romain Testard [:RT]]

ccing Nils since this will impact WebRTC usage on GetUserMedia. I recall browser prompts can significantly reduce the share of users enabling gUM and my non expert concern here is that having 2 levels of authorization (application and website) could be confusing users.

A couple questions:
- What happens if the user does not allow Firefox? Does this get shown again next time ?
- What happens when this launches for users that already allowed permanent access to cam to a certain website? Would they be prompted regardless?

Comment 7

[Haik Aftandilian [:haik]]

(In reply to Romain Testard [:RT] from comment #6)
> ccing Nils since this will impact WebRTC usage on GetUserMedia. I recall
> browser prompts can significantly reduce the share of users enabling gUM and
> my non expert concern here is that having 2 levels of authorization
> (application and website) could be confusing users.
> 
> A couple questions:
> - What happens if the user does not allow Firefox? Does this get shown again
> next time ?

I think we'll have to change our code to deal with that situation better. If the user clicks "Don't Allow", the dialog does not get shown again. The user will have to go into macOS settings and allow Nightly to access the camera and mic and then restart Nightly. (I'll add some screenshots showing this dialog). It sounds like we can improve this by adding code to check if the user has allowed Firefox to access the camera and if not, manually request access using the async authorizationStatusForMediaType[1]. Assuming that would work, I think that's the best approach. I'll file a bug to cover this.

We could be aggressive and trigger the dialog the first time Firefox is run on Mojave, but I think that's annoying to users and they are more likely to click "Don't Allow". And Apple recommends showing the dialog in context (i.e., at the time the access is needed) because it is easier to understand why the permission is needed.

> - What happens when this launches for users that already allowed permanent
> access to cam to a certain website? Would they be prompted regardless?

The OS-level dialog is not per-site, it is per-application per-user. They'll be prompted by the OS if they have not previously received the prompt on any site and clicked OK. Assuming the user clicks OK, they should only see these prompts once, the first time they use the camera/mic from Firefox on macOS Mojave.

1. https://developer.apple.com/documentation/avfoundation/avcapturedevice/1624613-authorizationstatusformediatype

Comment 8

[Haik Aftandilian [:haik]]

Attachment: Behavior of WebRTC site after user has clicked "Don't Allow" on OS Camera/Mic dialog

After a user has clicked "Don't Allow" on the macOS camera/mic dialog, this shows what talky.io looks like on subsequent visits.

Comment 9

[Haik Aftandilian [:haik]]

Attachment: Screenshot showing the restart prompt shown when the user grants Firefox access to Camera in Mojave Security and Privacy settings.

Comment 10

[Haik Aftandilian [:haik]]

Attachment: Bug 1470833 - Add NSCameraUsageDescription and NSMicrophoneUsageDescription Info.plist Keys for 10.14 OBSOLETE

Add Info.plist string entries for the Firefox executable to customize Mojave camera and microphone permission dialogs.

Comment 11

[Haik Aftandilian [:haik]]

@bram, I wanted to add you as a reviewer on this, but it looks like you haven't setup a Phabricator account yet.

Comment 12

[Haik Aftandilian [:haik]]

The posted fix sets the body of the Mojave camera and microphone permissions to be as follows. See attached screenshot for an example.

  Only sites you allow will be able to use the camera.
  Access to the camera can be configured in %MAC_APP_NAME%
  Privacy and Security settings.
  
The %MAC_APP_NAME% string will be replaced as follows.

  Release                   = Firefox
  Beta                      = Firefox
  Nightly                   = Firefox Nightly
  Firefox Developer Edition = Firefox Developer Edition
  
I haven't done builds with the Release/Beta/DevEdition marketing yet to confirm this, but will do that before landing.

Comment 13

[Haik Aftandilian [:haik]]

Attachment: New dialog for Mojave microphone permission on Nightly (version 1)

Comment 14

[Bram Pitoyo [:bram]]

This is tricky, because there are now two different places to manage camera permissions:

1. macOS System Preferences > Security & Privacy > “Privacy” tab > Camera
2. Firefox Preferences > Privacy & Security > Permissions > Camera > Settings…


The permission user flow looks like this:

1. When a site asks for permission, then the Firefox dialogue gets triggered.
2. If the Firefox dialogue is allowed, then the macOS system dialogue gets triggered.
3. If the macOS system dialogue is allowed, then the camera can operate.

So the user implicitly understands that the browser gets triggered first, then the system gets triggered.

The problem is, if the user clicks “Don’t Allow” on the macOS system dialogue, then whatever the website does in the future, the browser cannot get triggered until the system blockage has been removed.

In other words, it’s impossible to simply refresh the website and re-show the Firefox dialogue, and it’s impossible to re-show the system dialogue. The only way to remove the system blockage is by manually going into Settings.

So, the system dialogue will need to clarify this fact, and I recommend writing it as follows (string pending review and rewrite from Content Strategy):

> "Firefox" would like to access the camera.
> 
> macOS wants to know whether websites that you open with Firefox is allowed
> to ask your permission to use the camera.
>
> When you click “Allow”, you will still be able to control which sites
> are allowed to use the camera, and which sites are blocked.
>
> When you click “Don’t Allow”, you will never be asked for camera permission
> again. To change it, go to System Preferences > Security & Privacy > Privacy
> Camera, then check the checkbox next to the “Firefox” icon.

The dialogue will be really wordy (maybe to the point of being too wordy), but it will be clear.

-----

One more question: how do I create a Phabricator account?

Comment 15

[Haik Aftandilian [:haik]]

(In reply to Bram Pitoyo [:bram] from comment #14)
> This is tricky, because there are now two different places to manage camera
> permissions:
> 
> 1. macOS System Preferences > Security & Privacy > “Privacy” tab > Camera
> 2. Firefox Preferences > Privacy & Security > Permissions > Camera >
> Settings…
> 
> 
> The permission user flow looks like this:
> 
> 1. When a site asks for permission, then the Firefox dialogue gets triggered.
> 2. If the Firefox dialogue is allowed, then the macOS system dialogue gets
> triggered.
> 3. If the macOS system dialogue is allowed, then the camera can operate.
> 
> So the user implicitly understands that the browser gets triggered first,
> then the system gets triggered.
> 
> The problem is, if the user clicks “Don’t Allow” on the macOS system
> dialogue, then whatever the website does in the future, the browser cannot
> get triggered until the system blockage has been removed.
> 
> In other words, it’s impossible to simply refresh the website and re-show
> the Firefox dialogue, and it’s impossible to re-show the system dialogue.
> The only way to remove the system blockage is by manually going into
> Settings.

Thanks. If you didn't see it, take a look at bug 1479051 - "[macOS 10.14] WebRTC sites silently fail if user previously clicked "Don't Allow" for Firefox camera/mic access" if you haven't already.

This makes me think we need to do even more: if we are ever on a site that has been given access to the camera, but Firefox doesn't have access, we should show a UI mentioning this with a button that takes the user to the relevant System Preferences pane. I don't know if Mojave will allow us to open up the System Preferences, but I'll look into it on bug 1479051.

> So, the system dialogue will need to clarify this fact, and I recommend
> writing it as follows (string pending review and rewrite from Content
> Strategy):
> 
> > "Firefox" would like to access the camera.
> > 
> > macOS wants to know whether websites that you open with Firefox is allowed
> > to ask your permission to use the camera.

That isn't quite right because if a user clicks OK, it doesn't mean the site will ask for permission because the site might have already been given permission to use the camera/microphone before the user upgraded to Mojave. Maybe we can drop this part because I think it is redundant after reading "Firefox would like to access the camera."

> > When you click “Allow”, you will still be able to control which sites
> > are allowed to use the camera, and which sites are blocked.
> >
> > When you click “Don’t Allow”, you will never be asked for camera permission
> > again. To change it, go to System Preferences > Security & Privacy > Privacy
> > Camera, then check the checkbox next to the “Firefox” icon.
> 
> The dialogue will be really wordy (maybe to the point of being too wordy),
> but it will be clear.

I'll generate a screenshot with this and see how it looks.

> One more question: how do I create a Phabricator account?

https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#creating-an-account

Comment 16

[Haik Aftandilian [:haik]]

Attachment: New dialog for Mojave microphone permission on Nightly (version 2)

Comment 17

[Haik Aftandilian [:haik]]

@bram, I've updated the text to take into account your comments (not verbatim, but having roughly the same effect). What do you mean by "Content Strategy" review?

Comment 18

[Haik Aftandilian [:haik]]

I'm not totally happen with either version of the text and need some help finalizing this so we can get the fix landed.

Comment 19

[Bram Pitoyo [:bram]]

Sorry for my overdue response to this bug. See bug 1479051 comment 33 for my response, which was posted as an email to Haik yesterday – but may not be delivered due to my email problem.

Comment 20

[Panos Astithas (he/him) [:past] (please ni?)]

Not sure if this has been already mentioned, but in pre-release channels where we use Core Location APIs the first geolocation request also triggers an OS dialog prompt, right after the Firefox permission prompt. It would be nice to have some consistency in all these prompts if possible.

Comment 21

[Bram Pitoyo [:bram]]

See bug 1479051 for user flow diagram and string proposal.

I’m hoping that we can follow exactly the same user flow and string for geolocation? (Obviously, we rename “camera” and “mic” to “location”).

Comment 22

[Haik Aftandilian [:haik]]

Attachment: New dialog for Mojave microphone permission on Nightly (version 3)

Comment 23

[Haik Aftandilian [:haik]]

Attachment: Bug 1470833 - Add NSCameraUsageDescription and NSMicrophoneUsageDescription Info.plist Keys for 10.14 r?mstange

Add Info.plist string entries for the Firefox executable to customize Mojave camera and microphone permission dialogs.

UI text discussed and approved by Bram on bug 1479051 (https://bugzilla.mozilla.org/show_bug.cgi?id=1479051#c36)
on addition to this bug.

Comment 24

[Markus Stange [:mstange]]

Comment on attachment 9012448 [details]
Bug 1470833 - Add NSCameraUsageDescription and NSMicrophoneUsageDescription Info.plist Keys for 10.14 r?mstange

Markus Stange [:mstange] has approved the revision.

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7a531716e073
Add NSCameraUsageDescription and NSMicrophoneUsageDescription Info.plist Keys for 10.14 r=mstange

Comment 26

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/7a531716e073

Comment 27

[Haik Aftandilian [:haik]]

The new text is displayed in a dialog box on macOS and will need to be localized so the text is in the right language. The fix only applies to Mac. The new text is in the Mac .app bundle in an info.plist file that is generated during the build. Please let me know if there are any questions.