[mediacapture-screen-share] Suggestion: Moderate spec language about offering all surface types (#326)

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

== Suggestion: Moderate spec language about offering all surface types ==
## State of the Art
The spec currently reads:
> The user agent MAY use the presence of the [displaySurface](https://www.w3.org/TR/screen-capture/#dfn-displaysurface) constraint and its value to influence the presentation to the user of the sources to pick from. The user agent MUST still offer the user unlimited choice of any [display surface](https://www.w3.org/TR/screen-capture/#dfn-display-surface). The user agent is strongly recommended to steer users away from sharing a monitor, as this poses [risks to user privacy](https://www.w3.org/TR/screen-capture/#security-and-permissions).

That is, we have previously specified that `displaySurface` can serve as a hint to the user agent about which surface type should be presented most prominently to the user. But we require that all options still be offered to the user.

Chromium has implemented this as follows (try it out):
- https://screen-sharing-controls.glitch.me/?displaySurface=browser
- https://screen-sharing-controls.glitch.me/?displaySurface=window
- https://screen-sharing-controls.glitch.me/?displaySurface=monitor

Basically, Chromium always uses a 3-pane dialog, and the Web can tell Chromium which pane is pre-selected. But the user can always change panes.

<p align="center">
<img src="https://github.com/user-attachments/assets/fe2e7ce4-7a03-45e9-9e83-e131f0098080"/>
</p>

But things don't work as smoothly if we want to use the new native macOS picker. It looks like Safari had to contend with a similar issue, and they chose to use a text-heavy dialog, pictured below.

<p align="center">
<img src="https://github.com/user-attachments/assets/314d51cb-0450-4a52-b710-8cb63870d85a"/>

I am not sure Chromium should replicate this approach. With tabs thrown into the mix this becomes a three-option dialog, requiring multiple clicks and a lot of reading.

## Solution?
We should consider moderating the spec language here, allowing the hint to be taken as an instruction. That is, UAs should be free to **only** offer the type of surface (tabs/windows/screens) that the app requests. For non-malicious Web apps, this allows the UX question to be delegated to the Web-app, potentially saving a click.

<p align="center">
<img src="https://github.com/user-attachments/assets/adeb9796-3f74-44f1-9ca1-a70f8aad095b"/>
</p>

One might object that this allows the user to be "pushed" to share a screen, compromising their privacy/security. But I'd argue back that such pushing is already possible, as the Web app can just `stop()` the tracks if the user chooses anything but the screen, the forcefully suggest the user try again.

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


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

Received on Thursday, 12 June 2025 14:58:55 UTC