End-to-end encrypted profile sync means your browser profiles are encrypted on your own computer, with a key only you hold, before they are uploaded. The sync server stores and forwards them but cannot open them. "Encrypted in transit" and "encrypted at rest" are not the same thing: both still let the provider read your data whenever it chooses.
For browser profiles this matters more than for most data. A synced profile carries live sessions: the cookies that keep you signed in, your proxy credentials and the settings that make up each profile's identity. This post explains how end-to-end sync works, what a server still needs to see, how keys and recovery fit together, and how to tell whether a provider's sync is end-to-end at all.
Three kinds of "encrypted"
Providers use the word loosely, so it helps to separate three meanings.
| Kind | Who can read your data | What it protects against |
|---|---|---|
| In transit (HTTPS) | The provider, once it arrives | Someone on the network between you and the server |
| At rest | The provider, which holds the disk key | A stolen disk or a leaked backup file |
| End to end | Only devices that hold your key | The above, plus the provider itself, its staff and anyone who breaks into its servers |
Most services do the first two. Only the third keeps a breach of the provider from becoming a breach of your accounts.
How end-to-end sync works
The design is the same in outline wherever it is done well.
- A key is made on your device. The first time you sign in, your computer generates a random account key. The server never sees it in readable form.
- Your password protects the key. A slow key-derivation function, such as scrypt, turns your password into a key that wraps (encrypts) the account key. Only the wrapped copy is uploaded, so another of your computers can download it and unwrap it with your password.
- Signing in uses a separate secret. The password is never sent. The device derives a separate sign-in key from it, and the server checks that, so knowing what the server stores does not reveal the key that encrypts your data.
- Everything is encrypted before upload. Profiles, cookies, proxies and settings are encrypted with keys that come from the account key. The server stores ciphertext.
- Other devices decrypt locally. Your second computer downloads the ciphertext and decrypts it with the same account key, unwrapped with your password.
If you change your password, only the wrapper changes: the account key is re-protected under the new password, and nothing needs re-encrypting.
What the server still sees
End-to-end encryption hides contents, not the fact that something exists. A sync server has to know enough to deliver the right item to the right device and to resolve conflicts. Typically that means:
- your account details and devices;
- for each synced item, its type, an ID, a version, its size and when it changed;
- which device currently has a profile open, if the service keeps a profile on one computer at a time.
What it should not see is any of the contents: profile names and notes, cookies and site storage, proxy addresses and passwords, fingerprint settings. A trustworthy provider lists both columns in its privacy policy, so you can read exactly where the line is.
Recovery: the honest trade
If only your password protects the key, forgetting the password would lose the data. End-to-end systems solve this without giving the provider a key:
- A recovery key, shown once when the account is created, which can unwrap the account key in place of the password. Write it down and store it offline.
- A device that still holds the key. After a password reset, a computer that is still signed in can re-protect the key under the new password.
- A trusted person, in team setups, who holds an encrypted copy of your key and can hand it back after you both confirm a code.
Notice what is missing: the provider resetting your password and handing your data back. If a service can do that with no recovery key and no other device, it holds a key to your data, and its sync is not end to end.
How to check a provider yourself
You do not need to read source code to get a good idea. Five questions settle most of it.
- Does the privacy policy list what the server cannot read? Look for a specific list (cookies, proxy credentials, fingerprint settings), not a general "we take security seriously".
- Is a recovery key shown when you sign up? No recovery key usually means the provider can recover the data itself.
- What happens after a password reset on a new device? If your data appears with nothing but an email link, the provider holds a key.
- Does the password ever leave your device? The documentation should say the server stores a hash of a derived sign-in key, not the password.
- Who else in a team can read your data? Teams need some way to share keys. The answer should be named people, never "the server".
How Browz sync works
Browz is cloud-only, and every plan includes sync, Free included. Profiles, proxies, folders, automation flows, a set of settings and each profile's browser session (cookies and site storage) sync between your computers, so a profile continues where it stopped. Browsing history never syncs, and settings that describe one machine stay on it. The details are in accounts, sign-in and profile sync.
Everything that syncs is end-to-end encrypted on your computers with a key from your password, as the security page sets out:
- The account key is created on your computer at your first sign-in and protected by your password, so there is no separate passphrase. Browz shows a recovery key once.
- The password never reaches the server. The server keeps a scrypt hash of a sign-in key derived on your device, never the password and never the key that encrypts your data.
- The server refuses anything that is not encrypted, and stores only ciphertext and wrapped keys it cannot open. The Privacy Policy lists what it cannot read (profiles, cookies and site storage, proxy addresses and credentials, fingerprint settings and seeds) next to the metadata it can.
- Proxy credentials are sealed in an encrypted store when you save them and never sent back to the app window.
- Exports are encrypted too. A profile exported as a
.browzprofilefile is encrypted with a passphrase you choose, using scrypt and AES-256-GCM.
Changing your password in the app re-protects the key and signs your other computers out. After a reset, a computer that still holds the key keeps working, or you can enter the recovery key; your password, encryption key and recovery walks through each case.
In a team
Teams share profiles, folders and proxies at view, launch, edit or manage, and the records stay end-to-end encrypted. The workspace owner's Browz holds an encrypted copy of each member's account key, which lets the owner recover a member who forgets their password and see every member's profiles. Members are told this when they join, and the server cannot read either copy. A shared proxy's password stays encrypted too, and seeing it is a separate, logged action.
Frequently asked questions
Is encrypted browser sync safe for cookies and logged-in sessions?
When it is end to end, yes: the cookies are encrypted on your device and the server holds only ciphertext, so a breach of the server does not expose your sessions. With encryption only in transit or at rest, the provider can read them, so ask which kind a service uses before syncing sessions.
What happens if I forget my password?
With end-to-end sync, you use whatever recovery you set up: a recovery key, another computer that is still signed in, or, in a team, the workspace owner. In Browz those are the three routes, and the help article on account keys explains each one step by step.
Can the sync provider read my proxy passwords?
Not with end-to-end sync. Proxy addresses, usernames and passwords are encrypted on your device with the rest of the profile. In Browz they are also sealed in an encrypted store on your computer when you save them.
Does end-to-end encryption slow sync down?
Not noticeably. Encrypting and decrypting a profile on a modern computer takes a fraction of the time the upload takes. The slow step is deliberate and happens once: deriving the key from your password when you sign in.
Who can read my profiles in a shared workspace?
In Browz, the people you share them with, at the level you choose, and the workspace owner, whose Browz holds a copy of your key. The server cannot. If you want profiles nobody else can read, keep them in a separate account outside the workspace.