The Encryption Theater of Journaling Apps

"Your data is encrypted in transit and at rest" is printed on the privacy page of nearly every journaling app, and it's almost always true. It's also, on its own, close to meaningless as a privacy guarantee — because it describes protection against everyone except the one party in the best position to read your journal: the app's own server.

What "encrypted in transit and at rest" actually covers

These two phrases have precise, narrow meanings:

• In transit — the connection between your phone and the server is encrypted (TLS/HTTPS), so someone intercepting your Wi-Fi traffic can't read the raw data. This is table stakes; every legitimate app has had this for over a decade.
• At rest — the data sitting in the company's database is encrypted on disk, so if someone steals the physical hard drive or gets unauthorized filesystem access, they see ciphertext, not your entries.

Both of these protect you from a third party intercepting the connection, or a burglar stealing a server. Neither one protects you from the server itself — the party that holds the decryption key and has to use it to do literally anything with your data, including running the AI feature you signed up for.

Where the plaintext actually goes

Here's what happens, step by step, when a cloud-AI journaling app generates something like a daily reflection or answers "what's been stressing me out lately":

That fourth and fifth step is the actual privacy surface. It's rarely mentioned on the marketing page, because "encrypted in transit and at rest" is true right up until the exact moment your journal needs to be useful — and then it briefly, necessarily, isn't.

This isn't a bug in any particular app. It's an unavoidable consequence of running AI in the cloud on encrypted data: the model can't reason about ciphertext.

"Zero-knowledge" AI is not really a thing yet

There's active research into techniques like homomorphic encryption and secure enclaves that could let a server compute on data without ever seeing it in the clear. It's real, it's promising, and it is nowhere close to running a useful generative language model at consumer scale on a phone-app budget today. Any journaling app claiming "encrypted AI processing" in 2026 is almost certainly describing encryption at rest plus a brief decrypted window during inference — not literal zero-knowledge computation. Worth asking directly if a company's marketing implies otherwise.

The only clean fix: don't decrypt anywhere but the device

The straightforward way to close this gap is to never let the plaintext exist outside hardware you personally control. That's the entire architectural premise behind MirrorNotes:

• Entries are encrypted on-device, and the decryption key never leaves the device either.
• The AI model (Gemma 3, 1B parameters) runs locally, on your phone's Neural Engine — it reads the plaintext only inside your own hardware, and that plaintext is never transmitted anywhere to make that possible.
• There's no step 4 and step 5 in the diagram above. The "decrypt for the AI" moment happens entirely inside a device you hold, not a server we operate.

This is a strictly harder engineering problem than calling a cloud API — a 1B on-device model is a real constraint, and I've written about what that trade-off costs elsewhere. But it's the only version of "encrypted" that actually means what people assume it means when they read it on a privacy page.