- From: Elad Alon <notifications@github.com>
- Date: Fri, 23 Apr 2021 13:02:21 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/625@github.com>
Ya ya yawm TAG! I'm requesting a TAG review of getCurrentBrowsingContextMedia. ### Overview Consider the existing [navigator.mediaDevices.getDisplayMedia()](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getDisplayMedia). It allows a user unlimited choice of sources - any monitor, window or tabs. We’re in the process of standardizing a new API - [getViewportMedia](https://github.com/w3c/mediacapture-screen-share/pull/148) - that will allow web-applications to present a simple confirmation-only prompt to the user. The security requirements of this API are under [active discussion](https://github.com/w3c/mediacapture-screen-share/issues/155), but consensus is forming that both cross-origin isolation and a new opt-in header will be required. Not all applications can accept these requirements - at least not in the short-term. However, by forcing such applications to use [getDisplayMedia](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getDisplayMedia), the user is pushed towards the riskier option of sharing the entire monitor. Why is that the riskier option? Because at the moment capture starts, the entire current monitor includes the current tab. Note that the moment capture starts is sufficient for almost any attack, as all attacks we have thus far considered could be carried out using a single frame. A hybrid API - **getCurrentBrowsingContextMedia** - is deemed necessary in order to offer some of the benefits of [getViewportMedia](https://github.com/w3c/mediacapture-screen-share/pull/148) without its elevated security requirements. This hybrid API will allow the application to signal its preference for capturing the current tab. The browser will then offer the current tab as the first option to the user, but will still offer unlimited choice of capture sources (see image below). The unlimited choice of sources makes this new API compliant with the requirements of [getDisplayMedia](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getDisplayMedia). Since it complies with the requirements of [getDisplayMedia](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getDisplayMedia), the security requirements placed on [getDisplayMedia](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getDisplayMedia) are sufficient for this new hybrid API. ![Screen Shot 2021-04-23 at 21 32 45](https://user-images.githubusercontent.com/22117736/115923354-66a73200-a47e-11eb-8d81-a8129907f536.png) ### Links and Details - Explainer: [bit.ly/3dJgLfS](bit.ly/3dJgLfS) - Specification URL: https://eladalon1983.github.io/gcbcm/ (Intended to be moved to the WICG.) - Security and Privacy self-review: TODO (I will edit this comment and add the link.) - Primary contacts (and their relationship to the specification): - Elad Alon (eladalon1983@), Google, - Organization(s)/project(s) driving the specification: Google - Key pieces of existing multi-stakeholder review or discussion of this specification: [getViewportMedia](https://github.com/w3c/mediacapture-screen-share/pull/148) and [its security-requirements](https://github.com/w3c/mediacapture-screen-share/pull/155) - External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): [Chrome Status entry](https://www.chromestatus.com/features/5045313003847680) ### Further details: - [X] I have reviewed the TAG's [Web Platform Design Principles](https://w3ctag.github.io/design-principles/) - Relevant time constraints or deadlines: We aim to ship in Chrome m92 or m93. - The group where the work on this specification is currently being done: WebRTC WG works on [getViewportMedia](https://github.com/w3c/mediacapture-screen-share/pull/148), but is **not** interested in this hybrid API. - The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WICG (I will link once this is in the WICG.) - Major unresolved issues with or opposition to this specification: - Mozilla and Apple have voiced the opinion that [getViewportMedia](https://github.com/w3c/mediacapture-screen-share/pull/148) should be sufficient, and were not interested in ["weakened" version](https://github.com/w3c/mediacapture-screen-share/pull/148#issuecomment-807430485). - Our position, on the contrary, is that this hybrid is necessary and [does not degrade security when compared to getDisplayMedia](https://eladalon1983.github.io/gcbcm/#getdisplaymedia). - This work is being funded by: Google ### You should also know that... A word of caution over a source of potential confusion: * The name `getViewportMedia` is a later conclusion. Initially, that API was offered under the name `getCurrentBrowsingContextMedia`, which we now seek to reuse. * Chrome has an active origin-trial for `getCurrentBrowsingContextMedia` using the form in which we now offer it in the [explainer](https://bit.ly/3dJgLfS) and [spec](https://eladalon1983.github.io/gcbcm/). We'd prefer the TAG provide feedback as (please delete all but the desired option): 💬 leave review feedback as a **comment in this issue** and @-notify @eladalon1983 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/625
Received on Friday, 23 April 2021 20:02:34 UTC