Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

El vie, 11 jun 2021 a las 14:59, Elad Alon (<eladalon@google.com>) escribió:

>
>> 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.
>
>
One thing I overlooked from your original proposal is that you plan to do
the communication between two tabs to happen externally (via service
workers or p2p datachannels), maybe it has already been discussed but is
there any reason that you are not using a MessageChannel/MessagePort
instead?



> 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.
>
>
If I understood your proposal correctly,  the capture handle would only be
available if you share a tab, but can't be available if sharing a browser
window or the whole desktop. How would your proposal work in this case?

Best regards
Sergio