- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Thu, 27 Mar 2014 12:12:08 -0400
- To: Adam Bergkvist <adam.bergkvist@ericsson.com>, bugzilla@jessica.w3.org, public-media-capture@w3.org
On 3/27/14 6:17 AM, Adam Bergkvist wrote: > On 2014-03-22 08:29, 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". > > I think an indicator that tells the user that this site has got the > permission to start using your camera at any time is more important > than the indicator that mirrors the hardware light on the camera (and > only flashes when the camera is actually capturing). Martin, I'm confused about the subject here. Are you talking about the UA controlling when the hardware LIGHT comes on, or are you talking about other virtual on-screen indicators? I don't interpret anything in the spec's language on indicators as being covered by the hardware light, but I'm open to be convinced otherwise. My 2 cents on the hardware light: A teleconferencing software I use regularly, lets me "mute" my camera which turns off my self-view and (presumably) stops sending video of me to the other participants, but it leaves the hardware light on. This makes me uneasy. It is probably safe, but I still find myself acting reserved until the call has ended. I would probably prefer a different teleconferencing software that didn't leave the light on during mute. I am open to learn otherwise, but I don't see why the spec needs to police UAs here. What are we afraid will happen? .: Jan-Ivar :.
Received on Thursday, 27 March 2014 16:12:39 UTC