Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

I meant that maybe the token (I am not sure if the origin should be even
passed as that information can be conveyed within the token) should belong
inside the already available MediaTrackCapabilities/MediaTrackSettings and
the change launched on the video.onloadedmetadata and not have a specific
object/event handler.

El mar, 15 jun 2021 a las 16:29, Elad Alon (<eladalon@google.com>) escribió:

>  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
>>
>>