Using Profiles to Isolate Browsing Contexts with Vivaldi (or Chrome)

A few days ago, I lost access to all my saved passwords in Vivaldi. I was looking to securely store database passwords on my system using the "Password and Keys" app (GnuPG/seahorse) in Linux Mint and inadvertently regenerated the default "Login" keyring where Vivaldi (and Chrome) store the "master" decryption key for stored passwords.

After recovering and resetting passwords for websites, I went down the rabbit-hole of understanding how passwords are managed by the browser. Decrypting stored passwords from the browser's "Login Data" SQLite database stored in your browser profile directory (see "Profile Path" in vivaldi://about/) is a piece of cake...so long as you know the randomly generated string stored by the browser in your keyring. The "Login Data" file is still helpful to remind you of the websites that require a password reset (usernames and login URLs aren't encrypted).

I had configured my system to backup my browser profiles using the excellent Déjà Dup that runs every day at login. My OS root partition and a /data partition (where projects and code live) also get backed up regularly using the reliable Timeshift. What isn't backed up is almost everything in the /home partition, where the keyring lives :(

I use separate browser profiles for different clients. This helps isolate Vivaldi speed dials, notes, bookmarks, login pages, and...keeps me from logging into the wrong client AWS account ;)

Up until the above incident, I used simple shell scripts that fired up vivaldi-stable --user-data-dir=<path-to-store-browser-files> (and Déjà Dup was configured to backup those folders). Using isolated "user-data-dir" folders meant I could only launch the browser in that context using the shell-script (which is a simple as Alt+F2 and typing vivaldi-<context-name>). I had assumed that using a separate "user-data-dir" would keep things clean and isolated, but only recently realized using separate "profiles" was good enough (and saved me some disk space on my paltry 256GB SSD). Beyond this, I was interested to know how things worked, while also being able to use the GUI option to toggle profiles.

Profiles you create are super-portable. I could migrate profiles from isolated user-data-dir regime to a single directory and they resumed working just as before. You can "register" those profiles for the GUI by editing profiles.info_cache node in the "Local State" JSON file in your user-data-dir directory. The profile node has a lot more options than are exposed by the browser GUI!

Saved passwords, sadly, could not be recovered after the keyring debacle. The browser also failed to store any new passwords for some reason, displaying a "no saved passwords" message even after saving new passwords; requiring me to delete the "Login Data", "Login Data-journal" files, and letting the browser regenerate them.

Once the browser starts storing new passwords encrypted with the newly generated key stored in your keyring (named "Chrome Safe Storage", it may be a good idea to backup the keyring files (under $HOME/.local/share/keyrings) so that recovering passwords from your "Login Data" SQLite dbs may be possible in the future. You can import an old keyring file into seahorse to recover old passwords, so log as you know the keyring password (unless otherwise, it's your OS login user password).

You can use shell scripts to launch Vivaldi (or Chrome) with a specific user profile using vivaldi-stable --profile-directory='profile-name' option. In case you choose to have certain profiles stored under different user-data-dir's you can add the --user-data-dir=<path> switch.

Note that using multiple profiles under a single user-data-dir behaves differently from using multiple user-data-dirs. In the former, the browser process for all profiles is the same, meaning if you hard-exited a single browser window (Ctrl+Shift+Q in my case), all other profile windows would close and the process would terminate.

In case of isolated user-data-dirs, each browser process launched with a different user-data-dir switch has an independent lifecycle, presumably consuming higher system resources.

In summary, profiles are a great way to isolate browsing contexts. I've now configured the Déjà Dup app to create backups for the keyring(s) and $HOME/.config/vivaldi/profile-* directories (renamed "Profile 1" etc. to "profile-<context-name>" in the "Local State" JSON file).