- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 11 Mar 2022 08:26:59 +0000
- To: public-webrtc-logs@w3.org
> When doing whole-screen-capture, obfuscation helps with Hall of Mirrors. But it's **not at all useful** for tab-capture, because in that case, **the entire track** would be obfuscated. For self-tab-capture, Hall of Mirrors can be mitigated by the web page itself: region cropping, not previewing the captured stream... As I said before, the goal of this property is not to solve Hall of Mirrors, but to solve the case of a web app wanting any surface but current tab. This might be a fine goal. As long as we start with having this as a hint, this seems fine to me. We can always add stronger wording, say when getViewPortMedia becomes a thing. > The current tab is almost always under the attacker's control. > Other tabs - not as often. Yes, but the current tab is only able to embed iframes, which are much much less frightening. These days, cookies get partitioned, sites are protecting themselves from being embedded. Through social engineering, it might be easy to train user to select self tab for instance. Then the attacker could do something like: 1. Attacker opens a new tab, attacker knows the new tab is next to the current tab and will be next to the current tab in screen picker. When user is back to the current tab, attacker navigates the tab to a same origin page similar to current tab. 2. call getDisplayMedia with prefer tab surface + excludeCurrentTab. User thinks it is selecting the current tab (the only one with the attacker's origin, and preview is ok) but is in fact selecting the new tab. Of course attacker makes sure to disable focus so that user remains on the current tab, which removes an additional defense. 3. Attacker can now navigate the new tab (which was never visible to the user from the start of the capture) to more interesting websites and harvest plenty of first-party data. Given the potential increase of APIs to control UX (picker hints, conditional focus), I think we should strengthen the privacy/security considerations with regards to tab capture, in particular when capture continues across cross-origin navigations. Something like: - More clearly describe the specific risks of tab capture. Include the new APIs in the tab capture risk analysis - Describe existing or potential mitigations: make it clear which tab is being captured, make it clear tab capture has changed origin, mute/disable in case of (silent) navigations until user can properly notice it... Doing this effort will allow a collective assessment from the WG that we are not slowly weakening our privacy/security story. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/209#issuecomment-1064884908 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 11 March 2022 08:27:01 UTC