Re: getThisTabMedia

On 10/8/20 10:49 PM, Jan-Ivar Bruaroey wrote:
> On 10/8/20 3:56 PM, Sergio Garcia Murillo wrote:
>> On 08/10/2020 21:36, Jan-Ivar Bruaroey wrote:
>>>
>>>  2. Is the goal performance? E.g. is recording a web conference call 
>>> using canvas.captureStream prohibitive?
>>>
>> canvas.captureStream is not a viable option at all, the idea is to be 
>> able to capture all the richness of a css+js UI interface, not to 
>> have to re implement all of it manually (or via webgl).
>
> So the use case is recording a web conference call?
>
The primary use case is to share a tab that contains conferencing code + 
displaying information in the form of complex Web content. One example 
is projecting a Google Docs presentation into a conference; if the page 
displaying the presentation also contains conferencing code, it can 
capture itself and send itself to the conference.

For the use case of conference calls, where all the interesting content 
is already in audio/video form, we have adequate ways of recording them.

> This sounds appealing until I consider the limitations. The user would 
> have to:
>
>  1. avoid resizing the window for the entire call
>  2. avoid PMing participants during the call, unless they want the
>     private conversation included in the recording
>  3. avoid visiting the site's settings/options/speaker-notes panels or
>     otherwise accidentally sharing things
>  4. avoid any participant action they wouldn't be comfortable with
>     including in the recording, like focusing on another participant
>
> It'd basically record the participant, just not the call. The 
> recording is from their view, in their current resolution and window 
> size, with their actions. Perhaps a site could be designed around 
> these limitations, but that seems like the tail wagging the dog.
>
> In contrast, while a custom composition of a participant-neutral view 
> sounds like a lot more work initially, the end result would have none 
> of these problems.
>
> I already see requests in the thread for rendering in other 
> resolutions, which makes me wonder about the approach.
>
>
>> I agree with the IFRAME argument, we should prevent this for 
>> capturing contents from outside the domain (and isolated streams).
>
> Yes, though again I don't know if it can be done safely. E.g. what 
> would happen if I do
>
> video.src = "foo.mp4"; await wait(5000); video.src = 
> "https://vulnerable-site.com/bar.mp4"?
>
>
>> IMHO, I would prefer to extend to the media capture from DOM elements 
>> to the window or document elements (following the same domain 
>> security policies, of course).
>
> That's interesting, and might bring in DOM folks that perhaps would be 
> able to talk to the security ramifications of exposing DOM rendering 
> in this way (fingerprinting, personal data exposure through CSS 
> exploits etc).
>
> .: Jan-Ivar :.
>
>
>> Best regards
>>
>> Sergio