- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Dec 2020 17:39:34 +0000
- To: public-webrtc-logs@w3.org
> The service provider should not, IMHO, be forced to the decision of either not trusting the (specific) third-party it at all, or trusting it enough to allow it to run same-origin. @eladalon1983 but this feature undermines many of the same-origin protections you get from iframing in the first place. > ... Allows the application the knowledge of the contents of the capture, ... Right, and this knowledge adds risk. #### Whatabout getDisplayMedia? While `getDisplayMedia` already has this problem _**IF**_ the user chooses the same tab, at least that scope violation is 100% user-driven, and some form of social engineering is needed to make it a reliable exploit (it doesn't help that Chrome fails to warn about this when it [should](https://w3c.github.io/mediacapture-screen-share/#elevated-permissions)). I think it's fair to say `getDisplayMedia` is flying [close to the sun](https://github.com/w3c/mediacapture-screen-share/blob/gh-pages/questionnaire.md) already and exists because it is backed by such a highly compelling use case (web conference presentations). If you were to ask me if I think it has too many security mitigations, I'd say no. That's why I don't find it compelling to remove any of them. I do however find the idea of enabling apps to stream themselves into web conferences appealing, provided it can be integrated safely. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/pull/148#issuecomment-737385649 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 December 2020 17:39:35 UTC