search

w3c / mediasession

Media Session API
https://w3c.github.io/mediasession/
Other
128 stars 30 forks source link

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

Open jan-ivar opened 2 years ago

jan-ivar commented 2 years ago

Quiz:

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 commented 2 years ago

Original discussion in https://github.com/w3c/mediasession/issues/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 commented 2 years ago

@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 https://github.com/w3c/mediacapture-extensions/issues/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:

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 commented 9 months ago

This came again when discussing https://github.com/w3c/mediacapture-extensions/issues/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 commented 9 months ago

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 commented 7 months ago

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 commented 7 months ago

@jan-ivar, I wonder whether a note would cover the concerns, given https://github.com/w3c/mediasession/pull/313 and https://github.com/w3c/mediasession/pull/312 landed.