Re: [Bug 22337] When does the light come on?

On 3/27/2014 8:06 PM, Justin Uberti wrote:
> Note also that video capture, especially at HD, consumes a nontrivial 
> amount of CPU. Therefore being able to 'mute', by shutting off the 
> capturer, is more than just a privacy consideration.
>
> This is clearly a dilemma, and I don't think it can be addressed 
> without either giving up on the functionality, or using permissions 
> that persist outside the lifetime of the camera indicator.

I'll also note that actually stopping the capture (as opposed to 
ignoring frames, not fetching new frames, or setting the frame rate to 
0) may cause lengthy camera-re-initialization.  Some cameras can take a 
noticeable amount of time to open and go active (on the order of 
hundreds or even thousands of milliseconds).   Other cameras can restart 
quickly.

There certainly is a dilemma here between user preferences (to use the 
*hardware* light) as a capture indicator, and security against sneak 
peeks.  One option is to allow the UA to de-initialize the camera (turn 
off HW light if any) in some cases (like Mute), but keep the on-screen 
indication on always when the app has a valid getUserMedia stream.

It's not a perfect solution, of course.

>
>
> On Thu, Mar 27, 2014 at 2:04 PM, Eric Rescorla <ekr@rtfm.com 
> <mailto:ekr@rtfm.com>> wrote:
>
>
>
>
>     On Thu, Mar 27, 2014 at 1:16 PM, Cullen Jennings (fluffy)
>     <fluffy@cisco.com <mailto:fluffy@cisco.com>> wrote:
>
>
>         The "light" (or whatever the indicator is), should be on when
>         capturing. There should be a way for the JS application to
>         pause capture in a way that both causes the light to go out
>         and allows easy resumption of capture.
>
>
>     I don't agree with this when persistent permissions are not in play.
>     Otherwise, there is a fairly obvious security problem.
>
>     -Ekr
>
>         There might be a nuance of this in that it takes the light a
>         second to go off to avoid flicker capture attacks.
>
>         Users find if  troublesome when the light is always on even
>         when it is not capturing.  Applications that leave the light
>         on all the time get lots of user complaints and typically
>         change to not cause the light to be on when they are not
>         capturing. Leaving the light on all the time causes users to
>         start ignoring the light which is also bad.
>
>
>         On Mar 22, 2014, at 1:29 AM, bugzilla@jessica.w3.org
>         <mailto:bugzilla@jessica.w3.org> wrote:
>
>         > https://www.w3.org/Bugs/Public/show_bug.cgi?id=22337
>         >
>         > Randell Jesup <rjesup@jesup.org <mailto:rjesup@jesup.org>>
>         changed:
>         >
>         >           What    |Removed         |Added
>         >
>         ----------------------------------------------------------------------------
>         >                 CC|        |rjesup@jesup.org
>         <mailto:rjesup@jesup.org>
>         >
>         > --- Comment #2 from Randell Jesup <rjesup@jesup.org
>         <mailto:rjesup@jesup.org>> ---
>         > (In reply to Harald Alvestrand from comment #1)
>         >> The current text on indicators is:
>         >>
>         >> - 4.3 says that when a track is stopped, the user agent
>         should remove the
>         >> indicator for that source.
>         >>
>         >> - 10.1.1 says that UAs are encouraged to include a
>         prominent indicator that
>         >> the devices are "hot" when getUserMedia returns successfully
>         >>
>         >> I think this is pretty precise (although one can discuss
>         whether it is
>         >> sufficient). It does allow one to do the "indicator flash"
>         thing where one
>         >> opens up a device, takes a photo and closes the device
>         immediately - but
>         >> leaving the indicator on when no media is being captured
>         seems lame.
>         >
>         > One can leave this up to the UA; on FxOS (and maybe android,
>         I forget) we dim
>         > it after ending, and then let it time out shortly.  The
>         indicator flash concern
>         > is mostly around uses with persistent permission OR with
>         implementations that
>         > allow a single permission to make a camera go "hot" multiple
>         times (which I
>         > consider a major privacy risk) AND don't require the
>         indicator be on the entire
>         > time permission is given (see below).
>         >
>         >> We don't have any requirement that an indicator be shown
>         when permission is
>         >> granted. If we want that, I think we need an additional
>         indicator, not the
>         >> "on-air" one.
>         >
>         > Actually, it's arguable what the current spec requires - the
>         text is
>         >
>         > "If the user grants permission to use local recording
>         devices, user agents are
>         > encouraged to include a prominent indicator that the devices
>         are "hot" (i.e. an
>         > "on-air" or "recording" indicator)."
>         >
>         > There's no "when recording starts" or "when the devices are
>         'hot'" (it uses
>         > "that", which changes the meaning considerably compared to
>         "when"; you
>         > certainly can read the text as "you need to put up an
>         indicator once the user
>         > grants permission".
>         >
>         > --
>         > You are receiving this mail because:
>         > You are on the CC list for the bug.
>         > You are the assignee for the bug.
>         >
>         >
>
>
>
>


-- 
Randell Jesup -- rjesup a t mozilla d o t com