CurbAppsOne claim keeps appearing in the CurbApps docs: "we cannot read your synced data." That is not a slogan. It is a consequence of how the system is built. Here is the model in plain language.
The shape of it
Personal data such as a bookmark, note, OTP account, or vault entry is represented as an entity. Before a synced entity leaves your device, it is encrypted with AES-256-GCM. The server receives ciphertext, stores ciphertext, and forwards ciphertext. It does not receive an unwrapped data key, so it cannot read the plaintext.
Where the key lives
The app generates the data-encryption key on your device. A master password derives a separate wrapping key that protects it. Local auto-unlock keeps device-only key material on that installation.
- Master password: the data key is wrapped under a key derived from a password only you know. Unlocking requires it, and an encrypted recovery blob lets another signed-in device restore the workspace.
- Auto-unlock: the device holds local key material without asking for a password. This mode is local-only and does not create the recovery material required by the current cloud sync path.
Use a master password when you want cloud sync, the web data manager, or recovery on another device.
What the server can see
The server can see that you synced something, at some size, at some time. It also needs routing metadata such as the account, product scope, and entity type. It cannot read encrypted fields such as titles, note content, passwords, OTP secrets, or tags.
What this costs you
Zero-knowledge has a trade-off: there is no server-side "forgot password" path for encrypted workspace data. Lose the master password and no support agent can decrypt that data for you. The recovery blob helps a device restore the wrapped key, but it does not reveal the password or plaintext to the server.
One deliberate exception
One Premium feature, bookmark classification, sends a title and URL to a classifier. Page content is never sent, and the result is encrypted before it syncs.
In summary
Encrypt on the device, derive keys on the device, store ciphertext on the server. Three decisions, one outcome: a sync service that does not need your trust, because it cannot abuse it.