Re: getThisTabMedia

On Mon, Oct 12, 2020 at 7:23 AM Harald Alvestrand <harald@alvestrand.no>
wrote:

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

Thanks, makes sense! For this use case it would seem sufficient for the
document to only be able to capture itself. Same with the "record my
meeting session" use case.

For this to be secure, the document would have to be isolated as a matter
of policy. We'd need something stronger than cors-only, since being able to
render a document from another origin is different from reading it. A new
policy would be needed, e.g. Cross-Origin-Embedder-Policy: disallow

Even then it would need permission, since rendering contains private
information, such as:

   - link purpling (browser history)
   - form autofill (address, credit card info)
   - extensions (e.g. lastpass)
   - file input element sometimes contains private info

These risks are hard to explain to users in a prompt.

API-wise, this seems like a lower-level API functionally different from
getDisplayMedia(). E.g. document.captureStream() or
canvas.drawImage(document) - The latter would even be outside the scope of
this WG.

.: Jan-Ivar :.

On Mon, Oct 12, 2020 at 7:23 AM 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.
>
> 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
>
>

-- 
.: Jan-Ivar :.