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

> ... will allow a capturer to explore the inner structure of the captured page

Thanks @alvestrand for explaining. Being able to deduce information never intended for the screen seems at best surprising both to end-users and web developers. Since id strings _in theory_ can containing anything, this information could be part-guessable yet valuable I suppose, though in practice I think they only reveal the "structure", as you say. A valid item for the Cons column, I think.

At the same time, perhaps we should not give pages whose entire rendering output is captured a false sense of security — when is its structure not betrayed by its visuals? You mentioned an attacker would start from some "known" information about the victim site, so if this exploit can be polyfilled ontop of existing APIs, I'm not sure we have a (new) problem.

Also, with [getViewportMedia]( (the long-term API here), we're only talking about pages that have opted into capture with `Document-Policy: viewport-capture`. Id-based cropping seems fine then.

>  In our case, the iframe was ok with being embedded into the page, maybe this is a good enough restriction?

With [getDisplayMedia](, today's self-capture is unsafe and can hopefully be deprecated eventually End-users are already taking much greater security risks here, by allowing capture of cross-origin rendering to sites that are neither site-isolated nor restricted to opt-in-only iframes. Users make [faulty assumptions]( about those risks today: They don't know attackers can coax victim-iframes to render new information they'd never expect. So expectations about what can and can't be exposed seem meaningless here.

I'd like to get to a place where previous mistakes no longer informs new APIs.

GitHub Notification of comment by jan-ivar
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 22:43:04 UTC