This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec is pretty vague about when user indicators are expected to be shown: 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). This needs to be much more precise, particularly with respect to sites that are granted persistent permissions.
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. 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.
(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".
Two indicators - one when there is a permission - one where media is being captured When you call media stream stop, the capture ligth goes out Will say MUST indicate. We don’t say how we indicate.
Discussed at Media Capture TF meeting May 19. Consensus as captured in comments above. Waiting for text suggestion.
The text supplied by Martin: "[active] The browser MUST provide noticeable indicia when actively capturing media from a device. [potential] The browser MUST provide indicia when a site has a nascent ability to capture from a device without a user consent prompt."
Addressed this as part of security considerations. Security considerations say that there are two indicators, and what they indicate. Added specific text under opening/closing of tracks to say when they come on and go off. https://github.com/fluffy/webrtc-w3c/commit/6d6cb760205597f29c267c9438ea330034027454