Closed Bug 1021643 Opened 5 years ago Closed 5 years ago

Make gUM permissions (audio-capture, video-capture) allow by default for certified apps

Categories

(Core Graveyard :: DOM: Apps, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla32

People

(Reporter: pauljt, Assigned: jesup)

References

Details

(Whiteboard: [webRTC][p=5, ft:loop])

Attachments

(1 file)

Certified apps can already grab the camera using the mozcamera permission without a prompt. It makes sense that we can also grant gUM permissions (audio-capture, video-capture) to certified apps to harmonize behaviors between these APIs. (I did propose a while ago that the camera permission actually be merged into video-capture but I think that got punted)

This is important though for 2.0 as it greatly improves the loop experience - gaia privileged apps are already treated as certified for the purposes of permission initialization (bug 1014410) but currently video-capture and audio-capture is prompt for certified apps. 

I don't think this is unreasonable since we security review all gaia apps to ensure that they don't capture audio/video without the user being aware.

With 988285 landed, this change should be very small and low risk: Just changing PROMPT to ALLOW in http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/PermissionsTable.jsm#301 and http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/PermissionsTable.jsm#327
Comment on attachment 8435768 [details] [diff] [review]
allow Certified B2G apps to access mic and camera without prompting

r? to sicking, however:

I have concerns about this from a Privacy perspective.  Allowing mic and camera access by default seems to be out of line with the policy of not allowing certified apps access to geolocation information without a prompt, for example. 

Also, the argument is made there that "we already do this for Camera, audio and video isn't really any different".  Well, a) it is different in many user's minds - audio (in particular) == wiretapping/snooping/NSA/etc, and b) looking at the bug that enabled this for Camera, I don't see privacy issues even being discussed, so proxying to that as an already-decided argument seems an overreach - at least without serious discussion.  It seems at odds with our position about user control.

This is trivially flipped at any point; I'm ok with flipping it now and having the privacy/"should we" discussion after it lands in the tree.
Attachment #8435768 - Flags: review?(jonas)
Assignee: nobody → rjesup
Comment on attachment 8435768 [details] [diff] [review]
allow Certified B2G apps to access mic and camera without prompting

Adding PaulJT, I'll take either.
Attachment #8435768 - Flags: review?(ptheriault)
Thanks Jesup - I had my concerns about audio too so happy to discuss further. The mitigation in my mind though here is that gaia apps need to go through security and privacy review (and should be making it clear to the user that they are using microphone and camera when they are using it). Further we have persitent notifications on the status for gUM (which we don't have to camera or telephony permissions I might add, but maybe we should). 

I'm happy to r+ this since I proposed it, but I would prefer Jonas to at least be aware of this before it lands since I was the one proposing here.
Attachment #8435768 - Flags: review?(ptheriault) → review+
Comment on attachment 8435768 [details] [diff] [review]
allow Certified B2G apps to access mic and camera without prompting

Review of attachment 8435768 [details] [diff] [review]:
-----------------------------------------------------------------

As long as we always make it clear in the app UI what's going on, I think this is fine. Though I agree that ideally I would have liked to prompt as to not give ourselves extra favors. But we can always tweak this stuff over time.
Attachment #8435768 - Flags: review?(jonas) → review+
https://hg.mozilla.org/mozilla-central/rev/553bf8d3404c
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.