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

> If this API gets useful for slides, I can see it useful for other cases as well, so we might end up with more actions.
> ...
> If we take the approach to add specific actions, I do not want to end up in a place where we duplicate the work with MediaSession.

MediaSession is a rich spec that offers much more than sending simple actions. I think the duplication of work is quite minimal. I have not yet heard what entanglement with MediaSession would improve.

> The CaptureHandle's proposal is adding a one way communication from capturer to capturee.

It's the other way around.
**Identity:** Message from capturee to capturer. Normally one-off, with a change (new message) when the capturee navigates.
**Actions:** Message from capturer to capturee. Often repeating.

> The action's proposal is most probably also creating a two way communication channel between capturer and capturee

Looks pretty one-way to me. See explanation above. Each part (Identity, Actions) produces a distinct one-way communication channel. These APIs (Identity, Actions) are useful both in isolation as well as together. One session can involve one, the other, neither, or both.

> > I'd rather avoid adding another messaging channel to the platform
> The same privacy/security risks...

I'd like join @jan-ivar's objection to adding more generic message channels. Before we dive too deep into the discussion of whether it's secure, I think the onus is on you to show it's desirable to add a generic messaging channel where a limited one would do.

> I do not think it requires the same tight cooperation.
> Capturee can define its own protocol without knowing capturer. It is up to capturer to be able to understand and implement this protocol.

@youennf, I believe these two lines contradict each other. The second line explains the necessity of a mini-protocol for both approaches (my Identity, your [MessageChannel-based communication approach]( Namely, that even if the mini-protocol is as simple as a stringified JSON with a single key-value pair, e.g. `{name: "Wikipedia"}`, this is something that the capturer must understand.

> If this way of communication is not good, can you explain why and according which criteria?

When applications share a cloud infrastructure, it might be preferable for the developers to go through some **pre-existing** RESTful API than to add code in the capturee to handle messages from the capturer. Especially if the captured application does **not** wish to assume that the local user delegates their permissions in captured-application to capturing-application just by allowing it to display-capture. Since the captured-application will still treat messages from the capturing-application as suspicious (the local user might only have partial understanding of what display-capture allows here), it's easier to use pre-existing mechanisms for access-control, than to replicate them for yet another communications channel.

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 Monday, 31 January 2022 18:23:29 UTC