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

> 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.

There are two core issues addressed in this thread, which I'll call "identity" ([original proposal]( and "actions" ([additional mechanisms]( I also **prefer** splitting the work, but I **tentatively propose** addressing both issues together as an attempt to reach a compromise with @jan-ivar. To avoid risking misrepresenting his position, I'd like to ask @jan-ivar to explain why he thinks the two should be combined.

Clarifying my [question]( about support - it's an open ended question. Would you support either part (identity/actions)? Both? Only a certain mix? I hope that you'll be amenable to the identity part at least, @youennf, as the design was much influenced by your earlier input. :-)

> Instead I would try to piggy back on, which might move some of the corresponding API from MediaDevices to MediaSession.

Could you please clarify your proposal here?
Please note that:
* Some applications will want to treat actions differently if they come from the user ([MediaSession]( IIUC), compared to if they come from a capturing application (might be piping the user, might not).
* The [MediaSessionAction]( enum includes some actions (e.g. `seekto`) which require more information than we can assume the capturer/capturee have exchanged.
* The [MediaSessionAction]( enum includes some actions (e.g. `togglemicrophone`) which IMHO appear inappropriate in our context.

> In general, it seems desirable to know the origin of data you are processing

It's an interesting issue, and might not have the same answer for both directions.
1. The original part of Capture Handle (identity) allows the capturee to select whether it wishes to expose its origin. I think this is simple and flexible enough, because capturers that intend to trust only a given set of origins, will find that `undefined` does not match any origin on their allowlist. So conditional exposure here is both desirable (discussed earlier) and ergonomic (likely no code changes needed in the app compared to when origin-exposure is mandatory).
2. For actions the capturee receives from the capturer, I think it's reasonable to either expose, not expose, or conditionally expose the origin of the sender. I have no strong conviction here, and would be happy to align with whatever others agree on.

> Capturee would not even need to do anything other than register MediaSession callbacks.

I believe that's equally true for all proposals currently under discussion (modulo declaring capabilities, discussed below).

> In which case, the UA would be the one triggering action event handlers on behalf of capturer

The idea behind the [current actions-proposal ]( is that the capturing application can expose its own custom, in-content controls for the intersection of controls supported by the capturer and the capturee. So, for example, if Zoom captures Slides, it could expose `next`/`prev`, but if it captures YouTube, maybe it also exposes `mute` (mute-shared-tab, that is). I think this is preferable UA-based controls. But possibly I have misunderstood your point?

GitHub Notification of comment by eladalon1983
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 14:26:14 UTC