Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

The point of the origin is that the UA vouches for it's authenticity.

The token is just a string. As long as you can pass a string, the app can choose to pass anything: numbers, tokens, or jsonified objects. App's business, not UA business.

Den 15. juni 2021 16:42:06 CEST, skrev Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>:
>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
>>>
>>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.