- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Jun 2022 21:28:07 +0000
- To: public-webrtc-logs@w3.org
> > But how can youtube.com send a message to meet.google.com? Enter shared cloud infrastructure... > > So vimeo users will continue to get their playlists shown. Unless vimeo also participate by sending API messages to an open meet.google.com. I am calling into question your basic premise. I don't believe that a non-negligible number of sites would ever send stringified CropTargets optimistically, because that's just too expensive, and the upside is nil in 99.9999% of the cases. I think the only case where CAPTUREE would send CAPTURER a CropTarget, is if: 1. CAPTUREE and CAPTURER already trust each other. 2. CAPTUREE and CAPTURER are often used together, e.g. if they are part of a bundled offering. 3. **Key requirement**: Through a pre-existing channel, CAPTURER has alerted CAPTUREE to the existence of a capture session, thereby **soliciting CropTarget with a pre-existing well-defined meaning that both sides understand as mutually useful.** That means that a video-conferencing app could expose user-facing controls to `focus on video`/`share entire tab`. Without a well-understood semantic for the CropTarget, it is useless. The user does not understand `apply CropTarget`/`remove CropTarget`. Sane apps are not going to expose to the user unknown CropTargets that they had received over an open API that arbitrary sites can trigger. As such, I still hold that the risk of tracking by soliciting the entire Web to send you CropTargets is unfounded. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/46#issuecomment-1171695938 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 30 June 2022 21:28:09 UTC