Can an App Read My Journal?

Most journaling apps can read your entries. If an app stores your text on a server without end-to-end encryption, then the company — and potentially anyone who gains access to their systems — can read what you wrote. Daylogue gives you a real option most journaling apps don't: you can turn on client-side encryption in Settings so your entries are encrypted on your device with AES-256-GCM before they are transmitted, with keys stored only on your devices. When that setting is on, Daylogue cannot read your raw journal entries, even if compelled. It is off by default — if keeping entries unreadable to Daylogue itself matters to you, turn it on before you start writing.

What most journaling apps actually do with your data

The default in the journaling app industry is server-side storage. You type an entry, it gets sent to a server over HTTPS (encrypted in transit), and then it sits in a database. Some apps encrypt the database at rest using keys that the company controls. Others store entries as plain text. In either case, the company has the technical ability to read your entries. They may promise not to, but the capability exists.

This matters because databases get breached. Employees sometimes have overly broad access. Legal requests can compel companies to turn over data they have the ability to decrypt. If the company can read your entries, those entries are only as private as the company is trustworthy and secure — and that is a high bar for content as personal as a journal.

The difference between “encrypted” and “end-to-end encrypted”

Many apps advertise that your data is encrypted. This is technically true but misleading. There are two very different kinds of encryption:

• Server-side encryption: The company encrypts your data on their servers using keys they control. They can decrypt it at any time. This protects against external attackers but not against the company itself.
• End-to-end encryption: Your data is encrypted on your device before it leaves. The encryption keys exist only on your devices. The company never has the ability to read your data, even if they wanted to.

How end-to-end encryption works in Daylogue — when you turn it on

This protection is opt-in, not automatic. By default, your entries are stored in readable form on Daylogue's servers — protected by TLS encryption in transit and strict access controls, but readable by Daylogue in principle, the same as most journaling apps store data. If you turn on client-side encryption in Settings > Privacy & Security, Daylogue generates encryption keys on your device. These keys never leave your devices. From that point forward, when you write an entry, it is encrypted locally using AES-256-GCM — the same standard used by financial institutions and government agencies — before being transmitted to Daylogue servers for syncing across your devices. On the server, that entry is stored as an unreadable ciphertext blob, and no one at Daylogue has the keys to read it.

When you open Daylogue on another device, the encrypted data syncs and your local keys decrypt it. The readable version only ever exists on your devices — but only for entries written after you turned encryption on. Entries written before that point, and any entry written while the setting is off, remain in readable form on our servers.

The AI processing tradeoff

Even with client-side encryption turned on, there is one moment when your entry exists in readable form outside your device: during AI processing. When Daylogue generates your daily narrative, detects patterns, or runs a conversational check-in, your entry is briefly decrypted and sent to the AI provider (AWS Bedrock) over an encrypted connection. The AI processes it in memory and does not store, log, or train on your content — but the AI-generated summary that comes back is stored server-side in readable form (not end-to-end encrypted), because it powers features like your daily narrative and pattern insights. That means AI-generated summaries could be produced if Daylogue were legally compelled, even for users who have encryption turned on for their raw entries.

This is a genuine tradeoff. Full privacy purists might prefer no AI processing at all. Daylogue is transparent about this window because honesty about limitations is more trustworthy than false claims of absolute privacy. You can read more about how Daylogue handles AI safety and the technical details of AI processing.

What “client-side encryption” means in practice

Client-side encryption means your data is encrypted on your device before it reaches our servers, and the service provider has no technical ability to access it. In Daylogue, this is an optional setting you turn on in Settings > Privacy & Security. For entries written while it's on:

• Daylogue servers store only encrypted ciphertext for that entry
• Encryption keys exist only on your devices
• A server breach exposes only unreadable encrypted data for that entry
• If legally compelled, Daylogue could only produce ciphertext for that entry — not a readable version

None of this applies automatically. If you haven't turned client-side encryption on, your entries are stored in readable form on our servers, and could be produced in readable form if Daylogue were legally compelled — the same as any journaling app without end-to-end encryption. And regardless of this setting, AI-generated summaries and pattern insights are never end-to-end encrypted, because they need to be readable server-side to power your daily narrative and insights.

Red flags to watch for in journaling app privacy policies

If you are evaluating a journaling app, read the privacy policy carefully. These phrases should raise concerns:

• “We may use your data to improve our services” — this often means AI training
• “We share anonymized data with partners” — anonymized emotional data is often re-identifiable
• “Your data is encrypted at rest” without mentioning who holds the keys — this is likely server-side encryption
• No mention of encryption at all — your data is likely stored as plain text

Daylogue publishes its privacy architecture in plain language, not just in legal documents. If you are concerned about how apps use psychological pressure, that is worth reading too.