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

Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

From: Lennart Grahl <lennart.grahl@gmail.com>
Date: Wed, 16 Jun 2021 14:13:00 +0200
To: public-webrtc@w3.org
Message-ID: <ccdba354-5431-4572-3ab9-fa1691f555d3@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.

Received on Wednesday, 16 June 2021 12:14:22 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 16 June 2021 12:14:31 UTC