> > > the iframe was ok with being embedded into the page, maybe this is a good enough restriction? > > > > ... that seems to be a very liberal restriction when dealing with cross-origin iframe's internal structure.. > > Probably ... there are ways to fix this (opt-in via requiring to pass the environment id in cropTo, or additional API... I was suggesting opt-in as well, but it leaves the core problem unaddressed though, which @alvestrand expressed: > the page author has no reason to believe that those elements[' ids] are cross-origin exposed. This seems true and surprising even with opt-in. By not accepting element id as input to `cropTo` we avoid this class of problems, which seems beneficial regardless of other classes of (bigger¹) problems. I'm convinced. --- <sub>1. The "bigger problem" being: the same page author has no reason to believe data and resources they render are cross-origin exposed — Hopefully our concerns for page authors will be applied equally here and to speeding up implementation and migration to the safer [getViewportMedia](https://w3c.github.io/mediacapture-viewport/#dom-mediadevices-getviewportmedia)!</sub> -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/11#issuecomment-1126560902 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-configReceived on Friday, 13 May 2022 22:50:08 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:57 UTC