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

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 slides
<https://docs.google.com/presentation/d/17Z_vR4pOXn-9wthiqbM9GC7JE7vfbdNffEedBPqj1Mw/edit?ts=5fc3bf37#slide=id.gaec44d0fdd_2_0>
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 that is intended and in our envisioned use case, *intended
      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?

On Wed, Dec 2, 2020 at 6:39 PM Jan-Ivar Bruaroey <notifications@github.com>
wrote:

> The service provider should not, IMHO, be forced to the decision of either
> not trusting the (specific) third-party it at all, or trusting it enough to
> allow it to run same-origin.
>
> @eladalon1983 <https://github.com/eladalon1983> but this feature
> undermines many of the same-origin protections you get from iframing in the
> first place.
>
> ... Allows the application the knowledge of the contents of the capture,
> ...
>
> Right, and this knowledge adds risk.
> Whatabout getDisplayMedia?
>
> While getDisplayMedia already has this problem *IF* the user chooses the
> same tab, at least that scope violation is 100% user-driven, and some form
> of social engineering is needed to make it a reliable exploit (it doesn't
> help that Chrome fails to warn about this when it should
> <https://w3c.github.io/mediacapture-screen-share/#elevated-permissions>).
>
> I think it's fair to say getDisplayMedia is flying close to the sun
> <https://github.com/w3c/mediacapture-screen-share/blob/gh-pages/questionnaire.md>
> already and exists because it is backed by such a highly compelling use
> case (web conference presentations). If you were to ask me if I think it
> has too many security mitigations, I'd say no. That's why I don't find it
> compelling to remove any of them.
>
> I do however find the idea of enabling apps to stream themselves into web
> conferences appealing, provided it can be integrated safely.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/w3c/mediacapture-screen-share/pull/148#issuecomment-737385649>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AFIX22HUAQ6FT7ROYCGBRULSSZ3WJANCNFSM4SHNXW3A>
> .
>


-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/pull/148#issuecomment-737512596 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:40:05 UTC