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

> I do however find the idea of enabling apps to stream themselves into web conferences appealing, provided it can be integrated safely.

I agree completely about safety being of utmost importance, and would love to continue the discussion over how it can be achieved while maintaining the feature's usefulness.

In the [WebRTCWG-2020-12-02](https://docs.google.com/presentation/d/17Z_vR4pOXn-9wthiqbM9GC7JE7vfbdNffEedBPqj1Mw/edit?ts=5fc3bf37#slide=id.gaec44d0fdd_2_0) slides I see you were going to pitch a "stream-thyself" approach (AKA share-iframe-and-below). Here are some of my thoughts of this API when compared to share-this-tab:

1. **[Intro]** I see the usefulness of stream-thyself, and would be glad to see it defined and implemented.
2. **[Usefulness]** However, I thinks it does not eliminate the need for a share-this-tab API:
   - Sometimes the application and user are **interested in capturing the entire tab**. There might not be a natural top-level that is also well-positioned to handle the capture of the DOM below it. (My example was a Twitch-like service.)
   - It also bears mentioning that this type of permission-request (entire-tab) is **easiest to communicate to the user**; share-iframe-and-below is less straightforward.
   - **Implementation-wise, share-this-tab is a trivial variation** on the existing getDisplayMedia, and can be accomplished quickly by all major browsers, without any unforeseen security/privacy issues.
   - **Adoption** by browser vendors can therefore also be expected to be swifter and wider. ("Objection your honor! Conjecture!" "Granted.")
   - Content from lower in the DOM can **draw over content from higher in the DOM**, and the application might wish for that to be captured.
   - [Unsure about this one:] It is not clear to me what **efficiency** even an optimal implementation of stream-thyself would be. Would the browser not effectively have to render twice?
3. **[Security]** As for security, it is not clear to me that stream-thyself provides an improvement over capture-current-tab.
   - For the concern of **harvesting user information** (auto-fill, etc.), I don't think there is a difference between the two approaches. Harvesting is done in the frame under one's control, not further up the DOM, right?
   - The main selling point of the stream-thyself approach (share-iframe-and-below) is its **protection of the embedding frame from capture by the embedded frame**. However, this is already possibly using the [display-capture Feature Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy/display-capture), so I don't see stream-thyself as better in that regard.
   - For the opposite direction - **protecting the embedded frame from capture by the embedding frame** - I don't think stream-thyself offers added-value either.
      - I must confess to still not understand your suggestion for use of **COEP**. Assuming that suggestion addresses this concern - would it be applicable to capture-current-tab?
      - Alternatively, I suggest an **allow-capture-by-embedder Document Policy**, which I believe addresses this concern (and could do so equally for stream-thyself).

**In conclusion:**
- AFAICT, both approaches are equivalent from a **privacy/security standpoint** (modulo COEP, modulo^2 applying it to share-this-tab).
- From an **ease-of-use** standpoint, preferability for the application-developer depends on the developer's specific use-case.
- From an **ease-of-implementation** standpoint (for the browser vendor), share-this-tab is easier.
  - (And therefore **adoption** speed and likelihood are likely on the side of share-this-tab.)
- From a **communicability-to-user** standpoint, share-this-tab is simpler.
- Both APIs have their place.

Wdyt?

-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/pull/148#issuecomment-737518816 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 2 December 2020 21:53:49 UTC