Why your journal app can probably read your diary

What "private" actually means in app copy

When a journal app calls itself private, it almost always means one thing: other users of the app cannot see your entries. Your journal is not a public social feed. Nobody else on the platform can browse your writing.

That's a meaningful guarantee. But it's a much narrower one than most people assume when they hear the word "private."

What "private" typically does not mean: that the company running the app cannot access your entries. That employees can't see them. That automated systems aren't reading them to improve the service, train machine learning models, or flag policy violations. That your entries are stored in encrypted form the server cannot decode.

These omissions are rarely spelled out because they're commercially uncomfortable. Instead, privacy policies use language like "we take your privacy seriously", a phrase that has never, in the history of privacy policies, actually protected anyone's privacy.

How sync works, and why it matters for privacy

To sync your journal across devices, the app needs a server that both devices can reach. When you write an entry on your phone, it's sent to the server. When you open the app on your laptop, the server sends it down.

For this to work, the server needs to be able to read your entry. It has to decode the data to send it to your other devices, or to power features like full-text search. This is standard web architecture, there's nothing sinister about it.

The implication is that the company running that server has access to your entries. Not necessarily a human employee reading them by hand, but access at a technical level. Automated systems (for abuse detection, feature development, or model training) operate at the database layer, not the human layer.

The only technical way around this is end-to-end encryption (E2EE): your device encrypts the entry before sending it, using a key only your device has. The server stores ciphertext it can't decode. Only your devices can read it. Search and sync still work, they just work differently.

That Pew number suggests most people intuitively feel they've lost control of their data, but the mechanism is rarely understood. With journal apps specifically, it's not that data is being sold (most aren't doing that). The issue is subtler: data is accessible, and accessibility creates risk even when no one is actively abusing it.

What the privacy policies actually say

I've read the privacy policies for the major journal apps. Here's what I found:

Day One

Day One offers optional end-to-end encryption on its premium plans. When E2EE is enabled, Day One cannot read your entries, the math works. But E2EE is not on by default, it requires the premium plan, and most users never enable it. For users without E2EE enabled, Day One's policy does not explicitly rule out scanning entries for service improvement purposes.

Bear

Bear is a local-first app, notes live on your device by default, and iCloud sync (if used) goes through Apple's servers. Bear itself never has your notes on its servers. This is a meaningfully different architecture. The risk shifts to Apple, which does have strong privacy commitments, but it's still a server somewhere.

Notion

Notion's terms explicitly state they may use content to "improve Notion's products and services." This is standard SaaS language, and it's broad enough to include model training. Notion is a powerful tool, but it wasn't built for private journaling and its policies reflect that.

Standard Notes

Standard Notes uses mandatory end-to-end encryption for all users on all plans. The server stores only encrypted data it cannot read. This is the gold standard for technical privacy, at the cost of some features (server-side search requires a local search index instead).

Innerholm

Innerholm (which I built) does not use E2EE, server-side storage is required for sync and search. What Innerholm does instead is make an explicit, specific commitment: no content scanning for any purpose, no AI training on journal text, no behavioral profiling. Every optional data-collection feature requires affirmative consent before it's enabled. The server can read entries technically; the policy and contract say it won't. That's a policy guarantee, not a technical one. Understand the difference before relying on it.

What to look for when choosing a journal app

Ask these questions about any journal app you're considering:

• Is E2EE available, and is it on by default? If E2EE is optional, most users won't enable it. Default-on is the meaningful commitment.
• Does the policy explicitly rule out content scanning? Not "we take privacy seriously", specific language like "we do not scan, read, or analyze the content of your entries."
• Does the policy explicitly rule out AI training on your content? "Improve our services" language is broad enough to include model training. Look for specific exclusion language.
• What happens to your data when you delete your account? Purged within X days is better than "retained for legitimate business purposes."
• Who owns the content? You should. Most good journal apps say this clearly. If the policy is vague, that's a signal.
• Has the company ever had a data breach? Architecture and policy mean less if the data gets exfiltrated. Check their incident history.

No journal app is perfectly private unless you self-host and never sync, or use an app with mandatory E2EE. For most people, the practical question is: what's the company's commitment, and do you trust them to keep it?

The real risk isn't employees reading your diary

The thing people imagine, a Dropbox or Day One employee sitting at a desk reading your most embarrassing journal entries, almost certainly never happens. It would be career-ending, legally risky, and operationally pointless.

The risks that are real are less cinematic:

• Data breaches. A 2024 breach of any cloud journal app would expose every entry of every user to whoever found the database. The entries are often stored in plaintext or with server-side encryption (the server holds the key, in a breach, so does the attacker).
• Acquisition. If your journal app gets acquired, the new owner inherits the database. Privacy policies can be changed with 30 days' notice. Your 10 years of entries go to whoever bought the company.
• Legal requests. A subpoena for your journal is not science fiction. Your entries on a company's server are subject to legal process in ways that entries in E2EE storage are not.
• Model training. As AI development accelerates, the temptation to use user-generated content for training grows. Personal journal entries are high-quality human writing. The policies that permit "service improvement" were often written before LLMs existed.

None of this means you should go back to paper (though paper has real advantages, see our digital vs. paper comparison). It means you should read the policy, understand what you're trusting, and choose an app whose privacy architecture matches what you actually need.