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

I'd also like to clarify that cropping is not the main issue with
capture-this-tab, but rather just an example. I see the advantages of
capture-this-tab as being the following, and in this order:

   1. [Main advantage:] Nearly eliminates the risk of users sharing the
   wrong thing (choosing the wrong thing in a chooser). IMHO, this is a big
   selling point.
   2. [Important, but not main advantage:] Allows the application the
   knowledge of the contents of the capture, allowing processing of any sort,
   cropping (*even in JS*) being just one example. Other (hypothetical)
   examples include blurring part of the captured stream without blurring what
   the local user sees, censoring private information that's in the middle of
   the captured content (can't be cropped) without obscuring it for the local
   users, etc. This is just a short list of hypotheticals I could think of,
   3. [Lower importance:] Provides a streamlined interface for sharing,
   making both users' and developers' lives easier.
   - Contrast the "share this document" flow using
      getCurrentBrowsingContextMedia with the flow using getDisplayMedia. With
      getDisplayMedia, if the user chooses the wrong source in the picker, the
      application has to (a) detect it, (b) discard the MediaStream and (c)
      explain to the user what mistake he had made, and how to avoid it in the
      future, then (d) prompt the user to try again. Cumbersome.

On Wed, Dec 2, 2020 at 4:49 PM Elad Alon <> wrote:

> In the scenario described, the service provider trusts the (specific)
> third-party enough to (1) embed it and (2) provide its iframe with
> allow=display-capture. The service provider should not, IMHO, be forced to
> the decision of either not trusting the (specific) third-party it at all,
> or trusting it enough to allow it to run same-origin.
> On Wed, Dec 2, 2020 at 4:31 PM Jan-Ivar Bruaroey <>
> wrote:
>> 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
>> include:
>> (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.
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> <>,
>> or unsubscribe
>> <>
>> .

GitHub Notification of comment by eladalon1983
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Wednesday, 2 December 2020 16:06:31 UTC