Contact emailselada...@chromium.org Explainer https://docs.google.com/document/d/1q3oGy7hLJmdQA4ZK7QG7DnwgtcpL6oB2pqLQJ6MP1tY/edit?usp=sharing
Specificationhttps://github.com/w3c/mediacapture-screen-share/pull/222/files Summary Hint indicating to the user agent whether the application, upon calling getDisplayMedia() with {audio: true} or similar, wishes *system audio* to be offered to the user. (If not - only offer tab-audio.) Blink componentBlink <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink> Motivation User agents may offer audio to be captured alongside video, if the application specifies {audio: true}, or maps audio to anything else that's different from false. But not all audio is created alike. Consider video-conferencing applications. Tab-audio is often useful, and can be shared with remote participants. But system-audio includes participants' own audio, and it is NOT desirable to share it back. State of the art? VC applications can ask for "audio", use it if it's tab-audio, and discard it otherwise. This works, but it's sub-optimal. The user is left confused. The user wanted to share system-audio, the user was offered to share-system, the user explicitly approved sharing system-audio - and now remote participants are telling the user that they can't, in fact, hear the system-audio. Now how confusing is that?! It’s better to allow applications to ask for less - allow the application to ask for non-system audio. Initial public proposal https://github.com/w3c/mediacapture-screen-share/issues/219 TAG reviewN/A. This is just an addition of a single flag to an existing dictionary, following well-known patterns. TAG review statusNot applicable Risks Interoperability and Compatibility *Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/638) Jan-Ivar Bruaroey from Mozilla, and Youenn Fablet from Apple, have both collaborated with us closely in shaping this PR. They have then approved merging this PR into w3c/mediacapture-screen-share. This is implicit support, so I'd consider it POSITIVE even though, as of the time of this writing, the official request for position has not yet been answered. *WebKit*: Positive ( https://lists.webkit.org/pipermail/webkit-dev/2022-May/032247.html) Jan-Ivar Bruaroey from Mozilla, and Youenn Fablet from Apple, have both collaborated with us closely in shaping this PR. They have then approved merging this PR into w3c/mediacapture-screen-share. This is implicit support, so I'd consider it POSITIVE even though, as of the time of this writing, the official request for position has not yet been answered. *Web developers*: Positive Endorsed by Google Meet. *Other signals*: Security This feature can only be used by Web applications to REDUCE the amount of private information they obtain from the user. As such, this is a net security gain. WebView application risks N/A Debuggability N/A Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?No Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1329129 Estimated milestones No milestones specified Anticipated spec changes N/A Link to entry on the Chrome Platform Status https://chromestatus.com/feature/4649448880734208 This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMO6jDNS3OAe7dD0rfLB7tqnLrfYAkDROr6OP2qWcToexbwWFA%40mail.gmail.com.
