🔧 Avoiding oversharing when screen sharing

🕛 Zeit seit Veröffentlichung: 741 Tage, 12 Stunden 35 Minuten
📆 Veröffentlicht am: 29.09.2022 um 02:00 Uhr
Nachrichtenbereich: 🔧 Programmierung
🔗 Quelle: developer.chrome.com

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.
• The displaySurface option can indicate that the web app prefers to offer a specific display surface type (tabs, windows, or screens).
• The surfaceSwitching option indicates whether Chrome should allow the user to dynamically switch between shared tabs.
• The selfBrowserSurface option can be used to prevent the user from sharing the current tab. This avoids the "hall of mirrors" effect.
• The systemAudio option ensures Chrome only offers relevant audio-capture to the user.

# Reordering the selection offered to the user

When 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:

# Privacy

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)
• Language
• System notifications
• Running apps
• Installed apps
• Installed extensions
• Bookmarks
• 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.

# Feature-completeness

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:
  • Capture Handle allows the identification of the captured tab and establishment of a communications channel with it.
  • Region Capture allows further scoping down of 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

The new displaySurface, surfaceSwitching, selfBrowserSurface, and systemAudio options will allow you to tailor your screen sharing experience.

Check out Privacy-preserving screen sharing controls for more information.

# What's next

The 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.

# Acknowledgements

Hero image by Jelleke Vanooteghem.

Thanks to Rachel Andrew for reviewing this article.

...