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

Chrome Security is of the opinion that a confirmation-only flow for gCBCM (getCurrentBrowsingContextMedia) would require security measures similar to those which @jan-ivar [has suggested]( Namely, a combination of (a) site-isolation and (b) a new COEP-like header for opting in to capturability by embedder. I think we have the following issues to resolve, then:

## Name
We are open-minded about this. I personally like `navigator.mediaDevice.getCurrentTabMedia`. I think it’s succinct and clear. I have also considered `getThisTabMedia`, but I find that it’s not as clear whether “this” refers to “tab” or to “media.” Wdyt?

## Security Measures
I think we can continue this discussion in thread #155.

## Behavior when security-measures do not hold
The application might try to call gCBCM from almost any context.

If gDM is not allowed to be called from that context, then gCBCM should also not be permitted. (For example, calling gCBCM from an iframe that does not have the prerequisite [display-capture]( permission from its embedder.)

gCBCM introduces new requirements in addition to gDM’s - (a) site-isolation and (b) a new HTTP header (definition pending in [separate thread]( If either of these conditions does not hold at the time when gCBCM is called, we would like to specify that the user agent SHOULD (or MAY) fall back to gDM-like behavior. That is, display a dialog that does not limit the selection of the by the user to just this tab.

 **Rationale for Fallback**
We expect the most common failure of gCBCM calls to occur due to a third-party iframe served without the new HTTP header. This will be especially true in the beginning, before the new header has had time to gain wide adoption, but even after adoption is widespread, it will be difficult for complex applications to ensure that all embedded content “plays nicely” at all times and includes the necessary header. Third-parties could be migrating between servers, falling back on misconfigured servers, etc. So failure to call gCBCM should be expected even in otherwise well-structured applications.

One possibility for applications is to inspect the failure reason of gCBCM calls, and if it’s due to the missing header, to call getDisplayMedia “manually” as a fallback. This is possible, but clunky. It’s also arguable that exposing the exact reason gCBCM was rejected is undesirable. (Normally, a top-level application would not be allowed to see what HTTP headers embedded content uses, let alone embedded content twice-removed. Normally, things either load or don’t.)

We believe that it will be helpful if we specify that the user agent SHOULD default to a gDM-like dialog (or possibly MAY). The only new problem introduced - uncertainty by the application over whether the user really chose the current tab - can be resolved in several ways. It may be left to the application (e.g., pixel test), or we could discuss more ergonomic solutions - using a returned value, using the label of MediaStreamTrack (Firefox currently uses windows’ titles as the label), etc.

### Audio Playback Suppression
I will be using “**playback-suppress**” as shorthand for “mute the audio from the speaker’s point-of-view, but still make this audio capturable.”

While a user is capturing audio from a tab, it’s sometimes useful to prevent that tab from performing audio playback through the speakers. This is useful, for example, for performing echo cancellation, which works better if the audio captured on the playback-suppressed tab is sent back to some like is other participants’ audio, and is seen by the echo canceller as just another remote-sourced audio stream played out over the speakers. I see some options here:
1. Allow a parameter or a constraint to determine whether the captured tab is playback-suppressed or not. (Note that capturing is user-controlled, so malicious applications cannot just use this to mute other tabs willy-nilly.)
2. Reinterpret an existing control, constraint or setting to mean that the captured tab should be playback-suppressed (e.g. echoCancellation).
3. Specify that the behavior of capturing a tab playback-suppresses its audio, always, and that’s it.
4. The most ambitious change (goes beyond the scope of this WG), but IMHO the most desirable - we should note that atm, it is not possible for an app to suppress its own speaker-playback. Or an iframe’s playback. That means that by embedding an iframe, the application accepts whatever audio-playback the embedded frame happens to perform. It would be good if documents could playback-suppress (a) themselves or (b) specific embedded iframes.

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 Tuesday, 16 March 2021 15:49:26 UTC