search

w3c / mediacapture-viewport

Specification for getViewportMedia, an API to capture the content of a browser viewport.
https://w3c.github.io/mediacapture-viewport/
Other
6 stars 4 forks source link

Revisit: Rejecting audio-only capture #11

Open eladalon1983 opened 2 years ago

eladalon1983 commented 2 years ago

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

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

jan-ivar commented 2 years ago

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

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 https://github.com/w3c/mediacapture-screen-share-extensions/issues/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 commented 2 years ago

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?