Open
Bug 1470592
Opened 6 years ago
Updated 2 years ago
macOS 10.14 Camera/Mic Permissions granted in Private Browsing Mode shouldn't persist
Categories
(Firefox :: Private Browsing, enhancement, P3)
Tracking
()
NEW
People
(Reporter: haik, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [tor][fingerprinting][fp-triaged])
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
Updated•6 years ago
|
Whiteboard: [tor][fingerprinting]
Comment 1•6 years ago
|
||
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•6 years ago
|
||
(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•6 years ago
|
||
+1 :tjr. And this smells like a potential tracking vector too? Has anyone dug into this one more thoroughly?
Reporter | ||
Comment 4•6 years ago
|
||
(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•6 years ago
|
||
Ah, sites can't request the permission in the background mitigates a lot of my concern. Thanks for the info!
Updated•6 years ago
|
Priority: -- → P3
Whiteboard: [tor][fingerprinting] → [tor][fingerprinting][fp-triaged]
Updated•6 years ago
|
Whiteboard: [tor][fingerprinting][fp-triaged] → [tor][fingerprinting]
Updated•6 years ago
|
Whiteboard: [tor][fingerprinting] → [tor][fingerprinting][fp-triaged]
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•