Elad Alon

> I disagree here, it does not make sense to do stringification on top of CropTarget. If the WG validates the use cases/support of strings, it seems best to deprecate...

> With a UUID/String you have to do a lot more thinking about how it got to you before you decide to trust it. I don't think the benefit is...

> there are many more ways that a uuid could arrive in my app and be manipulated/tracked on the way Assume we specify: 1. Serializing the same CropTarget multiple times...

> From the point of view of the recipient of a cropTarget (e.g. a video conference app), I claim it is much easier to be sure that it is genuinely...

Here is an alternative version of the attack you proposed, which would not require any CropTarget. It works equally well with today's means: 1. [Different step] Demand that all sites...

> CropTarget UUIDs are lightweight and offer apparent user benefits. My point is that you can get all the user benefit without the risks by keeping it as an opaque...

> look at how likely the risk is to occur. Video conferencing is big in our world, but it's not so big that Wikipedia and other non-video-conferencing sites would worry...

As for legitimate purposes for sending CropTarget optimistically to unknown capturers - if these purposes are truly legitimate, then the real question is - how do we provide them in...

> > 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...

> what if the CropTarget UUID was also made visible as a property of the track. Do you mean a property of the track via being a property of Capture...