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

Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

From: Elad Alon <eladalon@google.com>
Date: Wed, 16 Jun 2021 14:31:12 +0200
Message-ID: <CAMO6jDPdjM06sG9Yg0c-_eyM+V_JkAug+TGk1Xt5RyFN-X76xg@mail.gmail.com>
To: Lennart Grahl <lennart.grahl@gmail.com>
Cc: public-webrtc@w3.org
> Considering both exist in the same browser instance, that is a
> mind-bogglingly unnecessary detour.

You were right *up to that point*, then took a detour. :-)
There is nothing here that *assumes* a shared cloud-infrastructure. That's
just *one* example of how you could use this.
You can perfectly well use the token to establish communication over
BroadcastChannel with a same-origin application. A token is still necessary
because you'd not know which of several tabs you're capturing.
Collaboration with cross-origin applications is also possible using this
method if you embed a frame from the same cross-origin and ask it to relay
messages on your behalf.

On Wed, Jun 16, 2021 at 2:18 PM Lennart Grahl <lennart.grahl@gmail.com>

> On 16/06/2021 12:30, T H Panton wrote:
> > Ha, I see the problem now, I’ve got comfortable in a flat-unique
> > token-namespace and forgotten how ugly the outside world is!
> >
> > I’m afraid this tells me that the idea of just having a token doesn’t
> > work - we need to define a namespace to assign meaning to it. I have
> > a couple of possibles in mind. The simplest being MDNS - you look up
> > the token in MDNS and retrieve an SRV which tells you how to
> > connect.
> I think you folks are talking at cross-purposes.
> IIRC, and please correct me if I'm wrong, this proposal is about
> **capturing a tab from the same browser instance**. And that is
> important. If we go beyond that (capturing a native app / window), all
> of a sudden we're in OS territory and have a whole number of different
> issues raising the barrier quite significantly as it would require
> specifying a communication channel between native apps (capturee) and
> browser (capturer) across different OSes.
> This is my summary of the spec so far and, again, correct me if I'm wrong:
> - it only targets **capturing a tab from the same browser instance**
> - the *handle* is just some arbitrary data unidirectionally exposed by
> the capturee for access by the capturer
> - the *permittedOrigins* limit access to the *token* by the capturer to
> the specified origins
> - *exposeOrigin* defines whether the capturer can see the origin it is
> capturing. (I'm not sold on having this btw. If you've got permission
> from the UA to capture, why would you need to hide the origin?)
> IIRC, what you (Google) are trying to do is to send a token from
> capturee to capturer that allows you to connect to some server the
> capturee is also connected to which in turn allows to remote control the
> capturee from the capturer. Considering both exist in the same browser
> instance, that is a mind-bogglingly unnecessary detour. What you
> actually want is a bidirectional communication channel between capturee
> and capturer.
> That brings me back to Sergio's proposal: Instead of *handle*, use a
> MessageChannel where one side gets port1 and one side gets port2. In code:
> dictionary CaptureHandleConfig {
>   boolean exposeOrigin = false;
>   port: MessagePort;
> }
> interface CaptureHandle {
>   [...
>   port: MessagePort;
> }
> If desired, that proposal could be refined with a mechanism from
> WebSocket, the subprotocol negotiation mechanism. This would allow to
> negotiate a (sub)protocol between both sides in a very simple manner, so
> both sides know how to communicate with each other.
> Now, if for some reason you still want to connect capturee and capturer
> via a third party (server), that's easily possible by just sending the
> data previously exposed via *handle* over the MessageChannel.
> Regards
> Lennart
Received on Wednesday, 16 June 2021 12:44:01 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 16 June 2021 12:44:17 UTC