Camera hardware is going to be used by Apps and Web contents. Camera hw usage APIs are Camera API and WebRTC. We need a way to arbitrate camera usage between apps and web contents. Bug 871485 might be helpful to understand the problem.

What are you thinking? It seems to me that background processes could be allowed to keep a hold on the camera so long as no foreground process wants it; but if a foreground process tried to get the camera, it should always be able to.

(In reply to Mike Habicher [:mikeh] from comment #1) > What are you thinking? It seems to me that background processes could be > allowed to keep a hold on the camera so long as no foreground process wants > it; but if a foreground process tried to get the camera, it should always be > able to. I also think same thing. But I am not sure about the camera when display is off. In current WebRTC implementation, camera is continues to be used even when display is off. It seems not good from privacy point of view.

Why is this a blocker? QA testing Nils & I did showed that the only negative impact seen right now when managing camera access across multiple apps was the fact that the camera wasn't reporting an error if gUM camera already had access. There is already UX in place to clarify which apps/origins are actively using the camera, so I think the privacy concern is addressed.

(In reply to Jason Smith [:jsmith] from comment #3) > Why is this a blocker? QA testing Nils & I did showed that the only negative > impact seen right now when managing camera access across multiple apps was > the fact that the camera wasn't reporting an error if gUM camera already had > access. There is already UX in place to clarify which apps/origins are > actively using the camera, so I think the privacy concern is addressed. Sorry Jason, I don't understand -- when is the UX shown? It looks like what Sotaro is saying is that the screen is off, so there is no UX seen but video recording continues. Input required from product too

(In reply to Hema Koka [:hema] from comment #4) > (In reply to Jason Smith [:jsmith] from comment #3) > > Why is this a blocker? QA testing Nils & I did showed that the only negative > > impact seen right now when managing camera access across multiple apps was > > the fact that the camera wasn't reporting an error if gUM camera already had > > access. There is already UX in place to clarify which apps/origins are > > actively using the camera, so I think the privacy concern is addressed. > > Sorry Jason, I don't understand -- when is the UX shown? There should be a persistent notification that shows indicating that the camera/mic is active & with what app/origin. In camera's case, I would expect to see a persistent notification appear indicating that the camera & mic is active in the camera app. This UX was implemented as a caveat of the landing of gUM video support.

(In reply to Jason Smith [:jsmith] from comment #5) > (In reply to Hema Koka [:hema] from comment #4) > > (In reply to Jason Smith [:jsmith] from comment #3) > > > Why is this a blocker? QA testing Nils & I did showed that the only negative > > > impact seen right now when managing camera access across multiple apps was > > > the fact that the camera wasn't reporting an error if gUM camera already had > > > access. There is already UX in place to clarify which apps/origins are > > > actively using the camera, so I think the privacy concern is addressed. > > > > Sorry Jason, I don't understand -- when is the UX shown? > > There should be a persistent notification that shows indicating that the > camera/mic is active & with what app/origin. In camera's case, I would > expect to see a persistent notification appear indicating that the camera & > mic is active in the camera app. > > This UX was implemented as a caveat of the landing of gUM video support. Okay, thanks for clarifying -- not blocking it for 2.0