Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

By your own admission, *the same lock-out is possible* with a
MessageChannel, so all previous arguments in that vein are
equally valid/invalid here. A rose by any other name...

What do we gain then?
Can we discover self-capture more easily? No, it becomes a bit more
involved.
Can we establish an arbitrary channel of communication more easily? No,
we're kind of pushed down the path of the MessageChannel. (Granted - we can
still change lanes. Note "more easily.")

What do we lose?
The capturer can no longer get information about the captured application
without alerting the captured application to the existence of a capture. A
real shame to lose this property. IIRC Mozilla was concerned that captured
applications could "paywall" and start censoring themselves when captured.
I share that concern.

Btw, I'd like to remind you of the presence of "*" (the wildcard character)
as a valid value of *permittedOrigins*. Browsers are not in the business of
forcing collaboration, we're in the business of enabling it between
consenting participants.

On Wed, Jun 16, 2021 at 3:00 PM Lennart Grahl <lennart.grahl@gmail.com>
wrote:

>
>
> On 16/06/2021 14:31, Elad Alon wrote:
> >>
> >> 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.
>
> I see your point that it is possible but I'm not convinced that jumping
> through the extra hoop of an iframe and fiddling with cross-origin
> policies is the better approach over an upfront MessageChannel.
> The former involves an arguably significant setup cost plus
> understanding the protocol while the latter "only" requires to
> understand the protocol.
>
> More importantly however is that the MessageChannel approach would allow
> us to remove the controversial *permittedOrigins* constraint because a
> bidirectional communication channel allows you (Google) to create a tiny
> protocol with an authentication challenge, if you so desire. This is
> preferable as it likely reduces the amount of hard in-house-barriers
> (term stolen from Tim).
> In other words: It is easier to implement a protocol than to convince
> you (Google) to include my app in your list of *permittedOrigins*. You
> can still lock me out if you really wanted to, though.
>
> Regards
> Lennart
>