Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

>
> let's not be naive and say that all VC services will benefit equally from
> this api


What I claim is that the API does not itself give preferential
treatment. *Hypothetical
situation:* Consider if, back when the introduction of getDisplayMedia was
discussed, Facebook Messenger suddenly objected that getDisplayMedia gives
advantage to Jitsi and other players who can now offer users a feature
which Messenger did not intend to use. We'd not have been receptive to that
complaint. How is the current situation different?

The user is the same one owning both browser tabs.


Captured applications are going to be apprehensive accepting input from
another application, just because it happens to be running in the same
browser. Previous/next slide might be fine (hence we've agreed on that
previously), but what about anything else? For anything even slightly
impactful, they would require some established API exposed with the proper
authentication. Something like a REST API accessed with pre-existing
authentication, where some session ID (exposed via the Capture Handle) is
the only missing piece.

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.


Multiple mitigations are needed, since the hall-of-mirrors effect can kick
in at any moment, e.g. when capturing a window and switching between tabs
in that window.

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.


We need two Swiss knives, not a toolshed. One Capture Handle to establish
trust and allow trusted collaboration, one Actions-based API for allowing
untrusted collaboration.

I am not opposed to that as well.


I am looking forward to hopefully either hearing your fully fleshed-out
proposal there, or to one day hearing your opinion on mine.

Thanks,
Elad



On Fri, Jun 11, 2021 at 10:02 AM Youenn Fablet <youenn@apple.com> wrote:

>
>
> On 11 Jun 2021, at 09:38, Sergio Garcia Murillo <
> sergio.garcia.murillo@gmail.com> wrote:
>
>
>
> 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.
>
>
> Communication channels between two untrusted parties is always something
> to look closely at, from a security and privacy standpoint.
> A safe model is to have the UA in the middle: the UA triggers these
> actions on behalf of the user, not on behalf of the capturer.
> For instance, by presenting UA UI in the capturer page to control capturee
> through actions, similar to picture-in-picture for VC.
> For instance if capturee page is playing a video, it might be convenient
> from capturer page to pause the capturee video using the play/pause actions.
> A further step would be to allow capturer page to blend well with this UA
> UI.
>
>
>
>> 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
>
>
>