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

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.


On Thu, Mar 27, 2014 at 2:04 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
>
> 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.
>> >
>> >
>>
>>
>>
>