Why offline-first matters for sensitive data.
Most apps that ask for sensitive data store it on their servers. against. does the opposite. Here is why that matters specifically for recovery.
Most apps that ask for sensitive data store it on their servers. against. does the opposite. Your data lives only on your device. Here is why that matters specifically for recovery work.
What “cloud-first” usually means
When an app stores your data on its servers, it’s making a bet: that its infrastructure is more reliable, more available, and more trustworthy than your phone. For many kinds of data, that bet is reasonable. For recovery data (notes about relapses, trigger patterns, journal entries), the calculus is different.
Cloud-first means several things happen automatically, often without you deciding:
- Your data crosses a network every time you interact with it.
- It lives on a server owned by a company, subject to that company’s security practices.
- It is potentially visible to that company’s employees, contractors, and any third parties they share with.
- It can be subpoenaed by a government or obtained by an attacker who compromises the server.
None of those things are necessarily outcomes. They are possibilities that exist as long as the data sits somewhere you don’t control. For routine data (a to-do list, a reading progress tracker) those possibilities are acceptable. For notes about your relationship with pornography, they may not be.
What goes wrong when sensitive data is centralized
The failure modes for centralized sensitive data are predictable and well-documented. Breaches happen. Companies are acquired. Business models shift toward advertising, which introduces third-party tracking SDKs. Legal regimes change. A startup with good intentions today may not exist in the same form in two years.
There is also a subtler problem. When data lives on a server, the people who built the app have the technical ability to read it, even if their privacy policy says they don’t. Policies are promises. Technical architecture is constraint. A server that stores your journal entries can be read by someone with the right access. An on-device database that never leaves your phone cannot be read remotely, regardless of what anyone promises.
For recovery work specifically, the stakes are higher than for most categories of personal data. This information touches relationships, legal situations, employment, and self-perception. The downside risk of exposure (even accidental, even by a well-meaning company) is real.
How offline-first changes the threat model
Offline-first means that the data never leaves your device in readable form. In against., it doesn’t leave your device at all. There’s no sync, no backup to a cloud service, no account that holds your records.
This changes the threat model materially:
Server breach: Not applicable. There is no server holding your data.
Company acquisition or pivot: Not applicable. The data isn’t in the company’s hands.
Subpoena or legal request: We have nothing to hand over. We can confirm you have an account, but we don’t store account data either, because there are no accounts.
Employee access: No employee can read your notes, because we don’t receive them.
Third-party trackers: against. doesn’t include advertising SDKs. There’s no economic reason to, since there’s no data to sell.
The remaining threat model is local: someone with physical access to your unlocked phone, or a sophisticated attacker who extracts the device’s storage and breaks the encryption. Those are realistic threats for high-value targets. For most people’s recovery journals, they are not the primary concern.
What you give up by going offline-first
Offline-first is not a free upgrade. It comes with real tradeoffs.
No cross-device sync. Your data lives on one device. If you switch phones, you need to export and re-import manually. If you lose your phone without a backup, you lose your history.
No account recovery. There’s no “forgot password” flow, because there’s no account. Your encryption key is stored in your phone’s secure hardware. If you lose that, you lose access to the encrypted data.
No web access. You can’t log in from a browser. The app only runs on the phone where the data lives.
These are not bugs. They are the direct consequence of the same design that protects your data. The app documents this tradeoff clearly. It’s a choice worth making for this category of data, but it is a choice, and it belongs to you.
There’s a broader point here about what “secure” means in practice. Security isn’t a single dial you turn up to maximum. Every security property involves tradeoffs with usability, convenience, and functionality. Offline-first maximizes one cluster of properties (resistance to remote access, resistance to corporate data handling, resistance to subpoenas) while accepting limits in another cluster. The question isn’t whether offline-first is secure. It’s whether the specific tradeoffs match the specific risks you’re managing.
For recovery tracking, the case is strong. The data is personal and sensitive. The people most likely to be harmed by exposure are the people generating the data, not third parties. The behaviors being tracked don’t require real-time coordination with other users. The cloud’s advantages (access from multiple devices, sharing, collaboration) are not features you need here. The risks it introduces are real. Offline-first is the right fit.
Further reading
See also: Privacy & Security.