Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

El jue, 10 jun 2021 a las 22:24, Elad Alon (<eladalon@google.com>) escribió:

> That's not up to Jitsi to decide, but it will be up to google docs/ms
>> office to allow jitsi domains to communicate with them. Also, what will
>> happen with self-hosted jitsi servers that would have their own domains, or
>> not domains at all?
>
>
> It is not in the browser's mandate to force collaboration on unwilling
> participants.
> Jitsi will be able to set up first- and third-party collaborations just as
> much as everyone else.
>
> what this web API will create is an uneven playfield to VC applications.
>>
>
> This API open a door. If some players are quicker to move through these
> doors, that is a legitimate advantage. For the slower players to demand
> progress be slowed and the status quo be kept, is to attempt to compete
> through kneecapping the competition - unsportsmanlike.
>
> You might say you do not ask for doors to be kept barred, but rather for a
> different door to be opened. If so, I'd respond - there are things Capture
> Handle provides that alternatives would not provide. It makes sense for
> browsers to open multiple doors here.
>
>
I think that both statements above are a bit incompatible.

I am not representing any VC service or content provider, so I don't have a
strong opinion about this. But when we analyze this new API we should be
aware of the consequences and the changes on the "status quo" in the webrtc
community and acknowledge that some VC services will have competitive
advantages over others that currently they don't have.

Not sure if that is a good or bad thing, or even if the W3C should be
worried about this kind of stuff, but let's not be naive and say that all
VC services will benefit equally from this api.



> So Jitsi will have to implement google docs apis, ms office apis, to do
>> basically the same? doesn't seem very scalable
>
>
>    1. I still agree that a more presentation-focused API would also be
>    useful. Operative word "also." The more general-purpose tool of Capture
>    Handle has its place. Some collaborations are very specialized by nature,
>    and scaling them is not necessary. Special-purpose collaborations set up at
>    great expense between one application (Underwater-Photoshop-2000) and one
>    VC application (Jitsi) at great expense, financed by one special customer
>    (the Atlantis School of Underwater Economics).
>    2. Official and unofficial protocols usually arise in such situations.
>    The capture-handle exposed by service X could be a JSON which includes
>    {protocol: "public-preso-2.3", id: "0x382abc42", ...}. That would make
>    things quite scalable.
>
> That's what I am concerned about, privileged actions that will allow
>> certain VCs to have a better user experience than the competence.
>
>
> I think we're talking about different types of "privileged" here.
> Regardless of whether the VC application is Jitsi or Zoom, the document you
> are capturing will not allow access to risky operations without
> authenticating the user. Imagine you're capturing Github. Would they allow
> remote browsing (via relaying keyboard+mouse events) to arbitrary
> capturers? No, because that lets them delete repos, post embarrassing
> messages, etc. It's too risky. They'll want some authentication.
>

Here you are not authenticating the user, you are authenticating the
capturee application. The user should be authenticated in the captureed web
page and not in the capturee one. The user is the same one owning both
browser tabs.


> If you want to do that, why not integrate the VC application into your
>> document web page and not the other wise?
>
>
>    1. The remote-editing example was just an example.
>    2. I can still have plenty of UX, marketing, budgeting and other
>    reasons to prefer a multi-tab experience.
>
> A capture-sef: disabled property on the getDisplayMedia would prevent this
>> as well.
>
>
> I like it when a single tool can tackle many tasks. I am not as eager to
> construct multiple single-use tools. Shipping anything on the Web takes a
> very long time...
>
>
In this particular case, that is, preventing the mirror effect, will be
much inefficient on a protocol happening after the capture has been allowed
by the user. It will be much more useful if it is prevented before the user
has to make any choices on the confirmation dialog.

Also, this could be aligned with the other attribute that was going to be
proposed to ask for capturing the self tab.



> That part of the api could work as is, i am only against the privileged
>> apis for certain domains.
>
>
> The API is not privileged, but its applications can be. That is by design.
> I am not upset when my password does not allow me to log into your email.
>
> I think that the action based approach is a good way to go for the remote
>> presentation actions, let's see if we can get an agreement on the other
>> topics.
>
>
> It is unclear to me if it would see use, as applications might prove
> unwilling to allow an arbitrary capturer to control them.
>

I really like apis when they allow untrusted parties to collaborate
securely allowing more freedom to the end user and I think it is a goal  it
is worth pursuing.


> I prefer to discuss this other proposal separately. We have enough reason
> to pursue both discussions in parallel.
>
>
I am not opposed to that as well.

Best regards
Sergio

>