FYI that there's a new Chromium/Blink I2S citing this review; if the TAG wants to weigh in, the time is now:

https://groups.google.com/a/chromium.org/g/blink-dev/c/Iaoq0CYadzo/m/4NcvzdVqFwAJ

Thanks for submitting this work. We have the following concerns regarding this spec and request clarification:

1. The spec should require that the mute trigger be origin-bound and device-bound. (This is for consistency with Media Stream permission policy requirements.)

2. Whether using getUserMedia() or the latest version of this proposal, every app that offers to "mute" a device retains the prerogative to unmute that device at any moment. Do you see any opportunities to provide security guarantees to users, that their camera will not suddenly be re-activated without their consent? (following the encoureged behaviour in Media Stream permission policy)

We feel that there should be potential for UA interaction to reassure users that once their camera/audio is muted, it will not be suddenly re-activated without their consent. Does this design leave some space to explore solutions to this problem? Do you think it would be possible to standardize such guarantees?

3. This spec will fomalise the following action-sequence: mute → unmute → mute. As the mute action is already fomally defined in Media Capture and Streams. We request the spec developers consider a clear definition for the action sequence to avoid confusion.

Furthermore, we have some observations regarding the explainer:

• There are two links included: one related to PEPC (which was a separate TAG review) and another for <usermedia>. The explainer for the latter, which we assumed is the focus of this review, does not follow the standard format. It lacks sections such as "S&P considerations" and "alternatives considered" - these are important in order for readers and reviewers to understand the trade-offs made during the design of the proposal. Can you please update the explainer to be consistent with the explainer format?

  Note: You may find the similar discussions in the <geolocation> explainer helpful.

Thanks for taking a close look! I see three concerns regarding the 'mute trigger': We have taken this out of the spec & and out of our implementation, because several aspects of the desired behaviour were unclear, and there was no agreement with the WebRTC editors on the details. Progress on that topic is tracked here: https://github.com/w3c/mediacapture-extensions/issues/170

I think we should have also taken this aspect out of the explainer. But looking back, it's probably fortunate because now we have additional input on this topic.

1. The spec should require that the mute trigger be origin-bound and device-bound. (This is for consistency with Media Stream permission policy requirements.)

Whether it's bound to the stream or the device was one of the open questions. I think we now have one more vote to make it per-device.

2. Whether using getUserMedia() or the latest version of this proposal, every app that offers to "mute" a device retains the prerogative to unmute that device at any moment. Do you see any opportunities to provide security guarantees to users, that their camera will not suddenly be re-activated without their consent? (following the encoureged behaviour in Media Stream permission policy) We feel that there should be potential for UA interaction to reassure users that once their camera/audio is muted, it will not be suddenly re-activated without their consent. Does this design leave some space to explore solutions to this problem? Do you think it would be possible to standardize such guarantees? Generally, the idea is that the user media capture elements would reflect the true state of the underlying stream or device: If e.g. the stream gets un-muted by API calls, the element should show it as un-muted. This matches the guidance you have linked.

Regarding a guarantee to disallow un-muting when the user has explicitly muted a stream: This is a good idea. I don't think this was considered, but I think we'd be happy to.

I expect all effects of the user media capture elements to correspond to Media Capture and Streams API capabilities. I think this would boil down to having some sort of 'hard mute' in the Media Capture and Streams spec, which I don't think is a capability that spec currently supports. It's IMHO worth considering.

I do see a risk for user experience, though: If a site uses the new media element capture elements, but also has some traditional UI that uses WebRTC APIs -- e.g. it uses <usermedia> to start a video conference, but also has traditional UI controls -- then it might run into the trap where a mute via the <usermedia> button mutes a stream, and the existing UI calling into Media Capture and Streams might no longer work as expected because the API-based unmute is "weaker" than the button based one. Maybe this can be resolved in some fashion; but it'll certainly require some care.

3. This spec will fomalise the following action-sequence: mute → unmute → mute. As the mute action is already fomally defined in Media Capture and Streams. We request the spec developers consider a clear definition for the action sequence to avoid confusion.

Yes, I agree. As mentioned above, I expect all actions of the media capture elements to be exclusively defined in terms of the Media Capture and Streams specification. Hosting the usermedia element specification alongside Media Capture and Streams extensions at https://github.com/w3c/mediacapture-extensions/ (rather than our WICG repository, https://github.com/WICG/PEPC) supports that goal.