Revisit: Rejecting audio-only capture

[eladalon1983]

If the user agent shows the same type of prompt for audio-only capture, and the same type of persistent onging-capture indicators, what's the purpose of forbidding "videoless" captures?

[jan-ivar]

I would follow getDisplayMedia precedent here. We've had this discussion there before, and I think the same arguments apply here.

[jan-ivar]

It would be useful to learn of use cases that would be compelled to ask for video self capture but is only interested in audio, that wouldn't be better served by using web audio and existing tech.

I think driver for self-capture has been video, because reinventing HTML layout in canvas was deemed to be a worse solution for many use cases that want to stream a rendered composite of say a video meeting.

[eladalon1983]

I would follow getDisplayMedia precedent here. We've had this discussion there before, and I think the same arguments apply here.

I don't think that discussion has been settled. There's way more Web-developer interest on w3c/mediacapture-screen-share-extensions#12 than that repo has seen in a while.

It would be useful to learn of use cases that would be compelled to ask for video self capture but is only interested in audio, that wouldn't be better served by using web audio and existing tech.

1. I believe I have presented the general usecase before. Imagine you're embedding cross-origin content like a YouTube clip, and you want to get its audio, but you don't want to set up a bespoke way for you to ask YouTube to send you audio and for you to receive it.
2. When discussing changes that would allow the user to grant LESS permissions, I think the usefulness test is much different. Assume there are interesting usecases, but we fail to think of them now and we misguidedly disallow audio-only. What then? Now those legitimate sites ask users for audio+video, where only audio would suffice. Who gains?

[youennf]

To make progress on this issue, I'd like to understand what the security and privacy model is for capturing tab audio using getViewportMedia and the differences with getDisplayMedia.

For instance, for getDisplayMedia, the user has to opt-in to audio as part of the prompt, separately from video.
Is there the same requirement for getViewPortMedia?

Is getViewPortMedia audio handled by a separate permission from getViewPortMedia video?
Is there even a need for a getViewPortMedia audio permission given the current getViewPortMedia security model?

What are the pros/cons of having tab audio capture within getViewPortMedia vs. a separate API?