Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

>
>  I feel that the opaque token ... might be better provider as metadata of
> the captured stream rather than in a different api.
>

What is Capture Handle if not a way to set() and get() this metadata?

On Tue, Jun 15, 2021 at 4:20 PM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

>
>
> El mar, 15 jun 2021 a las 11:42, T H Panton (<tim@pi.pe>) escribió:
>
>> I think there is a strong solution that _is_ a webRTC matter and we might
>> want to move to in the future.
>>
>> - We should use a webRTC data channel as the path between the capturer
>> and captured apps.
>> This has the advantage of being cross browser (in every sense) since it
>> would work if one were using chrome to capture a firefox tab etc.
>> It is also possible for standalone presentation apps to offer the same
>> feature - if they included one of the free-standing Data-channel stacks.
>>
>> The way I envisage it working is that the captured tab offers an opaque
>> token (as in Elad’s proposal) to the capturer when the user selects
>> a window to capture (this would not apply to regions/whole screen
>> captures) - The token does not include any clues about origin (the target
>> may be a native app)
>> or the ability to filter by provenance. This token could perhaps be an
>> MDNS SRV record for a data channel.
>>
>> My feeling is that we should move forward with Elad’s proposal - but
>> remove any requirements that preclude this path in future. (eg the origin
>> tests) and explicitly
>> include the concept that this feature might be available from captured
>> native windows too.
>>
>>
> I am still not buying the opaque token solution or how useful it would be
> for generic usage apart from some very tailor made use cases.
>
> Anyway, speaking only about the technical details, I feel that the opaque
> token (or semi-opaque as it can be set by the capturee to convey
> information to the capturer for example using a jwt token) might be better
> provider as metadata of the captured stream rather than in a different api.
>
> Also, I think that the opt-in should be doubled, first by a CSP directive
> indicating that the api is available to the page and the domains allowed to
> receive the token, and then enabled/disabled by the javascript APIs. I
> don't think that it is a good idea to allow any script to set it, as I can
> imagine an external script (like google analytics) trying to enable it for
> every domain in order to retrieve the capturee usage stats.
>
> Best regards
> Sergio
>
>