- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Jun 2021 14:59:38 +0000
- To: public-webrtc-logs@w3.org
> controlling an app Apologies if I was unclear. I'm describing user experience. When everything works, users are controlling what appears to be a shared app, and will form a mental model around what they are sharing based on that (they click "Present", find their presentation by name or thumbnail, share "it", and control "it"). This is a _desirable experience_, and I don't fault services for wanting to provide it. But I'd fault us for providing it without first addressing the security misconceptions underlying it: The security just isn't there to provide this experience safely just yet. The only tip-off to the lack of seat-belts is some tech prose in the prompt, and _maybe_ some pause in a user's mind about why their choice seems buried in the picker. This is still cooking with a blowtorch, and I think it's premature to add a kitchen timer to it. > The reverse could also be argued - that by keeping the user away from the captured tab, unintended navigation by clicking back too often becomes far less likely. An interesting argument, but this might also make users think the audience sees only the actions they make in the VC tab, not the target tab. Unless you're planning to freeze direct interaction with the target tab during capture, I think this is a net loss addressing oversharing concerns. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/182#issuecomment-854795097 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 4 June 2021 15:01:52 UTC