- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Feb 2022 08:53:23 +0000
- To: public-webrtc-logs@w3.org
> I'm OK with this idea. Consider `excludeSelf` as the name, though that leads to questions about the effect on tab, window, and display in that it might prevent display capture entirely for those people who only have one display (i.e., most). Interesting idea with `excludeSelf`. Thinking out loud: * If we make it refer specifically to excluding the current tab, it would be misnamed to the point of confusing developers. * If we make it exclude all "self" surfaces - current-tab, current-window **and** current-screen - then I'd be concerned that many video conferencing software would simply not use it. (Current users often share the whole screen, and VC software would not wish to lose users.) I think it might be interesting to also have distinct controls for `excludeCurrentTab`, `excludeCurrentWindow` and `excludeCurrentMonitor`. Either that, or a single cumulative enum value, e.g. `exclude=` and then `currentTab`, `currentTabAndWindow`, `currentTabWindowAndScreen`. **Devil's advocate against my own idea:** Would a proliferation of selection-limiting controls go too far and allow an application to tip the user's hand towards a specific surface? **Answer:** With any type of self-capture, a malicious application can directly embed what it wishes to capture. So self-capture is equivalent there to forced-capture. With one exception - native apps. But that seems like an unlikely attack for me, as a malicious application would likely much prefer self-capture through the browser window, than capture of an arbitrary native app. Your thoughts? -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/209#issuecomment-1048562181 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 February 2022 08:53:25 UTC