W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > December 2020

Re: [mediacapture-screen-share] Add getCurrentBrowsingContextMedia (#148)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Wed, 02 Dec 2020 15:31:35 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-737305409-1606923094-sysbot+gh@w3.org>
I don't think we should introduce artificial reasons to crop, nor assume cropping will ever be added as a feature since it's a slippery slope to image processing, something this WG appears to be leaning more toward raw media access to solve.

> Shelving it for the time being, let's please examine the scenario of a game running in the browser, and wanting to stream itself to a service like Twitch. The streaming service could "publish" an iframe or a script that can be embedded in a game, implementing that functionality. The alternatives I can think of are less preferable. They
> (a) Each game re-implementing the streaming capability, probably by importing the streaming service's code into their own codebase. I don't think that's a reasonable alternative, as the copied code would be running *same-origin*, and would have to be scrutinized before being imported;

Exactly. To protect users from dubious information-harvesting JS libraries, I think I'd prefer this to receive the same level of scrutiny that a service provider performs to protect itself.

I don't think we should make it easier to export user trust to entities the service provider itself doesn't trust, because if a service provider doesn't trust a library then users probably shouldn't either.

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/pull/148#issuecomment-737305409 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 December 2020 15:31:38 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:52 UTC