- 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