Content note: discussion of mental health data breaches and exposed therapy records.
I didn’t arrive at this from a market gap or a white paper.
I got pulled into it through someone I care about, and then through the slow process of realizing how badly ordinary software language fits what plural tools can contain. “User data” is too small a phrase. “Content” is too small a phrase. Even “mental health data” can sound too clinical for something that might include private system notes, fronting history, internal messages, journals, safety plans, trauma associations, memory gaps, relationship maps, and parts of someone’s inner life they may never have said out loud.
I’m not going to pretend I understand everything about plural life. I don’t. I’m still learning, and I’ve learned enough to know there are arguments and histories and fault lines I should not treat casually. But I’ve also been close enough to see something that feels very obvious from the software side: a lot of app architecture was not built with this kind of data in mind.
The conversations people are already having
The recent conversations around SimplyPlural and Octocon have made that harder to ignore. People are not all asking for the same thing, which is part of the point.
Some want local-first storage because they don’t want private system data living on someone else’s server. Some want friend or support notifications because they need trusted people to know when something changes. Some want backups, exports, migration paths, and clearer answers about what happens if a tool changes direction, becomes unavailable, or disappears.
New alternatives are starting to appear, and I’m glad people are building, but the bigger question is still there:
What should an app be allowed to know, and what should stay with the person using it?
Why servers become the default
If you build software long enough, you start to understand why so many apps reach for servers first.
A server solves a pile of practical problems at once: accounts, sync, backups, notifications, billing, support, usage metrics, shared access, recovery, crash reports. Once the server’s in the middle, the app has somewhere for everything to meet. It gives developers one place to manage the moving parts, which is why it becomes the default so easily.
For plenty of apps, that tradeoff is reasonable. A playlist syncing through the cloud is useful. A shopping list that follows you between devices is useful. A saved game that survives a broken phone is useful. Most of us have accepted some cloud infrastructure because everyday software feels less fragile when it can follow us around.
But software defaults wander. Something that makes sense for a playlist can end up shaping an app that holds journals, crisis notes, fronting history, internal messages, or private records someone uses to understand their own life.
That’s a very different category of data.
For plural systems, DID systems, OSDD systems, and people using software to track memory, identity, dissociation, safety, or communication, the app may become part of how they hold onto reality. Sometimes it’s a place to write down what happened because memory is complicated. Sometimes it’s a way to leave context for someone else in the system. Sometimes it’s a place for notes that would be dangerous, embarrassing, destabilizing, or simply too private to put anywhere else.
When an app puts that kind of data on a server by default, “because that’s how apps work now” is not a serious answer.
Servers are not the enemy
I don’t think servers are suspicious by nature. Some features genuinely need them.
If someone wants a trusted friend to get a notification when they switch, some version of that event has to leave the device. If someone wants cloud backup, encrypted backup data has to live somewhere. If people building an app want to know whether the product is healthy, they may need basic telemetry, like whether users opened the app this week or which screens are getting used.
The problem is how easily “some data needs to leave” becomes “the server gets to be the home for everything.”
A product team may need to know whether the journal screen gets used. They don’t need to know what the journal says. They may need to know whether people make it through onboarding. They don’t need the names of headmates. They may need crash reports. They don’t need the contents of internal messages. They may need to know which features are alive. They don’t need to turn someone’s private switching history into a scoreboard.
There’s a strange temptation in software to measure whatever’s available and then act like the measurement itself proves value. A dashboard saying “a million switches logged” might sound impressive, but it doesn’t necessarily say whether the app helped anyone. It mostly says the company had access to count something intimate. For some patterns, the user needs the insight and the company doesn’t.
Growth makes this harder.
A small project can run on personal trust for a while. Maybe the original developer understands the community, understands the stakes, and would never dig through private records. In community-built tools, that kind of personal ethic can get a project started. It just can’t be the access model forever.
If the app works, the circle widens. Another developer helps debug sync. A support person needs to investigate account problems. A contractor gets temporary access. A data analyst wants retention reports. Logs get more detailed because a bug is hard to reproduce. Someone builds an admin panel because support is drowning. A vendor SDK gets added because it saves time. A permission that was supposed to be exceptional becomes routine because the queue is full and everyone’s tired.
A lot of privacy failures don’t start with someone trying to hurt users. They start with access spreading. They start with “just for now,” “only staff can see it,” “we need this for support,” “we’ll clean this up later,” or “this is industry standard.” If private records are readable by the company, every future version of the company becomes part of the user’s risk.
A backup service can be designed so the server stores encrypted material without holding the key. A notification service can pass along only the event data needed to deliver the notification. Product telemetry can focus on boring app-health questions instead of intimate behavior. The server can coordinate the parts of the app that actually need coordination without becoming the default home of someone’s inner world.
The data you never collect cannot be sold, leaked, or handed over
There’s also the question of pressure over time.
A company can promise not to sell sensitive data, promise not to browse private records, and promise to fight overbroad requests. Those promises are better than nothing, but they still depend on the company having the data in a form it can use.
If the server never receives a private journal, there’s no private journal for a future owner to monetize. If headmate names are never stored in readable form, there’s no readable list of headmates to leak, analyze, or hand over. If backups are encrypted before they leave the device and the company never has the key, the company can be pressured for the backup file, but not for the contents inside it.
A service may still have account records, payment records, support messages, logs, telemetry, notification events, or encrypted backup files, and those deserve their own minimization rules. The private records the company never had aren’t sitting in a database waiting for a policy change, a subpoena, a breach, a future acquisition, or a desperate monetization strategy.
I don’t think plural communities need a lecture about why exposure is dangerous. People already know. A lot of the real fear is more specific: being misunderstood, being disbelieved, being treated as unstable, being outed, losing control of context, or having something private flattened into a category someone else thinks they understand.
That’s why the usual privacy language can feel so weak here. “We care about your data” is not enough. “We use encryption” is not enough if nobody explains who has the keys. “We don’t sell your information” is not enough if the app collects more than it needs and leaves future owners with a tempting pile of sensitive material.
Mental health tech has already shown us the failure modes
Mental health tech has already given us enough examples to stop treating this as theoretical.
The Vastaamo breach in Finland is the one I keep coming back to. A hacker accessed psychotherapy records for about 33,000 clients. A Finnish court found him guilty of aggravated data breach, nearly 21,000 aggravated blackmail attempts, and more than 9,200 aggravated disseminations of information infringing private life. About 24,000 people filed criminal complaints. Prosecutors said he demanded ransom from the therapy company first, then began publishing patient information and sending ransom demands directly to patients. (AP)
The data in that case wasn’t abstract. Therapy records became leverage against people who had sought help. Even after the attacker was sentenced, the exposure itself couldn’t be undone. The harm was not just technical or financial; it reached into people’s private lives at one of their most vulnerable points.
Other failures are less cinematic, which almost makes them more useful to study. BetterHelp wasn’t a story about a hacker breaking into a database. The FTC said BetterHelp shared sensitive health data with advertising platforms despite privacy promises, including personal mental health information and user emails, and BetterHelp agreed to a $7.8 million settlement without admitting wrongdoing. The user thinks they’re answering questions to get help. The business sees data that can improve ad targeting, attribution, and growth. Those incentives can coexist with very sincere-sounding privacy language. (FTC)
Then there’s the more ordinary infrastructure nightmare. WIRED reported in 2024 that an unsecured Confidant Health database contained more than 120,000 files and 1.7 million activity logs from the virtual medical provider, including detailed medical histories, therapy session audio and video, and other highly personal information. WIRED reported that some files were accessible without password protection. The company shut down access after being notified and said it found no evidence of malicious access. Even so, the design lesson doesn’t depend on proving a villain was waiting on the other side. Sometimes the weak point is just a database that was easier to expose than anyone wants to imagine. (WIRED)
The research on mental health apps doesn’t make these feel like rare exceptions. One empirical study of 27 top-ranked mental health apps found unnecessary permissions, insecure cryptography implementations, leaks of personal data and credentials in logs and web requests, third-party data sharing, and profiling risks. (arXiv) A 2026 preprint analyzing 25 therapy and life-coaching apps found transparency gaps too: every app studied embedded at least one tracker SDK that its privacy policy did not name, 68% failed to disclose at least half of the trackers detected, and 48% disclosed some third-party AI processing of sensitive user material. (arXiv)
The language around these incidents can make everything sound cleaner than it is. “Data exposure.” “Privacy incident.” “Third-party sharing.” “Analytics.” “Misconfiguration.” Those terms are useful for reports and regulators, but they don’t fully capture what it means for a therapy recording, a crisis journal entry, a private system note, or a fronting record to end up somewhere the user never expected.
Local-first does not mean local-only
For software in this category, I’d rather see a stricter habit from the start: keep what can stay local, send what actually has to be sent, encrypt backups before they leave, and don’t collect intimate data for product metrics when ordinary product metrics will do. Don’t make the server the default home of someone’s private life because centralized architecture is familiar, easier to support, or easier to monetize later.
Local-first thinking is useful here, as long as it doesn’t become an absolutist position. The useful distinction is “local-first,” not “local-only”: local storage stays central, while the cloud helps with the parts it’s actually needed for, like coordination, backup, or collaboration. That approach fits this category of app better than treating the cloud as the obvious source of truth for everything.
A notification server can deliver a switch notification without storing the whole private history behind it. A backup server can hold encrypted data without holding the key. Usage telemetry can show which screens are confusing without reading what users put on those screens. A service can coordinate the parts of an app that genuinely need to leave the user’s custody without quietly absorbing everything else.
There are risks on the local side too. Phones get stolen. Devices break. Unsafe people can access unlocked devices. Passwords get lost. Honest encryption can mean honest consequences if recovery keys are gone. Local-first doesn’t make anyone perfectly safe, and pretending otherwise would just replace one false comfort with another.
The questions should come first
Still, the questions have to come earlier than they usually do.
What does the app actually need to know? What can stay with the user? What needs to leave only because the user asked for a feature that requires it? What can leave only in encrypted form? What can be counted without becoming creepy? What would a future support person, contractor, analyst, or developer be able to see by accident? What would still be protected if the company grew faster than expected, got sold, changed direction, or made a mistake?
Those questions belong before the admin dashboard, before the analytics plan, before the backup flow, before the AI roadmap, before the comforting privacy copy. A privacy promise is easier to keep when the system is designed so there’s less sensitive material available to misuse in the first place.
People are allowed to want convenience. They’re allowed to want sync, backup, recovery, friend notifications, cross-device access, and support features that require infrastructure. Nobody should be shamed for using servers, and local-only tools don’t meet every need.
What I want challenged is the assumption that server custody is too ordinary to question.
For apps that hold someone’s private inner world, “where does the data live?” shouldn’t be a footnote. It should be one of the first design decisions anyone has to defend.
