I'm requesting a TAG review of capture-current-tab.

Summary: in a number of scenarios (most prominently sharing Web slides in a Web teleconference), offering the possibility to video-capture the current tab (or a cropped view of the current tab) provides a smoother and easier to understand UX than what's possible using the Screen Capture API. The WebRTC WG has rough consensus that this is a useful scenario to address and is exploring approaches to enable that scenario; we are seeking input from the TAG on how to do that safely and consistently with the rest of the platform.

• Explainer: Two rough approaches have been discussed:

  • getCurrentBrowseringContextMedia - explainer at https://docs.google.com/document/d/1CIQH2ygvw7eTGO__Pcds_D46Gcn-iPAqESQqOsHHfkI/edit#heading=h.bj2aavkeqqud related discussions at https://github.com/w3c/mediacapture-screen-share/pull/148 and https://github.com/w3c/mediacapture-screen-share/issues/156, with concerns around cross-origin protections (see below)

  • getTabMedia() secured by COEP sketched in https://docs.google.com/presentation/d/1CeNeno5XuDhm1mpnVyE9eT14YKZgZUtgQsJfC8uqEpA/edit#slide=id.gaef31c926d_1_72 (slides 16-28)

• Security and Privacy self-review The gist of our request for input is on the privacy and security trade-off given that in a number of cases, the content to be captured from a given tab will include cross-origin content (e.g. Web slides that integrate a video hosted on a streaming service), possibly nested several times.

  In general, we recognize that an API that allows to capture a single tab reduces some privacy risk compared to the generic screen sharing API (with less risk to share unintended content), but creates a bigger security attack surface where a Web site could embed third-party content and social-engineer the user to get it captured to gain access to cross-origin information.

  In particular, there is active discussion on whether embedded origins should opt-in or opt-out of that possibility: https://github.com/w3c/mediacapture-screen-share/issues/156

  The trade-off is discussed in slides https://docs.google.com/presentation/d/1CeNeno5XuDhm1mpnVyE9eT14YKZgZUtgQsJfC8uqEpA/edit#slide=id.gaef31c926d_1_37 from 11 to 28

• GitHub repo (if you prefer feedback filed there): https://github.com/w3c/mediacapture-screen-share/

• Primary contacts (and their relationship to the specification):

  • Elad Alon (@eladalon1983, Google), Jan-Ivar Bruaroey (@jan-ivar, Mozilla) have been shepherding the discussions in this space

• Organization/project driving the design: WebRTC WG

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WebRTC WG
• The group where standardization of this work is intended to be done ("unknown" if not known): WebRTC WG
• Existing major pieces of multi-stakeholder review or discussion of this design: (see above)
• Major unresolved issues with or opposition to this design: (as described above, the security model for cross-origin content)
• This work is being funded by: N/A

We'd prefer the TAG provide feedback as (please delete all but the desired option): 🐛 open issues in our GitHub repo for each point of feedback