- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Fri, 16 Apr 2021 21:00:53 +0000
- To: public-webrtc-logs@w3.org
> > The security properties don't seem significantly different to me. > > When approving getViewportMedia, the user would be giving permission to capture an arbitrary number of frames, and each one is handed off to the application before the user has the time to inspect them, let alone modify them. The application might even capture two radically different frames and present only one of them to the user as a way to mislead them. > > It would be a shame to "educate" otherwise savvy users, who understand the dangers of approving video-capture of a screen, that "sometimes you simply have to accept video capture." Our mandate is to _fix_ the _"dangers of approving video-capture"_, not educate users to stay away from it. The _"dangers"_ in *getViewportMedia* are mitigated by site isolation, capture opt-in and permission prompt. I think that's sufficient. But if you don't then I'm listening. > > we'd want to require site-isolation and html-capture opt-in, just the same, I think > > I will defer taking a strong position here until I've had time to discuss the matter with Chrome Security. Let's order the possible APIs by LOW to HIGH risk: 1. captureScreenshot() (isolated + opt-in) 2. getViewportMedia() (isolated + opt-in) 3. captureScreenshot() (not isolated) 4. getDisplayMedia() (not isolated) If you're arguing for 3, based on it being safer than 4, then I don't think that warrants a new API, because it's worse than 2. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/160#issuecomment-821562028 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 16 April 2021 21:00:55 UTC