- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 May 2022 12:21:05 +0000
- To: public-webrtc-logs@w3.org
@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 element.id 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 Element.id + https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-id (already exposed in some APIs like service workers or web locks), so that guessing the Element.id 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 https://github.com/w3c/mediacapture-region/issues/11#issuecomment-1123684809 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 May 2022 12:21:06 UTC