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

> @youennf Reusing mediaSession, while intriguing, seems risky design-wise and scope-wise: repurposing a well-known API with a known a trust model to now also be something else. I don’t see a lot of user benefit frankly.

In the WG meeting, YouTube was given as an example where such API could be potentially useful.
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.
Also, if it is useful to control slides from another page, it might also be useful to control slides from a PiP window, so useful to expose specific slides control from a MediaSession.

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.

> I'd rather avoid adding another messaging channel to the platform. Also, as soon as such a channel exists, the parties can exchange IDs anyway, so this seems like a superset of @eladalon1983's approach.

The CaptureHandle's proposal is adding a one way communication from capturer to capturee.
As Elad's mentioned several times, this one way communication channel can be used to create a two way communication between capturer and capturee.

The action's proposal is most probably also creating a two way communication channel between capturer and capturee (we would need to have a clear API to validate this).
The same privacy/security risks (exchange IDs) apply to all these proposals and we should review all of them accordingly. Or did I miss something? If the issue is not privacy/security, what is it?

> I'd rather steer clear of this.
> On the one hand, it requires tight cooperation, or else how would the capturer/capturee understand each other? So we can take it as a given that users of this API would be **tightly integrated**.

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. Google slides, as a capturee, does not have to understand capturer at all.
Capturee may of course still want to restrict the origin of capturer it is talking to.

> On the other hand, it forces a communications method, and I think this should be left out of scope. **Tightly integrated** applications have their own various means.

This communication method is the traditional way of doing cross-context communications on the web (postMessage).
If this way of communication is not good, can you explain why and according which criteria?

> But if getDisplayMedia is called twice in a row, how does JS know which one it is?

If we take the current eventing model, calling getDisplayMedia twice in a row, say A and B. As long as A and B trigger the prompt, the assumption is that the order is preserved as:
- event A is fired.
- promise A is resolved.
- event B is fired.
- promise B is resolved.
While this is not strictly guaranteed by spec by the 'run in parallel' step, we could make that clear.

The case where ordering is not guaranteed is if B fails, in which case promise B may reject sooner (but there will be no event B), though we could fix this as well.
It is true that the technique to register a one time event handler will not work in any case, the API ergonomics are not optimal. This would be also true in the case of the focus event handler so maybe we need a better API there, like an additional getDisplayMedia callback for instance.

-- 
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/166#issuecomment-1021001922 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 25 January 2022 09:52:41 UTC