Re: getThisTabMedia

On 10/12/20 8:39 PM, Silvia Pfeiffer wrote:
>
>
> On Mon, Oct 12, 2020, 10:23 PM Harald Alvestrand <harald@alvestrand.no 
> <mailto:harald@alvestrand.no>> wrote:
>
>
>     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.
>
>
> Would it be able to share itself into any Webrtc call or just into a 
> specific app?


Since what you get from getBrowserContextMedia is a MediaStream, it can 
be placed into any PeerConnection object that the page has access to - 
but since we don't have means of moving PeerConnections or MediaStreams 
between contexts, that effectively means "specific app".


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