Re: [mediacapture-screen-share] Add getCurrentBrowsingContextMedia (#148)

> An iframe only capturing itself would not cover some interesting use cases. For example, a document being presented to a VC, by embedding an iframe of the VC's application inside the document-editor application.

@eladalon1983 A security property I like about _"capture itself"_, is requiring explicit code in the capture target. Easy to grasp, ensures buy-in of the target, and no-one has to worry about being captured by other origins (except through the existing hyper-user-driven `getDisplayMedia` picker API).

I was even wondering about enforcing this by checking `current global object == relevant global object`, to enforce this:
```js
await iframe.contentWindow.navigator.mediaDevices.getDocumentMediaWhatever() // SecurityError
```

> Or a game capturing footage of itself by embedding an iframe which also contains code and visible controls for managing the capture, annotating it, and uploading it to a remote server, possibly one which streams it to remote viewers.

I don't understand this use of _"itself"_. Can't it put code in the parent as well, use postMessage etc? We seem to be making much stronger assumptions about the capture target's involvement elsewhere, e.g. _"Since the app can take for granted that the captured content is of itself, it knows how to crop sensibly"._

I feel strongly we shouldn't be over-capturing, only to create a need for inventing cropping APIs next.

I think we can lean on apps to use iframes to capture exactly what they want to send and no more. This is the web after all, so I'd aim for stronger integration than the existing modality. 

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/pull/148#issuecomment-736621543 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 1 December 2020 15:21:32 UTC