W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > May 2022

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

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Fri, 13 May 2022 22:50:07 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1126560902-1652482205-sysbot+gh@w3.org>
> > > 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-config
Received 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