How does #PaleMoon compare to other web #browsers when it comes to the security of synced data?

Pale Moon ( #Weave ):

• Your secret key is never sent to our servers, we only have encrypted data which we can never read without your key
• Pairing a new device while having an already synced device nearby is easy and does not need your sync account’s email and password, while still being cryptographically secure: the target device can generate a random 12-character code which will be inputted in the device already synced with your account in order to complete pairing. This preferred “quick link” method uses J-PAKE to transfer credentials and the secret key without having to show them to the screen, therefore avoiding key disclosure better. See our docs: https://www.palemoon.org/sync/help/easy-setup.shtml
• If an already synced device is not nearby, then you will need your account’s email and password. To get the synced data, you will need a copy of your secret key. If you don’t have access to any synced device which will have your key, then you can generate a new one within the browser itself (after logging in with your credentials), but all synced data stored in the server will be inaccessible and erased.
• The sync service is not meant for long-term backup and our storage is limited, therefore we limit each account’s sync storage to 30 MB, and if your account has not been synced for 2 or 3 months straight, we schedule your synced data or account respectively for deletion in the next maintenance window.
• Resetting your sync account’s password within the browser is not yet supported. However as long as nobody has your key, nobody will ever be able to access it, and given enough time, your data in encrypted form will not even be in our servers anymore because of the regular maintenance. For now you will have to DM Moonchild on the forums to get him to delete your account so you can re-register: https://forum.palemoon.org/viewtopic.php?f=52&t=31143&p=251609#p251616
• Sync service can be self-hosted! Source code for the implementation we use can be found at https://repo.palemoon.org/Moonchild/FSyncMS. It is basically a minimal #Weave / Sync 1.1, which is the previous sync system Mozilla used before Firefox 29 moved to Sync 1.5 + FxA, and it requires a LEMP stack.

Mozilla Firefox ( #FirefoxSync ):

• Synced data cannot be read by Mozilla
• Your secret key is sent to Mozilla’s servers, but it is first hashed client-side with your Firefox Account’s (FxA) password before it’s sent
• This means by default (i.e. one didn’t place a 2FA in their FxA) one can pair a new device and recover their synced data as long as one knows the FxA password, even if they can’t access any of the synced devices. The security of your synced data depends solely on your FxA password (which is why we didn’t adopt it and kept/brought back Sync 1.1 even if it got completely removed by the time we made our final hard fork of Firefox 52 ESR’s platform code)
• If you forget your Firefox account’s password and reset it, your previously synced data will be inaccessible
• Can be self-hosted, but truly self-hosting everything is a bit complicated because the sync service is dependent on FxA’s authentication service which is its own server. Docs can be found here: https://mozilla-services.readthedocs.io/en/latest/index.html

Google Chrome:

• Synced data can be read by Google by default
• Data can be made unreadable even to Google by setting a passphrase, but that’s dependent on the passphrase’s strength
• Resetting your passphrase will make previously synced data inaccessible
• Authentication can be three-factor: your Google account’s password, then the Google account’s own 2FA (e.g. TOTP), and lastly the local passphrase.
• Details about the sync system is obscure, so the above is based on what we probably know. Obviously this means Chrome’s sync can’t be self-hosted