W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2021

Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 15 Jun 2021 21:37:23 +0200
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>,Elad Alon <eladalon@google.com>
CC: T H Panton <tim@pi.pe>,Youenn Fablet <youenn@apple.com>,Jan-Ivar Bruaroey <jib@mozilla.com>,WebRTC WG <public-webrtc@w3.org>
Message-ID: <B759325A-5425-4AD8-9AE0-A6D1982C3CEC@alvestrand.no>
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
>passed as that information can be conveyed within the token) should
>inside the already available MediaTrackCapabilities/MediaTrackSettings
>the change launched on the video.onloadedmetadata and not have a
>object/event handler.
>El mar, 15 jun 2021 a las 16:29, Elad Alon (<eladalon@google.com>)
>>  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
>>>> 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
>>>> feature - if they included one of the free-standing Data-channel
>>>> The way I envisage it working is that the captured tab offers an
>>>> 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
>>>> may be a native app)
>>>> or the ability to filter by provenance. This token could perhaps be
>>>> MDNS SRV record for a data channel.
>>>> My feeling is that we should move forward with Elad’s proposal -
>>>> remove any requirements that preclude this path in future. (eg the
>>>> tests) and explicitly
>>>> include the concept that this feature might be available from
>>>> 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
>>> 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
>>> 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
>>> 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.
>>> 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.
Received on Tuesday, 15 June 2021 19:38:07 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 15 June 2021 19:38:23 UTC