Re: getThisTabMedia

On 08/10/2020 22:49, 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? This sounds 
> appealing until I consider the limitations. The user would have to:
>

My use case is not conference recording, but implementing a OBS studio 
on a web page.


> I already see requests in the thread for rendering in other 
> resolutions, which makes me wonder about the approach. 


In my use case, and extending the captureStream to an Iframe content, I 
could display the iframe/dom element content with a zoom property of 25% 
while still capturing the stream at full resolution.


>> 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"?
>
what about fetch("https://vulnerable-site.com/bar.mp4")? I don't 
understand the issue here.


>> 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).
>
That seems wise.

Best regards

Sergio