Trust-boundary-aligned resource set: chronic pain tracking resources
If you came here from the failure-mode and testing path, this is the boundary
question underneath it.
Read first:
Service Worker Failure Modes in Offline-First PWAs
Rollback Patterns in Offline-First PWAs
Testing IndexedDB Schema Migrations in Offline-First PWAs
and
Offline Queue Replay and Idempotency in Offline-First PWAs
This piece names the privacy boundary that those failures are threatening.
If you want privacy-first, offline health tech to exist without surveillance funding it: sponsor the build → https://paintracker.ca/sponsor
Health apps are not just software.
They are vaults for private life.
Pain patterns. Sleep. Mood. Medication. Injury logs. Photos. Notes that
were never meant to become somebody else's asset.
Once you build for health, you are not just making a tool. You are
deciding what kind of trust a person has to place in you.
That is where the boundary lives.
Not in vague privacy marketing.
In the actual architecture.
What stays local.
What gets encrypted.
What gets exported.
What gets synced.
What gets observed.
What never, under any condition, becomes someone else's data exhaust.
That line is the whole system.
The device is the first boundary
A client side health app should start from one hard truth:
the user's device is the safe zone.
Not the server.
Not the analytics stack.
Not the marketing layer.
The device.
That means the most sensitive data should live locally by default, and
any movement away from the device should be deliberate, visible, and
owned by the user.
If the app is collecting pain logs, personal notes, symptom histories,
or recovery records, those records should not quietly drift into remote
systems because the product team wants insight.
Health data is not product telemetry.
It is human residue.
And it deserves a boundary.
Local first is not a slogan
A lot of apps say they care about privacy while still routing everything
through the cloud like that is just how things are supposed to work.
It is not.
Local first means the app can function without handing the user's body
back to a server every time they tap a button. It means storage,
editing, and basic retrieval happen on device. It means the app does not
need permission from some distant system just to open a record, update a
note, or view a timeline.
That matters even more in health contexts, because the user may not want
their most vulnerable material sitting in a networked place at all.
Maybe they are tracking pain for themselves.
Maybe they are logging symptoms before a medical appointment.
Maybe they are building a record for legal, workplace, or benefits
reasons.
Maybe they just need a private place to notice patterns without turning
their body into a dashboard for somebody else.
A good client side app respects that.
A bad one treats local storage like a temporary inconvenience before the
real business of extraction begins.
Export is a boundary, not a leak
This is where a lot of products get sloppy.
They say "your data belongs to you," then make it almost impossible to
get out in a usable form. Or they ship an export that is technically
complete and practically useless. Or they only export what is convenient
for the platform, not what the user actually needs.
That is not ownership.
That is theatre.
A real export boundary should answer a few blunt questions:
What can the user leave with?
Can they take it without asking the server for permission?
Is the export readable?
Is it complete enough to matter?
Does it preserve context, or does it strip the data into mush?
For health apps, export is not a nice extra. It is part of the trust
model.
Because people may need their data for a doctor, a therapist, a lawyer,
a disability claim, a second opinion, or just their own continuity of
care.
If the data cannot move cleanly, then the app does not really respect
the user.
It just rents them access to their own history.
Not every feature belongs inside the health boundary
This is where product pressure starts trying to win.
Some team always wants "insights."
Some SDK wants "improved engagement."
Some dashboard wants "anonymized analytics."
Some growth person wants to know which screens keep people around
longer.
And suddenly the app stops being a private health tool and starts
becoming a behavioral sensor.
That is where the line matters.
A health app should be very careful about what counts as acceptable
observation.
Useful analytics might tell you:
a screen is broken,
a flow is confusing,
a button is not being reached,
an error is happening,
performance is degrading.
That can be legitimate if it is collected minimally and with care.
Surveillance creep begins when the app starts capturing:
what the user typed,
how often they log pain,
what time they were awake,
which symptoms they entered,
which notes they deleted,
how long they hesitated before saving,
whether they come back when they are stressed.
That is not product intelligence.
That is intimate behavioral extraction.
And once you normalize that, the app stops being a safe container and
becomes a quiet observer.
Threat modeling should begin with the obvious adversaries
People often treat threat modeling like an abstract security exercise.
In health apps, it is painfully concrete.
Who should this app protect the user from?
A nosy cloud vendor.
A compromised device.
A data broker.
An abusive partner.
A workplace that should not have the data.
A family member with access to the phone.
A breach years later when the data is no longer needed but is still
sitting around waiting to hurt somebody.
That is the real threat landscape.
Not just hackers in hoodies.
The app should assume the user may need protection from the people and
systems already closest to them.
That changes the design.
It means lock screens matter.
It means local encryption matters.
It means app level privacy controls matter.
It means export has to be deliberate.
It means shared devices are not some edge case.
It means convenience is not automatically virtue.
Analytics should prove necessity, not entitlement
There is a huge difference between learning enough to improve the app
and collecting data because it is there.
That difference is ethics.
If analytics are needed, they should be narrowed to the minimum
necessary to answer a real question. Not a vague "understand user
behavior" goal. A real question.
Is this screen failing?
Is this feature crashing?
Is this flow too slow?
Is this export path broken?
That is the kind of thing you can justify.
But the second analytics start mapping the user's vulnerable patterns,
you are crossing a line.
In a health app, "anonymized" is not magic.
Pseudonymous is not the same as safe.
Aggregated is not the same as harmless.
And "we do not sell data" is not enough if you are still building a
system that observes more than it needs to.
The question is not whether you can technically collect it.
The question is whether you should.
The boundary has to be visible
Users should not have to reverse engineer your trust model.
They should be able to see it.
A good client side health app should make boundaries legible:
This stays on device.
This is encrypted locally.
This is optional to back up.
This only leaves when you choose export.
This telemetry is off by default.
This sync path is explicit.
This feature does not require an account.
That kind of clarity does two things.
It reduces fear.
And it forces discipline.
Because once the boundary is visible to the user, it becomes visible to
the developer too. You cannot hide sloppy assumptions behind vague
language anymore. You have to actually build the system you claimed to
build.
The safest feature is often the one that does less
This is the part people hate because it sounds less exciting than
platform growth.
But in health software, restraint is often the most trustworthy feature.
If the app can do its job without collecting more, it should.
If the app can work offline, it should.
If the app can store locally, it should.
If the app can export cleanly instead of syncing constantly, it should.
If the app can avoid identity systems, ad tech, and behavioral tracking,
it should.
That is not minimalism for style.
That is boundary discipline.
The more sensitive the data, the less appetite the system should have
for reaching beyond the device.
Trust is not a claim, it is a constraint
That is the whole point.
Anybody can write "privacy first" on a landing page.
The real question is whether the architecture behaves like it means it.
In a client side health app, trust is earned by refusing to overreach.
By keeping core data local.
By making export real.
By limiting analytics to genuine product necessity.
By treating every remote connection as a risk surface.
By assuming the user's health record is not the app's to mine.
When the boundary is clear, the user can breathe.
When it is vague, they have to guess what is happening to them behind
the scenes.
And health software should never make people guess what is happening to
their own body data.
That is the line.
What never leaves the device is not a technical detail.
It is the shape of the promise.
If you want the catalog route that connects this boundary back to the broader
series map, start here:
Start Here: PainTracker and the CrisisCore Build Log
Support this work
- Sponsor the project (primary): https://paintracker.ca/sponsor
- Star the repo (secondary): https://github.com/CrisisCore-Systems/pain-tracker
