When an app’s site says “your data is encrypted”, that sentence could be describing any one of four different things. All four are correctly called encryption. The difference is a long way from a technical footnote. It decides who besides you can read what you wrote.
Four different things, one word
Encryption in transit. Data is protected while it travels between your device and the server. Every site has this now, and its absence would be a defect; but it says nothing about what happens once the data arrives.
Encryption at rest on the server. Data sits encrypted on the server’s disk. This helps against someone stealing the disk. It doesn’t help against the party running the server, because the key is sitting there too; they read it when they want to.
Encryption on the device. Data sits in an encrypted store on your machine. The app reads it while the device is unlocked and you’re signed in; someone who takes a copy of the drive while it’s off cannot.
End-to-end encryption. Data is encrypted on your device, travels encrypted, and is decrypted only on your devices. The server holds an opaque blob and doesn’t know what’s in it, because the load-bearing part here is that the key never reaches the server at all.
The first three usually coexist in a product. The fourth is a separate design decision, and it almost always costs something.
When an “end-to-end” claim is partial
A product can say it does end-to-end encryption and be telling the truth about some of your data and not the rest. The usual gaps: note bodies encrypted while titles stay readable; attachments and images stored through a different path; the search index kept server-side; and the whole model changing the moment sharing is switched on.
None of that is bad faith on its own. Server-side search over encrypted data is a genuinely hard problem, and plenty of products keep the index in the clear because they haven’t solved it. The problem is that the detail stays invisible underneath the phrase “end-to-end encrypted”.
The one question worth asking
Instead of reading the encryption page, ask one thing: where is the key?
If the answer is “derived from your passphrase and never sent to our servers”, you’re looking at end-to-end encryption. And it has an unavoidable consequence: if you forget that passphrase, nobody can recover it for you. When a product claims both end-to-end encryption and the ability to restore your account after you forget your password, one of those two sentences is being told incompletely.
The second question: who verified it? Without an independent security audit, every statement above is the vendor’s account of itself.
Where Context sits
In Context, data is held in an encrypted store on your device, and while sync is off it doesn’t go anywhere. Vault records, meaning API keys and passwords, are stored encrypted and stay masked in the interface until you choose to reveal one.
End-to-end encryption is not complete for every scenario, and no independent security audit has been done; the scope and the auditor’s contract are ready, but there is no report. We’re writing that here because recommending you ask these questions of other people while withholding our own answers would be incoherent.
The current list lives on the security page and changes as the product does. If you’re deciding whether to sync something sensitive, read that page first.