Closed Bug 977971 Opened 11 years ago Closed 11 years ago

FxOS GUM indicators can be hidden if camera and microphone requested separately


(Firefox OS Graveyard :: General, defect)

Not set



blocking-b2g 1.4+


(Reporter: pauljt, Assigned: fabrice)


(Keywords: sec-high)

So it appears that the indicators in the status bar and notification tray are only designed to deal with one app at a time using getUserMedia. This is normally the case since getUserMedia({video:true}) will fail if another app is already using the camera (same for audio). However if one app is using video, and one app is using audio, you can end up in a state where video is enabled, but there is no indicator shown.

For this test I installed two apps that basically have this page in them:

1. In app 1, start audio and accept the prompt
2. In app 2, start video and accept the prompt
3. Look at the notification tray - you will see that only app1 one is shown, and it is shown to be using the microphone.
4. Kill app 1, and the gUM notification will fade then disappear as normal
5. Go back to app 2, and you can see that video is still being captured, even though there is no notification in tray or red dot in status bar.

Expected Result:
Either the second call to gUM fails, or two status notifications should be shown (probably the latter, but will need a semaphore for tracking or something?)

Video is still captured with no indication to the user.

Security Implications:

I'm marking this as security sensitive even though this is pre-release, just in case. While the steps above may sound unlikely, I'm pretty sure a lone app could achieve a similar result using web activities, iframes or some combination of the two. Its probably easier to fix than to construct that PoC though. If that were possible, this constitutes a pretty serious privacy issue, so I am marking this sec-high. One mitigation is the user does have to actually accept both prompts, so its not completely stealth.
SC - May I assign this bug to you?  We need to resolve this bug ASAP for v1.4.  If you are unavailable, please let us know so that we can find a new owner.  I am copying CJ, Steven, and Ekr on this bug for their awareness.  Thank you.
Assignee: nobody → schien
Flags: needinfo?(schien)
Hi Maire,

S.C. is not available to work on this bug right away since today is the national holiday in Taiwan. For such urgent bug, is it possible to find a new owner from other regions?
Flags: needinfo?(mreavy)
I'll take a look tomorrow
Assignee: schien → fabrice
We either need to fix this or turn off gUM video support. Either way - blocking+.
Blocks: b2g-getusermedia
No longer blocks: 923361
blocking-b2g: --- → 1.4+
Whiteboard: [ucid:WebRTC7, 1.4, ft:multimedia-platform]
This might be a dupe of bug 942724.
yes, it is bug 942724 and it needs Gaia modification.
Flags: needinfo?(schien)
I've marked this as dependent on bug 942724 (so that the 2 bugs are linked) in case there are any additional code changes (specific to gUM) that are needed after bug 942724 is fixed, but it may make more sense to close this as a dupe.  

SC -- Will there be any gUM-specific code changes needed after bug 942724 is fixed?  Or will multiple gUM notifications simply work once bug 942724 is fixed?

I'll make the rest of my comments in bug 942724.
Depends on: 942724
Flags: needinfo?(mreavy) → needinfo?(schien)
Fix Gaia in bug 942724 is enough. Gecko part has done in Bug 940045.
Flags: needinfo?(schien)
please cc me in Bug 940045 thus I could better checking gaia part in bug 942724.
Fred, I just added you to Bug 940045
Given that there are no additional code changes required here in gecko, I'm going to dupe this to the Gaia bug.
No longer blocks: b2g-getusermedia
Closed: 11 years ago
No longer depends on: 942724
Resolution: --- → DUPLICATE
Group: core-security
Group: b2g-core-security, core-security
You need to log in before you can comment on or make changes to this bug.