Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

>
> 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?
>

Here
<https://github.com/w3c/mediacapture-screen-share/issues/166#issuecomment-852329145>
is
one comment that addresses this question.

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?


We can expand Capture Handle to work with user-agent windows, by saying
that the window's Capture Handle is that of the active tab. Changing of
active-tab can be handled the same way we handle top-level document
navigation in the captured tab.

On Fri, Jun 11, 2021 at 4:12 PM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

>
>
> 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
>