[mediacapture-screen-share] Allow apps to avoid riskier display-surface types (#261)

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

== Allow apps to avoid riskier display-surface types ==
Some video-conferencing tools offer admin settings that allow tuning what the user may do. For example, some admins allow sharing of screens when all participants are employees, but restrict to window-sharing in calls that have external participants (under the assumption that accidental leaks would be more costly in such scenarios).

Native apps allow such fine-grained control. Web apps... almost. Web apps can call `getDisplayMedia()` and pray. If the user chooses to share a monitor, these apps can stop the capture and chide the user for making an improper choice - a bad experience for all involved (remote participants included, as they sit and listen to the user complain about the Web app).

It would be better if we allowed Web apps to remove the `monitor` option from what is offered to the user. We could go with an API shape that's similar to the existing [selfBrowserSurface](https://w3c.github.io/mediacapture-screen-share/#dom-displaymediastreamoptions-selfbrowsersurface) option, which is similar.

```webidl
enum MonitorTypeSurfacesEnum {
  "include",
  "exclude"
};

dictionary DisplayMediaStreamOptions {
  MonitorTypeSurfacesEnum monitorTypeSurfaces;
};
```

Note that I propose a shape that only allows removing monitors, which is the riskiest option. Whether windows should be exclude-able is its own discussion. I think that if we ever decide that these too should be exclude-able, we could specify that one cannot exclude windows without also excluding monitors, lest the user be nudged towards monitors.

If we also specify [getSupportedOptions()](https://github.com/w3c/mediacapture-screen-share/issues/260), apps would be able to know ahead of time whether such shaping is possible, btw.

CC @Coread, who is interested in such a mechanism. (He might have different opinions about the API shape and some finer points, though. Please let us know.)

---
It should be mentioned that discussions in this vein arose somewhat often. I believe this particular variant has not been rejected before. The latest discussion on an adjacent topic was #209, which culminated with the aforementioned [selfBrowserSurface](https://w3c.github.io/mediacapture-screen-share/#dom-displaymediastreamoptions-selfbrowsersurface) being specified - a success-story which I hope to repeat.

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


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

Received on Wednesday, 22 March 2023 18:20:32 UTC