Re: [mediacapture-region] Why expose produceCropTarget at MediaDevices level? (#11)

@eladalon1983, I am not sure what you are trying to point at. In any case, one scenario would be to use getElementById, something like: postMessage the ID from frame A to frame B. Then, when frame B wants to get info on the element (say its CSS class, its name...), frame B postMessages to frame A with the ID, frame A calls getElementById, gets the necessary bit of information and postMessages it back to frame B.

> This is the kind of side effect without a security evaluation that I've been warning about when arguing in favor of a new ID scheme.

Right, I think this is the kind of things that would be good to validate.
Note though that is not sufficient, we need a reference to the document. In our case, the iframe was ok with being embedded into the page, maybe this is a good enough restriction?
I guess we could enforce cropTo to take a combo + (already exposed in some APIs like service workers or web locks), so that guessing the is not sufficient, the iframe would have to explicitly transmit its own env ID. That would also solve the general case, as well as @eladalon1983 CropTarget stringification issue.
That said, the first thing would be to identify what we are trying to protect from, which I am still not very clear about.

GitHub Notification of comment by youennf
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Wednesday, 11 May 2022 12:21:06 UTC