Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

Embedding the specific UA controls in the browser (proposal A and B) is 
a layering violation.

The WebRTC API and the platform does not offer a presentation feature; 
it offers a platform on which applications can be built, some of which 
embed the concept of "forward slide" and "back slide".

If you want to propose creating a complete framework for presentations 
and presentation management, and propose embedding the whole thing in 
the browser, you're free to do so, but that's not a WEBRTC matter (it 
might be a webapps matter), and I do not think it is at all appropriate 
to prusue such a course.

Letting a controller component and a controlled component for an 
application find each other and decide to communicate seems like an 
appropriate thing for the platform to offer.

Trying to dictate what they talk about is not appropriate for WEBRTC.

On 6/14/21 5:16 PM, Youenn Fablet wrote:
>>
>>>     I really like apis when they allow untrusted parties to
>>>     collaborate securely allowing more freedom to the end user and I
>>>     think it is a goal  it is worth pursuing.
>>
>>     Communication channels between two untrusted parties is always
>>     something to look closely at, from a security and privacy standpoint.
>>     A safe model is to have the UA in the middle: the UA triggers
>>     these actions on behalf of the user, not on behalf of the capturer.
>>     For instance, by presenting UA UI in the capturer page to control
>>     capturee through actions, similar to picture-in-picture for VC.
>>     For instance if capturee page is playing a video, it might be
>>     convenient from capturer page to pause the capturee video using
>>     the play/pause actions.
>>     A further step would be to allow capturer page to blend well with
>>     this UA UI.
>>
>>
>> So I hear 3 directions for presentation control actions:
>>
>>   * A: UA triggers these standard actions on behalf of the capturer.
>>   * B: UA triggers these standard actions on behalf of the user, not
>>     on behalf of the capturer.
>>   * C: Out of band between mutually participating properties only,
>>     based on id.
>>
>> I think both A and B sound promising. Youenn, it seems to me A might 
>> have slightly better ergonomics, so I'm curious about what risks B 
>> might mitigate.
>
> A and B are not exclusive, B could be implemented and deployed faster 
> than A.
> I believe B is the current MediaSession approach and has the same 
> security context.
>
> A is an extension to this approach and needs additional scrutiny since 
> now capturer, which is not as trusted as UA, is the one deciding to 
> trigger these actions.
> For instance, capturer might iterate through all slides while not 
> displaying the captured live stream to the user.
> Or multiple capturers can interact with the same capturee.
> This is not to say it is impossible but it probably requires more work.