Sharing tabs, windows, and screens is already possible on the web platform thanks to
getDisplayMedia(). We’re now shipping the following improvements that guide the user away from accidental oversharing:
- Sharing tabs is now the default option, rather than sharing screens.
displaySurfaceoption can indicate that the web app prefers to offer a specific display surface type (tabs, windows, or screens).
surfaceSwitchingoption indicates whether Chrome should allow the user to dynamically switch between shared tabs.
selfBrowserSurfaceoption can be used to prevent the user from sharing the current tab. This avoids the "hall of mirrors" effect.
systemAudiooption ensures Chrome only offers relevant audio-capture to the user.
Reordering the selection offered to the user
getDisplayMedia() is called, users are presented with a media picker which allows them to share whichever display surface they would like. Experience shows that the ordering of the offering affects the users’ selection. We are experimenting in Chrome 107 with reordering the picker in order to nudge users towards tabs, which is the best option in the majority of cases.
The expected benefits are as follows:
Previously, screens were offered as the default option. This is the least privacy-preserving option, as users may end up exposing more personal information than they had originally intended. Such as:
- Timezone (via the system clock)
- System notifications
- Running apps
- Installed apps
- Installed extensions
- Browsing history (via the omnibox)
- The user’s profile pictures (browser, system, other apps)
- Rugby-club affiliation (via desktop wallpapers)
- Audio notifications from backgrounded apps, like a calendar
Most of these concerns are mitigated by sharing a tab instead of a screen.
Tab sharing is more feature-complete:
- Sharing tab audio is supported on all platforms; sharing system audio and window audio is only implemented on some platforms, at the time of writing.
- When sharing tabs, complementary features enable closer collaboration with the captured content:
Performance and user experience
When a user intends to share another web app, it’s preferable to directly share the tab running that app, rather than its Chrome window, or even the entire screen.
- The tab will continue being shared even if the user interacts with another app.
- The resulting image on remote users’ participants is going to be “zoomed in on the action” and therefore clearer.
- Avoiding the capture, encoding and transmission of irrelevant content saves CPU and bandwidth.
- A more stable frame-rate is possible for tab-capture than for other types of capture.
New screen sharing controls
systemAudio options will allow you to tailor your screen sharing experience.
Check out Privacy-preserving screen sharing controls for more information.
suppressLocalAudioPlayback option will indicate whether the audio playing in a tab would be played out of the user’s local speakers.
Conditional Focus will allow the capturing web app to instruct the browser to either switch focus to the captured display surface, or to avoid such a focus change.
Hero image by Jelleke Vanooteghem.
Thanks to Rachel Andrew for reviewing this article.