How to report
Email security@longlifelist.com. Include what you found, where, how to reproduce it, and what you think the impact is. If you need to encrypt, say so in a first message with no details and we will send a key.
We publish this route at /.well-known/security.txt as well, so a scanner can find it.
What we commit to
- Acknowledge your report within one working day.
- Give you a triage decision and a severity within five working days.
- Keep you updated at least every two weeks until it is closed.
- Fix critical issues within seven days, high within 30, and tell you if we are going to miss that.
- Credit you publicly if you want it, and stay quiet about you if you do not.
- Never involve lawyers or law enforcement over a report made in good faith under this policy.
Safe harbour
If you follow this policy, we will treat your research as authorised, we will not pursue or support any action against you, and we will say so to anyone who asks. If a third party brings an action against you for work done within this policy, tell us and we will make that authorisation clear to them.
What we ask of you
- Use your own test account. Do not access, modify or retain anyone else’s data — and health data especially. If you stumble into someone’s records, stop, tell us, and delete what you have.
- Do not run denial-of-service tests, spam, social-engineer our staff, or attack physical premises.
- Do not use an automated scanner at a rate that degrades the service.
- Give us 90 days before publishing, or less by agreement. If we are dragging, say so and we will agree a date rather than stalling.
Scope
In scope
- The public site, the member app and the provider portal.
- The public API.
- Anything that crosses the boundary into health data: a path from an unauthenticated or wrongly-authorised context to a patient record is the highest-severity class of bug we have.
- Authentication, session handling, multi-factor bypass, and the consent and audit logging that sits in front of patient data.
Out of scope
- Findings from automated scanners with no demonstrated impact.
- Missing headers or cookie flags with no exploit path.
- Rate limiting on endpoints that have no sensitive effect.
- Social engineering, physical access, and anything involving a third party’s infrastructure rather than ours.
- Best-practice opinions about our TLS configuration or email authentication in the absence of an attack.
What we do at our end
- Health data is in a separate database with row-level access control, per-record encryption, and an append-only audit log that members can read.
- Multi-factor authentication is mandatory for any staff or clinician access to patient data, and there is no role that can browse it without a patient-created relationship.
- A build-time check fails the pipeline if any public page imports the health data client. That boundary is enforced by CI, not by review.
- Break-glass access exists for one role, is logged, and alerts a human every time it is used.
- We do not pay bounties yet. When we do, this page will say so and what the amounts are.
Questions about this notice go to the routes on the contact page, which lists the specific address for privacy, security, editorial and clinic matters rather than a single inbox that everything disappears into.