1470592 - macOS 10.14 Camera/Mic Permissions granted in Private Browsing Mode shouldn't persist

Status: NEW

(Firefox :: Private Browsing, enhancement, P3)

Description

[Haik Aftandilian [:haik]]

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. In the same way that our Firefox site permissions granted in private browsing mode don't persist after the last Private Browsing window is closed, neither should the OS-level permissions (ideally). Apple's WWDC presentation stated they'd be shipping a utility to reset an App's OS-level permissions, but that it's not something developers should use outside of testing. So implementing this might not be possible or advisable. Needs more research to determine if this is something we want to pursue.

The new prompts are described here (video is downloadable).
https://developer.apple.com/videos/play/wwdc2018/702/

Querying the OS permission state can be done with the authorizationStatusForMediaType API:
https://developer.apple.com/documentation/avfoundation/avcapturedevice/1624613-authorizationstatusformediatype?language=objc

Comment 1

[Johann Hofmann [:johannh]]

I don't understand why this is a problem. The website still has to go through the Firefox permission prompts. In what scenario would persisting this information be troublesome?

Comment 2

[Tom Ritter [:tjr]]

(In reply to Johann Hofmann [:johannh] from comment #1)
> I don't understand why this is a problem. The website still has to go
> through the Firefox permission prompts. In what scenario would persisting
> this information be troublesome?

We don't want to write the behavior of the user in Private Browsing Mode to disk, especially not in a permanent record.

Comment 3

[Luke Crouch [:groovecoder]]

+1 :tjr. And this smells like a potential tracking vector too? Has anyone dug into this one more thoroughly?

Comment 4

[Haik Aftandilian [:haik]]

(In reply to Luke Crouch [:groovecoder] from comment #3)
> +1 :tjr. And this smells like a potential tracking vector too? Has anyone
> dug into this one more thoroughly?

I'm not sure the camera/mic OS-level permission status would work well as a tracking vector. It would provide a single bit of information. Theoretically, a site could try to check if the OS-level access had been granted and use that knowledge, but that would require the site requesting camera/mic access itself and the user allowing it and then using timers (or some other means) to detect if the blocking allow/deny OS-level dialog was displayed. However, sites can't request that in the background without the user knowing unless the user has already allowed camera/mic access for that site.

Comment 5

[Luke Crouch [:groovecoder]]

Ah, sites can't request the permission in the background mitigates a lot of my concern. Thanks for the info!