Re: [mediacapture-screen-share] Identification of Captured Application By Capturer (#166)

In general, I like the idea of actions.
In terms of scope and role sharing between specs/WGs, I think we should try to not build our own actions.
Instead I would try to piggy back on, which might move some of the corresponding API from MediaDevices to MediaSession.
If feasible, getDisplayMedia would be a boostrapping mechanism to potentially get access to MediaSession proxies.
Other APIs in the future could well allow to expose the same proxies.

I am also interested in the trust model, which probably applies to both CaptureHandle and actions.
In general, it seems desirable to know the origin of data you are processing, which would translate in something like:
- capturer knows capturee origin if processing some information from capturee.
- capturee knows capturer origin if processing some information from capturer.
Depending on the API shape, interaction with transferring MediaStreamTrack might be useful to study.
Rate limiting could be enforced by the API (only one action being processed at a time, capturee can tell when the action is done to capturer).

Another approach would be to state that the UA is the entity sanitising capturer/capturee relationship.
In which case, the UA would be the one triggering action event handlers on behalf of capturer and potentially doing rate limitations. Capturee would not even need to do anything other than register MediaSession callbacks.

> @youennf, @aboba and everybody else: What do you think? Would you support the adoption of [Capture Handle]( if we add these mechanisms?

Can you clarify what the proposal is?
Is it that we would work/adopt one spec that would define both capture handle and actions?
Or that we would work/adopt two specs roughly at the same time, one for capture handle and one for actions?

I would personally be inclined to split the work in two different specs given the scopes seem to be different enough.

GitHub Notification of comment by youennf
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Friday, 14 January 2022 11:30:11 UTC