[mediacapture-screen-share] Identification of Captured Application By Capturer (#166)

eladalon1983 has just created a new issue for https://github.com/w3c/mediacapture-screen-share:

== Identification of Captured Application By Capturer ==
This is the culmination of discussions in #159. I am re-summarizing so as to avoid misunderstandings stemming from that other issue's history (it started focused on label, but evolved in a different direction).

## Problem
When the user chooses a tab using `getDisplayMedia`, the capturing application has no good way of discovering which application is is capturing.

## Use cases
### 1. Establishing Cross-Tab Communication
The stress here is on "establishing," by which I mean **identification**. Communication itself is a solved issue once identification takes place - we can use [BroadcastChannel](https://html.spec.whatwg.org/multipage/web-messaging.html#broadcastchannel), a shared back-end, sometimes a service worker. This issue is concerned with how the capturing application can identify the captured application, so that messages could be addressed specifically to it.

For example, assume two collaborating apps from ACME corporation - a capturing VC application called ACME VC-Max, and productivity suite app called ACME Presentron. (The marketing department took a day off.) The user has many open tabs, both of Presentron as well as of other applications. When VC-Max asks to capture a tab, and the user chooses Presentron, we want VC-Max to be able to identify that this selection took place. Moreover, we want Presentron to be able to declare an ID; VC-Max can then use this ID to address messages solely to the **specific** captured Presentron session. (Note - reliably and ergonomically passing this ID is in-scope; use of the ID for communication is beyond scope; it's enough for us that it's possible.)

Once this ID is passed an communication is initiated, VC-Max can display controls for the user that will allow the user to flip through slides on the captured Presentron slides deck from within the VC-Max session.

### 2. Analytics
Capturing applications can gather statistics over what applications its users tend to capture. This can be used to improve service for the users by introducing collaborations. One such possible collaboration was described in the use-case above.

### 3. Conditional Tab-Focus Change
In #165 I proposed an API for one-way hand-off of tab-focus from capturer to captured. Consider the intended case for this - shortly after capture starts. With the capture-handle defined by the current issue, a capturing application could make an informed decision about whether it wants to hand off tab-focus to the captured application, depending on what the captured application is.

### 4. Rejecting Undesired Captures
Issue #143 introduced a web-developer who wanted to discard `MediaStream`s that resulted from the capture of either blocklisted or non-allowlisted origins. If we can enable this use-case along the way, that would be great.

## Solution
Define `MediaDevices.captureHandle`. If set, the application can use it to expose information to potential capturing applications.
1. Origin.
2. An arbitrary "handle" string.

The "handle" string can be an ID which is meaningful given the origin (each origin and its published ID schema).

## Noteworthy
1. **Opt-in**: This mechanism is opt-in.
2. **Application discovering it is being captured**: This mechanism does NOT allow the captured application to discover it is being captured. However, **if** the capturing application wishes to send the captured application a message to that effect, it can. But that's neither new, nor is it problematic.
3. **"Please choose again"**: One possible concern is that the capturing application could use the capture-handle in order to repeatedly ask the user to choose again until the user chooses the capturing app's intended target. I think this concern is invalid because these attacks were equally possible previously:
   * Detecting capture of the current tab is trivial, e.g. by embedding some specific pixels in the current tab or by flashing the entire tab black for a single frame, then searching for that in the capture.
   * Detecting a specific other tab - this implicitly assumes that information can be harvested from that specific other tab, which also implicitly assumes that it can be parsed by visual inspection, which means its capture can also be distinguished from an arbitrary other capture.


Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/166 using your GitHub account


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

Received on Tuesday, 13 April 2021 09:01:03 UTC