Privacy issue: is it a good idea to let webapps lie about camera/mic ON/OFF on a user's lock screen?

[jan-ivar]

Quiz:

• A toggle on your lock screen says microphone is OFF. Can web apps hear you?
• A toggle on your lock screen says camera is OFF. Can web apps see you?

If a browser implements this spec verbatim, they can.

togglecamera and togglemicrophone are misnomers: they don't limit camera or microphone access to the webapp at all. Instead they let any webapp control what the lock screen says about the user's microphone and camera, whether true or not.

This seems concerning from a privacy perspective.

It's useful: it lets well-behaved video conferencing apps show on your lock screen that you're on a call right now and whether participants can hear and see you or not (hopefully not if you've arrived in this situation).

But the spec needs to call this out in its Privacy and Security Considerations which doesn't mention this.

Also, some of these risks were hard to make out in the current rosy prose:

"The setMicrophoneActive(active) and setCameraActive(active) methods indicate to the user agent whether the microphone and camera are currently considered by the page to be active (e.g. if the microphone is considered "muted" by the page since it is no longer sending audio through to a call, then the page can invoke setMicrophoneActive(false))."

This "e.g." suggests the page is no longer sending audio through a call, and "then" can invoke setMicrophoneActive(false)). As normative language, this is confusing. It should be a note. Also, the fact that the page can invoke setMicrophoneActive(false) at any time with any value it wants, also seems worth mentioning.

"The user agent MAY display UI which invoke the handlers for the togglemicrophone and togglecamera media session actions, and it is RECOMMENDED that the user agent respect the microphone and camera states indicated by the page in this UI."

It might be better to RECOMMEND the user agent not overstate the significance of these web application states and their correspondence to reality.

[chrisn]

Original discussion in #264. I agree with the concerns here. This may be a naive question, but why does the page need to handle these actions, rather than the UA handling them and notifying the page of the new camera / microphone state?

[jan-ivar]

@chrisn an excellent question. To simplify, let's look only at the microphone dimension (camera is symmetrical):

Only Safari implements user agent mic-mute atm, and web apps can listen to mute and unmute events to react. But a generalized solution requires solving the double-mute problem w3c/mediacapture-extensions#39 with better integration.

If we solve that, then yes, we could have lock screen cam/mic toggles that worked that way instead (with teeth).

But it would require better integration with video conferencing apps, because:

• Only the video conferencing web app can authoritatively say "participants can hear you"
• Only the user agent can authoritatively say "you're not being recorded"

IOW if you're on a call, these apps would need to integrate their current "don't send audio" state to match the UA mic state, so that participants immediately hear you when you turn on mic from the lock screen, and not have a separate state for that.

[youennf]

This came again when discussing w3c/mediacapture-extensions#39.
Maybe we do not need this API at all and should remove it.
It would help to understand how it is supposed to be used and whether it is used by web apps today.

[jan-ivar]

The intended use is for the app to maintain state and update it in response to UA "toggle"s. An abbreviated example 6:

let isMicrophoneActive = false;

navigator.mediaSession.setActionHandler("togglemicrophone", () => {
  navigator.mediaSession.setMicrophoneActive(isMicrophoneActive = !isMicrophoneActive);
  // Hope the app actually mutes or unmutes the microphone.
});

The privacy issue is setMicrophoneActive(false) showing browser UX claiming the microphone is off even if it isn't.

1. UAs could control this today by muting the app's tracks in response to setMicrophoneActive(false), but don't.

2. UAs could unmute the app's tracks again in response to setMicrophoneActive(true) if called in response to the user unmuting in the browser.

3. The issue is how to unmute in response to setMicrophoneActive(true) from the user unmuting in the app, without defeating privacy.

Or is that an implementation detail? (e.g. if it has user attention and transient activation, maybe it just works, raises a toast message, or a prompt?)

[guidou]

The intended use is for the app to maintain state and update it in response to UA "toggle"s. An abbreviated example 6:

let isMicrophoneActive = false;

navigator.mediaSession.setActionHandler("togglemicrophone", () => {
  navigator.mediaSession.setMicrophoneActive(isMicrophoneActive = !isMicrophoneActive);
  // Hope the app actually mutes or unmutes the microphone.
});

The privacy issue is setMicrophoneActive(false) showing browser UX claiming the microphone is off even if it isn't.

1. UAs could control this today by muting the app's tracks in response to setMicrophoneActive(false), but don't.
2. UAs could unmute the app's tracks again in response to setMicrophoneActive(true) if called in response to the user unmuting in the browser.
3. The issue is how to unmute in response to setMicrophoneActive(true) from the user unmuting in the app, without defeating privacy.

Or is that an implementation detail? (e.g. if it has user attention and transient activation, maybe it just works, raises a toast message, or a prompt?)

How do you know what the initial state is?

[youennf]

@jan-ivar, I wonder whether a note would cover the concerns, given #313 and #312 landed.

[youennf]

Would the note from #312 be sufficient:

The setMicrophoneActive(active), setCameraActive(active) and setScreenshareActive(active) methods can reject based on user agent specific heuristics. This might in particular happen when the web page asks to activate (unmute) the microphone, camera or screenshare. The user agent could decide to require transient activation in that case. It might also require user input through a prompt to make the actual decision.