How new web APIs and Chrome’s Privacy Sandbox made us overhaul our Local Recording feature

For a long time now, Whereby has offered paying customers using Chrome (or Chromium-based browsers) the option to locally record their Whereby meetings. This feature cleverly uses the Screen Capture API and Chrome’s capability to share the content of a selected tab, turning it into a downloadable WebM file — other browsers only allow window or screen sharing, which is why they aren’t supported just yet.

In recent months, we’ve been making a number of changes to this feature — some of these adjustments have resulted in UX improvements by using new APIs, while others were needed for compatibility with Chrome’s new Privacy Sandbox-related browser restrictions.

Navigating through permission prompts

When implementing our local recording feature on top of the Screen Capture API, we had to get around a tricky usability problem: the browser’s screen sharing permission dialog offered a lot of options and was not optimized for a basic recording use case that just requires sharing the Whereby meeting tab. Indeed, as you can see in the highlighted screenshot, we had to carefully guide customers making sure they’d find and select the specific tab their meeting was happening in — if the wrong surface (such as another tab, window or the entire screen) was selected, the recording would yield unintended results or even fail altogether.

We decided that asking users of our recording feature to install a Chrome browser extension was the most straightforward solution: the extension put available tabs front and center and rewrote the title of the current tab with “SELECT THIS AND PRESS "SHARE" TO RECORD”. Hacky? Oh yes! Also, it didn't work in embedded rooms, which wasn't ideal...

displaySurface and preferCurrentTab

Since then, folks in the Google Meet team have been spearheading two new getDisplayMedia() options that have helped us to overcome these hurdles and implement a much simplified user experience:

• displaySurface: this option allows developers to influence the display of the screen sharing permission prompt, pre-selecting one of the available display surfaces (tabs, windows or screens).

• preferCurrentTab: this option, which is still in an experimental stage, shows the current tab as the only selectable surface in the screen sharing permission prompt, and makes sharing the current tab a simple one click operation.

These two additions have allowed us to dramatically simplify the local recording permission journey, even allowing us to get rid of the requirement to install the Whereby extension altogether — neat!

This is what the new local recording start flow looks like — no extension needed, and it works in embedded rooms as well.

Privacy Sandbox’s Storage Partitioning

As part of its Privacy Sandbox project, the Chrome team has been working on a privacy feature called Storage Partitioning, which it has enabled by default from Chrome 115 onward.

When we tested Whereby’s readiness to deal with this API change, we bumped into an unexpected issue when storing local recordings.

When recording a meeting locally, we’d capture it as a WebM video file, and then store it in the browser cache using IndexedDB. We then would offer users an option to download the resulting file immediately or else, to fetch it later on through the Whereby customer dashboard. It was the latter option that started causing problems…

You see, when customers embed Whereby’s video calling web component in a website (e.g. example.com), Whereby’s web component is served from a custom Whereby subdomain associated with their account (e.g. mycompany.whereby.com); however, when storing session data in the browser cache, the origin chain is no longer mycompany.whereby.com as it used to be, but instead it’s now the origin of the embedding website — in this case example.com. In practical terms, this meant that the Whereby customer dashboard, available on mycompany.whereby.com/org/welcome, was not able to discover and list locally stored recordings as the origin chains weren’t matching anymore!

Rethinking video downloads

We considered a couple of approaches, and looked into APIs like sharedStorage and federated access, but in the end we settled on a more straightforward approach: when someone initiates a recording and then stops it, the resulting file is now automatically downloaded to the Downloads folder on the user’s local machine, rather than being stored in IndexedDB. This works very well, and to be honest, it might even make for a better, more straightforward user experience.

TL;DR:

Two relatively recent changes in Chrome / Chromium made us overhaul our local recording feature: Storage Partitioning made us consider modern browsers’ more narrow definition of origin chains and make the necessary changes for that, and new APIs like displaySurface and preferCurrentTab allowed us to get rid of some creative, but clunky extension-based workarounds when screen-sharing.

Give local recording a try and let us know what you think! Also: did you know about these API changes? Let us know on Threads or Discord!