- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Mon, 31 Jan 2022 18:23:27 +0000
- To: public-webrtc-logs@w3.org
> 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](https://github.com/w3c/mediacapture-screen-share/issues/166#issuecomment-1016301880)). 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 https://github.com/w3c/mediacapture-screen-share/issues/166#issuecomment-1026075648 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 31 January 2022 18:23:29 UTC