- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Fri, 02 Sep 2022 13:41:56 +0000
- To: public-webrtc-logs@w3.org
> Your past message says that tricking a user to click will allow the web page to focus to the capturee page. > My question is what are the scenarios where you think this behaviour will be exploited for bad reasons. I am not sure where the unclarity lies. Two options have been discussed: 1. Focus yes/no can only be decided right after getDisplayMedia() resolves. 2. Focus yes/no can be decided at an arbitrary point. I have explained the dangers inherent to 2, and explained that therefore, only 1 is in scope for me. The danger of 2 has be clarified. If we were to implement 2, an attacker could cause the user to click inside the captured page, at a location of the attacker's choice. This risk does NOT exist with 1 to any credible extent. I hope this answers the question? > Why is not focusing the less risky behaviour? Because the user keeps seeing the same page they had manually focused before, and with which they had interacted, and which would still be the active page if not for the getDisplayMedia() call. > Isn't it more risky to leave the user without any preview of what is being shared? The user DID see a preview, as [previously discussed](https://github.com/w3c/mediacapture-screen-share/issues/230#issuecomment-1234053014). If you want to mandate a preview in the spec, we can do that. > Also, it seems wrong if the more risky behaviour is the default behaviour. It's the existing behavior for all supporting, but I am willing to specify differently if that helps drive us reach consensus. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/230#issuecomment-1235521505 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 2 September 2022 13:41:58 UTC