Re: getThisTabMedia

On Mon, Oct 12, 2020, 10:23 PM Harald Alvestrand <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?


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