Re: [mediacapture-region] Should we support strings in addition or in lieu of opaque identifiers? (#46)

> > But how can send a message to 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

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 using your GitHub account

Sent via github-notify-ml as configured in

Received on Thursday, 30 June 2022 21:28:09 UTC