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

On Thu, Mar 27, 2014 at 1:16 PM, Cullen Jennings (fluffy)
<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 wrote:
>
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=22337
> >
> > Randell Jesup <rjesup@jesup.org> changed:
> >
> >           What    |Removed                     |Added
> >
> ----------------------------------------------------------------------------
> >                 CC|                            |rjesup@jesup.org
> >
> > --- Comment #2 from Randell Jesup <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.
> >
> >
>
>
>