Camera light and "disabled" tracks

[alvestrand]

In current implementations, we mainly use the camera light as an "on-air" indicator.

At the moment, the spec says:

Turning on: If the result of the request is "granted", User Agents are encouraged to include a prominent indicator that the devices are "hot" (i.e. an "on-air" or "recording" indicator), as well as a "device accessible" indicator indicating that the page has been granted access to the source.

Turning off: A script can indicate that a MediaStreamTrack object no longer needs its source with the stop() method. When all tracks using a source have been stopped or ended by some other means, the source is stopped...... If the data is being generated from a live source (e.g., a microphone or camera), then the User Agent should remove any active "on-air" indicator for that source.

Disabling: A muted or disabled MediaStreamTrack renders either silence (audio), black frames (video), or a zero-information-content equivalent. For example, a video element sourced by a muted or disabled MediaStreamTrack (contained within a MediaStream ), is playing but the rendered content is the muted output. When all tracks connected to a source are muted or disabled, the "on-air" or "recording" indicator for that source can be turned off; when the track is no longer muted or disabled, it must be turned back on.

Disabling is a Javascript-controllable function, using the "enabled" attribute of a track.

(Note that it says "can be turned off" and "must be turned back on" - so keeping the light on is legal.)

Two worries with this wording:

• Privacy: Disabling the track and having the light go out leads to a malicious application being able to turn on the camera briefly to take a picture at any later time, possibly without the user noticing because the indicator flash is so brief.
• Practicality: For a certain class of drivers, turning the light off means closing the camera. Re-opening the camera will take significant cycles, and having the camera device released means losing what little guard we have against some other app stealing the camera while it's closed.

Suggestion: Change the language in the third quote above to read:

"When all tracks connected to a source are muted, the "on-air" or "recording" indicator for that source can be turned off; when the track is no longer muted, it must be turned back on. When the track is disabled, but not muted, the "on-air" or "recording" indicator should still be on, to indicate that the device is still available to the application at any time."

Thoughts?

[stefhak]

The current text allows applications to work well even if there are no stored permissions: if the application disables the track the camera light goes out. If the application would have to stop the track to accomplish that, the user would have to accept the use of the camera once video is desired again.

I think privacy is not an issue with the current spec text, it says When all tracks connected to a source are muted or disabled, the "on-air" or "recording" indicator for that source can be turned off

so if the app briefly enables, takes a picture and then disables the UA is allowed (and probably should) to keep the light on a bit longer (and should probably keep it lit permanently if this happens more than once).

I have greater sympathy for the driver+closing camera issue, but I don't think we should make it less appealing for apps without stored permission to behave well.

[jyasskin]

What's the purpose of a disabled track? Presumably it's straightforward to synthesize an all-black track and swap it into place if you really want to keep the camera open, and disabling is for when you actually want to stop using the power that an "on" camera costs? If so, then maybe enabling should be spelled with a function that returns a Promise instead of with a simple assignment.

[alvestrand]

Swapping tracks is far less simple than disabling a track. How much power are we talking about for leaving a camera on?

[jyasskin]

http://www.hotmobile.org/2013/papers/full/17.pdf says about .5 to 1 watt? I have no idea if that's measured well or still correct.

[jan-ivar]

The spec is not talking about the camera light. Not all cameras have lights, and when they do, they may not always be pointing at user, and may not be visible. Microphones don't have lights.

The spec is talking about both cameras and microphones in all the text quoted, and is talking about in-browser indicators, which all implementations have AFAIK.

The spec language appears to already have some fidelity here, distinguishing between two indicators: "on-air recording" and "device accessible". The spec says the first one can be dropped during mute. It does not say the second one can be dropped. This seems to cover the privacy concern to me.

The first one, from its names warns about the device actually being on and recording. Since we're not recording if we're muted, dropping it, as the spec allows, makes sense, so I believe that's its definition.

About the second one, little else is written, and we should probably fix that. But taking a guess, the only other concern I could see a user having that may warrant an indicator, would be to warn of a site's power to resume recording.

For a browser without persistent permissions - and the spec has to make sense for those as well - the natural conclusion is that this second indicator would go away when the track stops, the point at which it can no longer resume recording (the spec fails to mention this, it probably should).

Of course a UX may combine these two indicators into a single one, say a camera icon that's visible during access, with an optional slash through it (four states).

Wrt persistent permissions, one could argue when it says "granted access to the source" whether "access" means "permission" as opposed to "accessing device" - and that might, as with persistent permission, a site may also "resume" recording at any point, so to speak - though no current implementation appears to have such an indicator on pageload for pages with persistent permission already (Chrome has a camera icon in the URL field which lingers after access ends, but not before it starts, though it has a function, so not sure about its signal intent).

I've already filed https://github.com/w3c/mediacapture-main/issues/387, maybe we could mention when "device access" indicator should go away there?

[alvestrand]

Agreed with the conclusion that the camera light is neither of our indicators, but may sometimes vary when one of the indicators does. Implementation advice should probably say that.

@jan-ivar do you want to make a PR for the language describing the indicators?

[alvestrand]

Being worked out as part of the permissions cluster (including language about what device lights should track).

[alvestrand]

We need to check if this is resolved when #411 is merged.

[alvestrand]

Solved by #421