One standing job: this page is where we engage, on an ongoing basis, with the threats faced by people who use technologies like these: person-held archives, consumer health tools, AI agents with access to a life. A versioned register that grows, dated and credited. The development-status inventory that used to open this page moved on August 8, 2026 to the build log — the site's one status page, updated every time reality changes. The plain-words version is for everyone else.
The precise inventory (what is built and tested, what is designed on paper, what has not happened at all) lives on the build log, the site's single status page, so no copy of it can rot here. It carried this page's inventory until August 8, 2026; the archived versions keep that history. Two of its sentences still govern everything below: no independent security audit, penetration test, cryptographic review, or certification has occurred, and any deployment decision that treats KISOP as audited software is wrong, with the build log as the citation.
The three claim labels this register uses — ENFORCED · RECORDED · FUTURE — are defined once, on the build log, their anchor since August 8, 2026. The system's own security posture — the eleven named hard problems, the adversary table, what we refuse to market — lives on the main site's Security page and in For builders & security. This page holds the register below.
This register names what lands on people: anyone using a person-held archive, a consumer health app, or an AI agent with access to their life, ours included. Each entry: the threat, our current answer with its plain label, and the open question we want argued. The register is versioned; entries are added over time, dated, and credited to whoever brought them unless they prefer otherwise. Argue with any line of it. That is what the page is for.
The dominant business model of consumer health technology is the pile: data collected centrally, monetized laterally — sold, shared with brokers, breached, or subpoenaed at a scale no individual consented to. The person's risk exists because the pile exists.
Our answer: never build the pile. Archives live with their owners; the site itself stores nothing; the company cannot leak, sell, or surrender what it never receives.
Open question: metadata. Content never pooling doesn't stop sync timing, sizes, and query patterns from speaking. We claim no traffic-analysis resistance, and say so — is our accounting of what metadata still reveals complete? 📋
People inherit the consequences of institutions' breaches: identities cloned from leaked records, care obtained in a victim's name, institutional charts silently poisoned with someone else's episodes — which can hurt a person in a hospital bed years later.
Our answer: the person-held archive as the detection instrument — your right of access pulls institutional records to you, where a local comparison against your lived record can flag the claim you never made, the prescription you never filled. Recovery as a runbook: detect, preserve, report, correct, follow up.
Open question: the comparison discipline that makes detection reliable in a non-technical household. ⚠️
The realistic attacker of a personal archive is often family: physical access to devices, knowledge that defeats security questions, sometimes a legitimate consent grant — and a motive. Elder financial abuse is mostly committed by trusted people. The hard case is the son with the passcode. Consumer security is built for strangers.
Our answer so far: verb- and partition-scoped grants, unconditional logging with after-notice, and four research priorities: witnessed grants, cooling-off periods, duress signals, silent undo.
Open question: which of those patterns actually survives a controlling family member with device access — and which just move the coercion one screen earlier? This is the entry we most want adversarial minds on. ⚠️
Voice cloning and generative text have industrialized the grandparent scam: the caller now sounds exactly like the grandchild, the phishing letter reads exactly like the clinic. The people these technologies serve worst are the people scams target best.
Our answer so far: a known-people-only doctrine (unknown senders never reach the human), pairing ceremonies that require spoken human attestation, and community security sessions, because an hour of scam-spotting can protect a street. Trust in the channel itself is never enough.
Open question: ceremonies humans won't skip. A verification step people bypass under emotional pressure is theater; what does coercion-resistant urgency handling look like for a family that believes the grandchild is really calling? ⚠️
Personal AI agents summarize what arrives — PDFs, letters, portal downloads. A crafted document is therefore an instruction-injection vector into the software holding the keys to a person's context: exfiltrate the archive, alter the summary, manipulate the human through the tool they trust.
Our answer so far: content is treated as data. No instruction is ever taken from it. Agent tool-use is provenance- and consent-gated; agents propose, named humans decide anything that moves data or money.
Open question: this remains unsolved. Show us a document-borne attack that turns an archive agent against its owner despite the gate; our safe harbor exists for exactly that class of finding. ⚠️
Rich longitudinal personal data re-identifies; every practitioner knows it, and "your data is anonymized" remains the industry's favorite lullaby. People consent to sharing they don't understand because the word sounds like a guarantee.
Our answer: refuse the myth. Research sharing here leans on explicit consent scopes and contracts. No anonymization claim carries the weight. The person is told so, plainly, before anything moves.
Open question: the plain-words consent language that makes residual re-identification risk understood by a non-technical person. 📋
Forty-page policies nobody reads, pre-checked boxes, cancel-flows built like mazes, engagement mechanics tuned to farm attention from the anxious. The harm is quieter than a breach and more universal: people "agreeing" to things no informed person would choose.
Our answer: versioned plain-language promises with recorded agreement (the version you saw travels with your application); no engagement economy to serve — time-in-app is an anti-metric here; and a standing rule that marketing never edits a promise.
Open question: drift. The charter and versioned promises make backsliding visible and legally enforceable against us. Is that enough? Watch the record and tell us. ⚠️
Platforms die, get acquired, or quietly sunset — and people's records die with them, trapped in proprietary formats behind accounts nobody can access. And every person eventually dies; most technology pretends otherwise, leaving families locked out of what mattered at exactly the wrong moment.
Our answer: the archive is files — readable without our software and exportable by construction. It never becomes hostage to our continued existence. Custodianship across incapacity and death is designed as a first-class lifecycle.
Open question: the custodian handoff's failure modes — contested custody, estranged families, a custodian who is also entry #3's intimate adversary. ⚠️
The archive lives on real devices: shared phones, aging laptops, browsers with seventeen toolbars. Owner-device compromise defeats every guarantee above it, and the people this project most serves are the least likely to hold hardened hardware.
Our answer so far: graceful degradation; sane defaults; plain guidance; a paper layer as part of the system, with its own opsec, because paper survives malware.
Open question: what is the minimum hardware baseline — the device below which we should advise, "don't keep your archive here yet"? ⚠️
Data held by companies is one subpoena from being someone else's; people learned this the hard way when reproductive-health app data met changed laws. What a platform holds, a court can reach — and the person finds out last.
Our answer: minimize what exists to demand. There is no server-side trove of member records, and we cannot surrender what we never receive. For the limited information held by intake, we comply narrowly and notify the person unless forbidden. Records stored at home remain subject to the laws of that jurisdiction; local storage is not beyond legal reach.
Open question: with counsel, document jurisdiction by jurisdiction what person-held records can and cannot resist. 📋
"Ongoing" is a mechanism here:
| Claim | Standing | Where |
|---|---|---|
| The site makes no external requests and stores nothing server-side | ENFORCED | machine-checked before every release; verifiable in page source and network tab |
| The tools transmit nothing | ENFORCED | by construction — no transmit path exists in the code; verify it yourself |
| Consent gate: default-deny, scoped grants, every access logged | ENFORCED | test suite — current counts and dates on the build log; with the caveat that raw filesystem access bypasses the gate by design; the owner's device is the boundary |
| Untrusted transports require end-to-end sealing; violations refused | ENFORCED | message transport test suites — while the live age round-trip itself remains unproven in the build environment |
| No independent audit, pen test, or certification has occurred | RECORDED | the build log — the status fact everything else defers to |
| Good-faith security research safe harbor | RECORDED | Terms §15, in force (v1.1); formal coordinated-disclosure policy FUTURE, ships with the public repository |
| This threat register is maintained, versioned, and credited over time | RECORDED | this page's own commitment, v0.1 — hold us to it |
| Independent security review | FUTURE | will be announced dated, with scope and findings, when it happens |
Standing questions, in falsifiable form. The door is the main site's Write to us → security; the safe harbor is Terms §15.
Written July 13, 2026, as v0.1 of a living page. The threat register opens with ten entries chosen because they land on people — four carry a "designed against" label, six are open or stated stances, and the page says which is which. On August 8, 2026 the development-status inventory moved to the build log; this page's job is the register.
In review 📋: Carmen's review is pending. The register's verdicts are the project's own to date. No counsel and no auditor has been through yet, and the page exists precisely because of that.