which files does Vivaldi encrypt in the profile?

georgep

I have flatpak Vivaldi running on KDE neon, so KDE wallet is used for the encryption of passwords, login cookies, etc.

With flatpak Vivaldi, I can theoretically share Vivaldi between linux distros, and this worked until recent changes, with Neon and Linux Mint in separate partitions, and /home in it's own partition.

As I learned in a recent thread I started (see "Profile decryption problem after last update" 3 weeks ago in this forum), this no longer works because (some of) my VIvaldi files are encrypted by KDE wallet, and Mint knows nothing about that. And trying to put KDE Wallet on Mint seems like a bad idea,

SO - as I mentioned in the earlier thread, I used a /shadowhome directory in each distros partition to store /home stuff that's actually distro specific (symlinked to from /home). My thought is that I can still share most of the Vivaldi profile if I can split of the encrypted profile files to /shadowhome, and let each distro encrypt those files however it wants to.

However, in order to try this, I need a list of which files to split off. Probably only devs have access to such a list so I hope one reads this!

I've been using KDE Neon all the time, but Linux Mint 22 will be released soon, and I would like to fiddle with it, and it would be nice if I had a shared Vivalid working.

(Also, in case it's relevant, I do NOT use Vivaldi to store passwords.)

edwardp

@georgep I believe this would be considered a security issue and do not believe the developers would divulge that information.

Pathduck

@edwardp
Security through obscurity is always a bad idea. Any encryption in Vivaldi is based on Chromium which is open-source and can be examined by anyone, which is a good thing.
https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#Does-the-Password-Manager-store-my-passwords-encrypted-on-disk

Basically, Chromium core handles any encryption in Vivaldi, just like other similar browsers (Chrome, Edge, Opera++). There's tons of information out there for anyone willing to do a little bit of web searching (and lots of people complaining about losing their passwords because they changed their OS user - in ALL browsers...)

And there are no "encrypted files" - the relevant values stored in database tables are encrypted, not the files themselves.

From what I know, it's the following but there might be more.

Passwords: Stored in Login Data (SQLite)
Cookies: Stored in Network\Cookies (SQLite) - possibly different location on Linux.
Extension Data: No idea where this is stored, there's Extension Cookies (SQLite) and several extension-related folders with black-box LDB files.
Credit Cards: If user has saved them, they are in Web Data (SQLite)

For passwords/cookies only the value of the cookie itself is encrypted.
For cookies, if they're unable to be decrypted they will be deleted from the DB on launch. For passwords, they will not be removed so the Login Data file will end up with duplicates for the same site.
For Extension data, again I don't know much. I assume some extensions store some "sensitive" data but not all extension data is encrypted.

For Vivaldi-specific Mail/Feeds/Calendar the passwords are stored where the others are (Login Data). Except for oAuth where the token is stored in Preferences (JSON).

Of special note is the value encrypted_key in Local State (User Data folder). This value is also used to encrypt the data, in addition to the OS key/token.

Note: I'm not actually sure if the Local State encrypted_key value is a Windows-only thing or not. I guess you Linux folks will just have to see for yourself.
https://www.alertra.com/blog/decrypting-browser-passwords-other-secrets

Basically, if you don't store passwords in Vivaldi, and don't mind losing cookies (site logins), don't use extensions that use encrypted data and don't have stored CC's it might work to simply use the same profile. And don't complicate things by using Mail 'cause I have no idea if that transfers and I've never tested it.

Obviously doing this is a not supported configuration and if you run into problems, well - No Rights Given Or Implied.

My advice would be just go ahead and test, rinse and repeat. Use Snapshot profiles for testing to not lose "important" data (then again you don't store passwords so... and cookies ain't important data.)

edwardp

@Pathduck Thank you for the clarification.

Capushon

@Pathduck said in which files does Vivaldi encrypt in the profile?:

Credit Cards: If user has saved them, they are in Web Data (SQLite)

No. Web Data (SQLite) are search engines

Pathduck

@Capushon said in which files does Vivaldi encrypt in the profile?:

No. Web Data (SQLite) are search engines

That's just one table out of several in that DB.

$ sqlite3 "Web Data" ".tables"
autofill                                masked_ibans_metadata
autofill_model_type_state               meta
autofill_sync_metadata                  offer_data
benefit_merchant_domains                offer_eligible_instrument
contact_info                            offer_merchant_domain
contact_info_type_tokens                payment_method_manifest
credit_cards                            payments_customer_data
keywords                                plus_address_sync_entity_metadata
local_addresses                         plus_address_sync_model_type_state
local_addresses_type_tokens             plus_addresses
local_ibans                             secure_payment_confirmation_instrument
local_stored_cvc                        server_card_cloud_token_data
masked_bank_accounts                    server_card_metadata
masked_bank_accounts_metadata           server_stored_cvc
masked_credit_card_benefits             token_service
masked_credit_cards                     virtual_card_usage_data
masked_ibans                            web_app_manifest_section

$ sqlite3 -header "Web Data" "select * from credit_cards;"
guid|name_on_card|expiration_month|expiration_year|card_number_encrypted|date_modified|origin|use_count|use_date|billing_address_id|nickname
51151449-2b1d-4b4a-9d20-977998e38164|Test Testicle|12|2024|v10+8W?\??????hQ?&???y☻+???(?♀▼??2?  /|1720866770|Chrome settings|1|1720866770||Test Card

georgep

The OP here. Taken me a little while to parse all this info.

Let me first state an assumption I'm making: Even tho I'm not storing any, for example, passwords or credit cards, it seems to me I have to separate out those items anyway, as otherwise it's possible the Chromium core will detect some conflict and get upset.

So I need to split off every file that can contain encrypted data.

Thus far I have, based on @edwardp 's post:

Login Data
Cookies file (I did not see anything like "Network\Cookies")
Extensions - a directory with a few files with names in scrambled lower-case letters. (I did not see an "Extension Cookies".) Maybe something more needed here?
Web Data
Local State

So I'll go ahead and split those off and see what happens ...

edwardp

@georgep said in which files does Vivaldi encrypt in the profile?:

Thus far I have, based on @edwardp 's post:

Not my post.

georgep

@edwardp Oops! Yes, it was Pathduck's! Sorry.

Doing a bit more research before trying anything.

It occurred to me that once I move the files and folders listed earlier to the Neon partition, VIvaldi on Mint will see nothing but empty files and folders in their place, and may not be able to handle that.

But my additional research suggests that in Linux, Chromium makes calls to libsecret which in turn deals with gnome-keyring or kde wallet. This leads me to wonder if they can both encrypt and decrypt in the same way. For example, can I just change some "seed" on Mint so it encrypts and decrypts the same as on Neon?

Then no spliting off of files and folders would be necessary.

I haven't retried Viv on Mint since the previous pop-up problem, but a that time, Viv decided somehow that the Neon encrypted values would not work. Was just because it just stored the name secret service" use for the encryption (e.g. kde or gnome) or is it some test decryption that should produce a certain value? If the latter, it may be possible for gnome keyring to produce the same result as kde wallet.

I need to research further what encryption methods kde and gnome use ...

georgep

Not easy to find out the encryption options for gnome-keyring and kde wallet.

gnome-keyring - A 5 year old reddit post says AES-128.

kde-wallet - an older KDE document says blowfish or PGP.

So, thus far, no chance of making them produce the same results.

becm

@georgep in current versions, only the Symmetric encryption key is stored in a wrapped state in a platform secret store.
e.g. kwallet5: <default keyring> / Chrome Keys / Chrome Safe Storage
In case of Vivaldi, Chrome branding seems to still be active.

This value is used instead of the standard secret in case of the basic back end.

Syncing that value so each installation sees the same (unwrapped) key should lead to shareable encrypted data between platforms.

In case of OAuth, it might be interesting if entries in the oauth table in Preferences are also encrypted.
If not, Chromium devs introduced a security leak there.

Pathduck

@becm Finally someone actually on Linux who seems to understand how things work

Syncing that value so each installation sees the same (unwrapped) key should lead to shareable encrypted data between platforms.

Yes, I've been thinking along the same lines - they are just keys. Depends if exporting the keys and importing into another keystore is actually possible. Are there UIs or commands to deal with these stores directly?

If you use OAuth, you might be interesting if entries in the oauth table in Preferences are also encrypted.

A quick test here shows they are. Simply removing part of the encrypted_key in Local State, I had to reenter all my oAuth credentials in Vivaldi Mail.

Going by the very useful article I linked earlier:
"Just like with the "DPAPI" prefix, any data Chromium encrypts with its own internal AES implementation gets a prefix. In this case it is "v10"."

$ echo "djE...nfGg==" | base64 -d | hexdump -C
00000000  76 31 30 90 7b e8 7b 25  c8 5b a7 c6 c7 dc 46 83  |v10.{.{%.[....F.|
00000010  b9 ed 0e 7a 43 65 78 24  e6 72 aa 37 7f 1f 0d ea  |...zCex$.r.7....|

And accordingly, the same with encrypted_key:

$ echo "RFB...25no=" | base64 -d | hexdump -C
00000000  44 50 41 50 49 01 00 00  00 d0 8c 9d df 01 15 d1  |DPAPI...........|
00000010  11 8c 7a 00 c0 4f c2 97  eb 01 00 00 00 21 fd cd  |..z..O.......!..|

Out of interest - does Linux have this encrypted_key value in Local State at all?
Mine starts with DPAPI since this is Windows.
Also very interesting to see "Vivaldi" in the key itself.

becm

@Pathduck getting the actual shared secret on Windows seems to be a bit more complex.

My guess based on the Windows recovery approach, sharing a profile folder will not work there.
Platform specific parts of the encryption are put into Local State.
There might however be a trick I'm not seeing at the moment…

Sharing Login Data between different platforms also seems impossible.
Different encryption schemes are used for password_value entries.

Sharing data between Linux systems, assuming careful setup of secret store data, at least seems as if it might work.

georgep

Lots of interesting info here, but I'm hoping I don't need to become a security expert myself.

@becm said in which files does Vivaldi encrypt in the profile?:

Syncing that value so each installation sees the same (unwrapped) key should lead to shareable encrypted data between platforms.

How would you suggest I try to do this? (You can try the short explanation first - I have years of OS and app programming experience behind me so hopefully I could understand that.)

becm

@georgep to sync values:

start Vivaldi from the first user account
read out the value of Chrome Keys/Chrome Safe Storage in whichever secret store is used
set that value on further user account secret stores which should share the profile before Vivaldi is ever started there.

Nowadays, if a Who is using this computer dialog opens when starting Vivaldi on the 2nd profile;
abort the startup, something went wrong (or for some reason this approach is actually not working at all).

georgep

@becm OK, that worked! I'm replying here from Viv on Mint as opposed to my usual Neon. Thanks!

I will shortly post some details for anyone else who may want to try this in the future.

georgep

Here's some details for anyone else who may want to try sharing a flatpak vivaldi between linux distros running different "secret services".

To see what "secret service" your distro is running, you can run, if the command is
available or installable:
/usr/lib/qt6/bin/qdbus --session org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID org.freedesktop.secrets

Failing that, you can try this: open a command line window and try:
ps aux | grep gnome-keyring-daemon
OR
ps aux | grep kwallet
to see which one is running (if any).

(Note you'll always get a hit on the grep itself, but ignore that one.)

While in a system running kwallet:

start kWalletManager from the menu
under "Folders" click the "+" next to Chrome Keys
click the "+" next to "Passwords"
click "Chrome Safe Storage"
then in the right hand panel, click "Show Contents" and the key is visible (and changeable, so be careful)

While in a system running gnome-keyring-daemon:

start "Passwords and Keys" (also called "Seahorse") from the menu
go to Passwords - Login - Chrome Safe Storage
view the key by clicking on the key icon (or copy it with the "copy" button); this
one is changeable too, so use due care

So you want to copy/paste the key from one of those into the other, depending on which system has the already working Vivaldi. (Be sure Vivaldi is NOT already launched on the system you are modifying.) Once you've pasted, you can start Vivaldi.

The fortunate part here is that Vivaldi (Chromium core) is ONLY using the distro's own "secret service" for the storage of its key; all the encryption is done internally to Chromium core, based on that key. So just use the same key and everything works.