Add NSCameraUsageDescription and NSMicrophoneUsageDescription Info.plist Keys for 10.14

RESOLVED FIXED in Firefox 64
(Needinfo from 2 people)

Status

()

defect
P1
normal
RESOLVED FIXED
Last year
9 months ago

People

(Reporter: haik, Assigned: haik, NeedInfo)

Tracking

(Blocks 1 bug)

62 Branch
mozilla64
Unspecified
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox62 wontfix, firefox63 wontfix, firefox64 fixed)

Details

Attachments

(5 attachments, 3 obsolete attachments)

Assignee

Description

Last year
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>
Assignee

Updated

Last year
Blocks: mojave
See Also: → 1470592
Assignee

Updated

Last year
See Also: → 1474462
Do you plan on tackling this bug?
Flags: needinfo?(haftandilian)
Priority: -- → P2
Assignee

Comment 2

11 months ago
(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.
Assignee: nobody → haftandilian
Flags: needinfo?(haftandilian) → needinfo?(rtestard)
Priority: P2 → P1
Assignee

Comment 3

11 months ago
@bram, could you review the camera/mic dialog text in the attached screenshot?
Flags: needinfo?(rtestard) → needinfo?(bram)

Comment 4

11 months ago
(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?
Flags: needinfo?(bram) → needinfo?(mheubusch)
Assignee

Comment 5

11 months ago
(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

11 months ago
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?
Assignee

Comment 7

11 months ago
(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
Assignee

Comment 8

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

Updated

11 months ago
See Also: → 1479051
Assignee

Comment 10

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

Comment 11

11 months ago
@bram, I wanted to add you as a reviewer on this, but it looks like you haven't setup a Phabricator account yet.
Flags: needinfo?(bram)
Assignee

Comment 12

11 months ago
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 14

11 months ago
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?
Flags: needinfo?(bram)
Assignee

Comment 15

11 months ago
(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
Assignee

Comment 16

11 months ago
Attachment #8998004 - Attachment is obsolete: true
Assignee

Comment 17

11 months ago
@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?
Flags: needinfo?(bram)
Assignee

Updated

10 months ago
Attachment #8998004 - Attachment description: New dialog for Mojave microphone permission on Nightly → New dialog for Mojave microphone permission on Nightly (version 1)
Attachment #8998004 - Attachment is obsolete: false
Assignee

Updated

10 months ago
Attachment #8999286 - Attachment description: New dialog for Mojave microphone permission on Nightly → New dialog for Mojave microphone permission on Nightly (version 2)
Assignee

Comment 18

10 months ago
I'm not totally happen with either version of the text and need some help finalizing this so we can get the fix landed.
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.
Flags: needinfo?(bram)
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.
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”).
Assignee

Comment 22

9 months ago
Attachment #8998004 - Attachment is obsolete: true
Attachment #8999286 - Attachment is obsolete: true
Assignee

Updated

9 months ago
Attachment #9012027 - Attachment description: New dialog for Mojave microphone permission on Nightly (version 2) → New dialog for Mojave microphone permission on Nightly (version 3)
Assignee

Updated

9 months ago
See Also: → 1494326
Assignee

Comment 23

9 months ago
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.
Assignee

Updated

9 months ago
Attachment #8998003 - Attachment is obsolete: true
Attachment #9012448 - Attachment description: Bug 1470833 - Add NSCameraUsageDescription and NSMicrophoneUsageDescription Info.plist Keys for 10.14 r?spohl → Bug 1470833 - Add NSCameraUsageDescription and NSMicrophoneUsageDescription Info.plist Keys for 10.14 r?mstange
Attachment #8998003 - Attachment description: Bug 1470833 - Add NSCameraUsageDescription and NSMicrophoneUsageDescription Info.plist Keys for 10.14 → Bug 1470833 - Add NSCameraUsageDescription and NSMicrophoneUsageDescription Info.plist Keys for 10.14 OBSOLETE
Attachment #8998003 - Attachment is obsolete: false
Attachment #8998003 - Attachment is obsolete: true
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.
Attachment #9012448 - Flags: review+

Comment 25

9 months ago
Pushed by haftandilian@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7a531716e073
Add NSCameraUsageDescription and NSMicrophoneUsageDescription Info.plist Keys for 10.14 r=mstange

Comment 26

9 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/7a531716e073
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Assignee

Comment 27

9 months ago
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.
Flags: needinfo?(l10n)
QA Contact: mstange
You need to log in before you can comment on or make changes to this bug.