Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

> 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 <mailto: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 
> 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).
> 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?
> The remote-editing example was just an example.
> 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