[w3ctag/design-reviews] Early TAG design review for captureTab (#609)

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:

  - [X] I have reviewed the TAG's [API Design
Principles](https://w3ctag.github.io/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**

-- 
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/609