Privacy protocol

Strong privacy encourages more reporting. We don’t want to know who you are and take significant steps to avoid doing that. This page details how.

Looking for the legal stuff instead? Read our privacy statement and terms.

We want your questions and feedback. Contact us.

1. What we promise

We hold nothing that identifies a report. The report form asks for no account, name, email, phone, cookie, key, receipt, or location; none is stored with a report; and your network address is never written down. There is nothing to link a report to a person, so nothing to leak, subpoena, or sell. (The contact page is separate: see §3.)
We ask only for rounded answers. Every question on the report form is a fixed choice — a dose band, a duration bucket, a kind of source — so the record cannot carry the precision that matching it to a person would need. There is nowhere to type on the report form.
We store nothing until you say so. The form holds your answers only in the page you are looking at. The server writes one row, at the moment you press Agree and submit, and never updates it.
We publish only aggregates, under rules fixed in advance. Every table that will ever be published, and the threshold for each, is written down and will be witnessed in a public log before the first report is accepted. Small groups are suppressed. Individual reports are never shown to anyone — not to researchers, not to a buyer, not in a wind-down.
We will never try to work out who you are, and we will never let anyone else use our data to.
The count is checkable. Every accepted report is committed to a public log anyone can verify (release spec).
Nobody pays us and we pay nobody.

What a careful design still cannot do is set out, without softening, in What we cannot promise at the foot of this page.

2. What a report contains

Fifteen multiple-choice answers: thirteen about one compound — which compound, route, dose bands, frequency, kind of source, duration, whether it was tested, the main goal and what happened, side effects from a fixed list with when they started and whether they stopped, whether you are still taking it — and an optional age band and sex or gender. The server adds the day it arrived (not the time) and a random secret value used only for the public append-only log described in §7. That is the entire record. The complete field list and every allowed value is the schema.

3. What is not collected, and what is not logged

What we never ask for. No account, no email, no name, no phone, no date of birth, no cookie, no key, no vendor or brand, no location of any granularity — not your country, not your state. No free text: there is nowhere to type on the report form.

The contact page is the one place on the site where you can type. A message sent there is stored on our server, forwarded to the operator’s mailbox, and deleted within 30 days. It is kept entirely separate from reports, and it is the reason we ask you never to describe a report you submitted in a message.

What leaves your browser. The form never asks for the precise thing, only the rounded one: a dose range instead of the milligram, a duration bucket instead of a start date, the kind of source instead of the vendor. Nothing is sent until you press a button, and nothing is stored until you press the last one.

Your network address. Over the public web address, the server reads your IP address once, to limit how many submissions one connection can make in an hour: it hashes the address with a random value that changes every hour, keeps the count in memory, and never writes any of it to disk. After an hour it cannot be recovered even by us. Over the Tor onion service there is no address at any layer. Nothing else about your connection is read.

Your browser. Every web server receives headers such as the browser’s name and language. Ours never reads or stores them, and there is no JavaScript on the site, so there is no way to fingerprint a device — no canvas, fonts, screen, or hardware signals are ever examined.

What this site loads. Nothing from anyone but us — no analytics, no fonts, no CDN, no error reporting, no CAPTCHA, no scripts. Your browser’s network panel should show exactly one host. A check that fails our build enforces it.

Two ways in: the public web address and a Tor mirror. The same site, the same code, the same rules, at two addresses: https://privateanecdata.org and, in Tor Browser, http://unxzqdwshn2ftzivh3bg7e63mvn3ccsxs2d5oplxd7z3djs3qvppjhyd.onion. On the public address, our hosting provider necessarily sees your network address (§3 above), and your own network provider can see that you visited a site about peptides. Through the Tor mirror neither can: no one on our side receives an address, and Tor Browser also blocks the fingerprinting that ordinary browsers allow. We run the mirror for the same reason major news organisations run theirs — so that reading and contributing do not require telling anyone you did. It is listed openly here and in Subprocessors, and nothing exists on one address that does not exist on the other.

Location. We do not ask for it, look it up, or log it. Today the server performs no geographic lookup of any kind. If we ever enable a regional block on the public web address (to decline connections from regions we do not serve), it would work by checking the region of an address in memory to decide whether to serve the page, keeping nothing — and this paragraph would change to say so before it was switched on. The onion service cannot be region-blocked.

Logs. The web server’s access log is off. The application writes nothing per request. The only logs that exist are process logs — startup, certificate renewal, errors — kept in memory and expiring within a day. Two honest caveats. A failed TLS handshake is logged by the HTTP server with the address that failed — a connection that never became a request. And when the web server cannot reach the application (for example during a restart), it logs the error; our configuration deletes the address, port, headers and path from that entry before it is written. Both logs are volatile and expire within a day.

The hosting provider. To deliver a page, the provider’s network necessarily carries your packets and therefore your IP address. We do not control what its own network layer keeps; the provider, its region, and its retention policy are named in Subprocessors, which lists every party involved — there are three.

Backups are encrypted copies of the store and contain exactly what §2 describes. Retention is stated in Legal process.

4. How a report is kept from pointing at you

Coarse by construction. The form never asks for the exact dose, date, or place; it offers bands, buckets, and kinds. What is never asked cannot be recorded.
Nothing you type is stored. Every control is a fixed choice, and the server re-checks each answer against the list it would have offered before writing anything. The one text box on the page is invisible, exists to catch automated submitters, and discards the submission if filled.
One goal, not many. A combination of several goals was the single most identifying thing a report could carry, so the form asks for the main one.
No location, ever. Not country, not state.
Small groups are never shown. Any published cell under 5 reports is hidden, and one neighbouring cell is hidden with it so the small one cannot be recovered by subtraction; both are labelled “not shown”, never with a number. A compound with fewer than 10 reports is not shown under its own name. Age and sex are reported only for all contributors together and are never crossed with anything.
Disclosure grows with numbers. What is published about a compound depends on how many people have reported it — a count first, distributions later, outcomes-by-goal later still — so the number of published figures never gets close to the number of reports behind them.
We measure it and say so. How distinctive a single report is on several combinations of fields is computed on synthetic data in the schema and re-computed on the real store at every release, shown in the Uniqueness of the store section at the end of each release page (table T15 in the spec). We do not claim a rounded report can never be distinctive; see what we can and cannot promise.

5. The commitment

We will not attempt to identify any person from any report, and we will not allow anyone else to. We do not search the store for a particular person’s report for any reason, including at that person’s request. Individual reports are never displayed, shared with researchers, licensed, sold, or transferred, de-identified or otherwise, to anyone, including a buyer or trustee in a sale or wind-down; if the project ends, the store is destroyed under the shutdown protocol. The one thing we cannot refuse is valid legal process, which could compel production of the store; Legal process says what that would and would not obtain — nothing in the store identifies anyone. The terms §4 make this a promise to every contributor that binds any successor.

It follows that we cannot find, correct, or delete your report after you submit it: we hold nothing that says which report is yours, and no way to check that a request about a report comes from the person who made it. The form says so before you submit. If that is not acceptable, do not submit.

6. What is published — the release specification

Only aggregate statistics. Individual reports are never displayed, shared, licensed, or given to researchers, in any form. The tables that can be published, and the number of reports each one needs before it appears, are fixed in the release specification — a document that will be witnessed in a public transparency log before the first report is accepted, and that can be changed only by a versioned amendment announced a full release period in advance. Our code, schema, and rounding rules are public with it. In brief:

Tiers. Under 10 reports, a compound is counted only inside its class. At 10: its count, route, and source. At 50: every one-way distribution — dose bands, frequency, duration, purity testing, effects, status, what people took it for. At 100: outcome by goal. At 200: percentages with intervals, and effect timing. At 1,000: the one cross-compound view, stratified and never pooled.
Floors. Cells under 5 are hidden, with complementary suppression across every published total. A cross-tabulation stratum needs 20 reports. Percentages need 100 in the denominator.
Never. No table crossing age or sex with anything; no three-field cross; no mean or average of any scale; no ranking or “most effective”; no comparison statistic between compounds; no per-vendor or per-region breakdown (no such fields exist); no row, partial row, or synthetic row; no live count; no statistic on request.
Cadence. Cumulative snapshots, monthly for the first year and quarterly after, each reviewed by a person, signed, and witnessed. A release is never deleted or changed. A compound’s tables are recomputed only once at least 5 reports have changed since they were last computed (20 once it has cross-tabulated tables), so that comparing two releases never reveals a smaller group than the tables show.

7. Counting honestly

Our numbers are real. This section shows how anyone can check.

Every accepted report is committed, in the same transaction that stores it, to an append-only log: a hash of the report with a secret per-report value, so the log reveals nothing about any report and no one — not even the person who submitted it — can find a particular entry. With every release we publish the whole list of log entries, the root that summarises them, and the previous release’s root. Anyone can recompute the root, confirm the count equals the number of entries, and confirm the previous list is an exact prefix of this one — that nothing was removed, reordered, or backdated between releases.

The release’s manifest, which carries the hash of every published file, is signed and its hash is submitted to two independent public logs we do not control — Sigstore Rekor and OpenTimestamps (anchored in Bitcoin) — so a release cannot be quietly replaced later. Reports excluded from the tables for quality reasons are never deleted: they stay in the log and are listed, by position and reason, in every release. Each release page ends with an Integrity log section: how many reports the coordinated-submission detector (public code: tools/detect.py) flagged, for what reason, and a note on any pattern it found.

What this does not prove: that any report is true, that reports came from different people, or that a submission was never dropped before it entered the log. The full procedure, what each check proves, and what none of them can, is in How we count reports.

8. Changes

This protocol, the privacy statement, the terms, the schema, and the release specification are versioned. Each version’s hash is submitted to a public transparency log when it takes effect, recorded in the witness record (spec/WITNESS.md in the repository), so a change cannot be quiet or backdated. A change that reduces a promise does not apply to reports received before it — and since reports cannot be separated by contributor, in practice it cannot apply to the store at all.

What we cannot promise

The limits of this design, stated without softening. Read before you contribute.

Most sites that collect health information tell you what they do to protect it. This page tells you what we cannot do, so you can decide with that in front of you.

Your report might point at you on its own

We never ask who you are. But a report about an uncommon compound, taken at an unusual dose, by someone in a less common age group, is a small enough description that it could match only a few people — and if you have described the same thing publicly, somewhere you can be identified, then someone who obtained our database and also read your post could shortlist your report.

We do three things about this. The form only asks for rounded answers — a range, a bucket, a kind — so the database holds a dose band rather than your dose and a duration bucket rather than your start date. We never hold your location, at any granularity. And we never publish individual reports — only aggregate statistics, under rules fixed before we collected anything.

What we cannot do is make a detailed report about a rare drug indistinguishable from other reports when there are few other reports. We publish an analysis quantifying this. If the compound you use is rare and you have discussed your use publicly under a name that can be traced to you, you should weigh that before submitting.

We cannot delete your report after you submit it

There is no account, no email, no key, and no identifier of any kind attached to your report. That is the point: it means nobody — not us, not someone who takes our database, not a court that orders us to hand it over — can find your report among the others.

The consequence is that we cannot find it either. If you write to us and describe your report, we will not search for it: doing that would be exactly the re-identification we designed against, and we could not confirm the report was yours in any case.

Before you submit, you will see everything you are about to send, and you can go back and change it. Nothing is stored until you confirm. After you confirm, submission is final. If that is not acceptable to you, please do not submit.

This is the ordinary condition of survey research that collects no identifiers, and consent forms for such studies have said so for decades. We are saying it here so it is not a surprise.

We cannot promise our hosting provider has never seen your IP address

When your browser loads this site, the company that hosts our server receives your IP address in order to deliver the page. That is how the internet works. We do not log it, we do not store it, and we have configured every layer we control not to. We publish who our host is, where the server is, and what their own retention policy says.

If that is not enough, use our Tor onion address. Over Tor there is no IP address for anyone on our side to receive.

We cannot prove the server runs the code we published

Our source code is public. You can read what it does. But you cannot verify from your browser that the server you are talking to is running that code and not something else. No website can offer that proof, and we are not going to pretend otherwise.

What we can make checkable is the output. Every set of statistics we publish is committed to a public log we do not control, along with a fingerprint of our submission database. You can verify that a number we published today is the number we published, and that our count of reports is the count we committed to. That is a narrower guarantee than “trust the server,” and it is the one we can actually keep.

We cannot stop someone from submitting false reports

Anyone can submit. We do not ask for identity, so we cannot prove that two reports come from two people, or that any report is truthful. A vendor with a commercial interest in a compound could submit many reports to move a statistic.

We make this detectable rather than impossible: a bot trap catches automated submitters, an in-memory rate limit slows any one connection, a coordinated-submission detector (public code: tools/detect.py) flags self-contradicting reports and unusual bursts, and what it flags is excluded from the tables and listed in every release’s Integrity log section. We publish only counts and distributions — never an average — so a burst of extreme reports cannot move a headline number. There is no CAPTCHA and no proof-of-work: both would need a third party or a script in your browser, and this site runs neither. We do not claim the data is clean, and you should not read any number here as if it were.

We cannot resist a lawful order to produce what we hold

If we are served with valid legal process, we will comply with it. What we hold is a set of rounded reports with no field that identifies anyone, and we hold nothing else that could be used to try. We will challenge overbroad requests where we can, and we describe our handling of legal process in a separate document. But you should assume that anything we hold could one day be produced, and submit only what you would be comfortable having produced under those conditions.

We cannot tell you whether anything here works or is safe

Every report on this site is something a person chose to tell us, about themselves, after the fact, with no verification. People who had bad experiences may be more or less likely to report than people who had good ones. People expect things to work and report accordingly. The compounds themselves vary in what is actually in the vial.

The Federal Trade Commission’s own guidance states that anecdotal evidence, including surveys of consumer experiences, is never sufficient to substantiate claims about the effects of a health product. We agree. Nothing here is evidence that any compound is effective or safe. What it is, is a structured record of what people say happened to them, with the number of people shown next to every figure, published under rules we cannot quietly change.

We cannot promise to exist forever

Projects like this usually end. When this one does, the shutdown protocol we publish specifies that the submission database is destroyed. Because no row identifies anyone, there is nothing in it that would be worth transferring, and we have committed in our terms never to transfer it.

If you have read this far and still want to contribute, thank you. The rest of the site explains what we do with what you send.

Appendix A: threat model

The technical appendix — what the system enforces, by threat.

Version 1.0. This document is written as a specification: it states what the system enforces, not what it worries about. Every mitigation listed here is either implemented in code, enforced in CI, or stated as a published operating commitment. Where a risk cannot be removed, that is stated in What we can and cannot promise.

What this system is

A public website that accepts one-time, structured, identifier-free reports about peptide use, from any source, and publishes aggregate statistics computed from those reports under a release specification fixed before any data was collected.

Assets

In priority order:

The contributor’s identity — never collected, so never held.
The association between a report and a person — the only thing that could convert a report about drug use into a fact about a specific human. The design’s purpose is to make this association unavailable to us and to anyone who obtains what we hold.
The report’s content — coarsened structured fields about compound, source, dose, duration, outcomes and adverse effects. Sensitive in aggregate for the population; identifying only in combination with (2).
The integrity of the published aggregates — the product. Compromised by fabricated submissions, silent editing, or selective publication.
The contributor’s trust — damaged by any gap between what we say and what the deployed system does.

Adversaries

We design against, in decreasing order of concern:

A motivated individual with public information about a target — a partner, employer, competitor, or anti-doping investigator who knows a specific person uses these compounds and wants to find their report. Has: public posts by the target, the published aggregates, the published source code, and the ability to submit crafted reports. Does not have: our database.
Legal process — a subpoena, preservation demand, or warrant served on us or our host. Has: everything we hold. This adversary is the reason the design holds nothing that resolves to a person.
A compromised host or database — an attacker who obtains the raw store. Same capability as legal process, without the notice.
A vendor or other party with a commercial interest in the published numbers — submits fabricated reports to move a statistic. Has: the ability to submit at scale through any path we offer.
Ourselves — a future operator, an acquirer, a bankruptcy trustee, or a version of the current operator under pressure. The design limits what any operator can do, not just what this one intends to.

We explicitly do not design against a nation-state adversary with the ability to compromise endpoints, and we do not claim protection against an adversary who has compromised the contributor’s own device.

What the server receives

One HTTP POST per screen of the form, each carrying the answers so far in a hidden field so the server can render the next screen — and nothing is kept from any of them. Only the final POST, at the moment the contributor confirms, is written, and it contains only fields drawn from the frozen controlled vocabularies in SCHEMA.md, re-validated against them immediately before the write. Specifically:

Field	Form
Compound	One of a frozen list; rare entries are published only rolled into a mechanism class
Primary goal	One of that compound’s predefined goal list
Source channel	One of eight channel types (including “don’t know” and “other”); never a vendor, pharmacy, or brand name
Starting and current dose	A band, never a number
Frequency, duration	Buckets
Purity testing	One of five: did not test / tested, matched label / tested, did not match / tested, unsure how to read the result / don’t know
Outcome for the stated goal	No change / slight / moderate / large
Adverse effects	Multi-select from a fixed list, each with an onset bucket and whether it resolved on stopping
Status	Still taking, finished a planned course, or stopped early — and if stopped, the main reason from a fixed list
Age band, sex or gender	Optional; six bands and five options

Not received, by construction: name, email, phone, account, cookie, contribution key, IP address (see Network), free text of any kind, exact dose, exact dates, start date or quarter, vendor or pharmacy name, price, location at any granularity, device identifiers, or any field not listed in the schema.

Coarsening is a property of the questions, not a transformation: the form never asks for the exact value, so the server never receives one to round. Every control is a fixed choice — a dose band, a duration bucket, a kind of source. The form runs no script at all, so there is no client-side step to audit; the choices on the page are the only values that can be sent.

What the server stores

Exactly the fields above, plus a day-granularity received date assigned on write, a per-row secret salt, and the row’s Merkle leaf in an append-only log table. The leaf is a hash of the salt and the row, so anyone holding the store can recompute which log position belongs to which row; the salt only prevents that matching from the published leaf list. Nothing else. There is no session table, no draft table, no request log that references submissions, and no column that could hold an identifier.

Nothing is stored until the contributor confirms. Multi-step form state is carried in the request and rendered back to the contributor for review. Abandoned forms leave no record.

Every stored row is appended, with a per-row secret salt, to a Merkle log whose root is published periodically (see Integrity). Rows are never updated. Rows excluded from analysis for quality reasons are recorded in a separate, separately-published exclusion list with reason codes; they are not deleted from the log.

What is published

Only the outputs enumerated in RELEASE_SPEC.md, which is fixed and to be witnessed in a public transparency log before the first report is accepted. Each release is a set of static files generated by a pipeline whose code is public, reviewed by a person before publication, and committed with a signed tag.

The specification lists every table that will ever be published and the rule for every cell. No table is added in response to a request. No interactive query interface exists. No row is ever published, licensed, shared with a researcher, or otherwise disclosed, in any form, de-identified or otherwise.

Enforced mitigations, by threat

Direct identification

Threat: a name, email, or contact detail arrives with a report.

Enforced: no such field exists in the schema, and nothing typed on the report form is ever stored. Every control on the report form is a fixed choice, with one exception: a visually hidden text input that only an automated submitter would fill, whose value is used solely to reject the submission and is never written anywhere. Before the final write the server re-validates every field of the report against the vocabulary the form would have offered, and rejects anything else — a tampered request cannot store a value the form does not list. A check that runs in CI (tools/check_form.py) renders every screen and fails if any control is not a schema field, a routing field, or that one bot trap. The contact page is the only other form on the site; it is a separate store, holds free text by design, is never joined to reports, and is pruned at 30 days.

Linkage via public posts

Threat: a contributor posts publicly (“35M, started BPC-157 at 250 mcg in March for a tendon”) and an adversary matches that post to a stored row.

Enforced: the row does not contain the values a post contains. It contains a dose band rather than 250 mcg, a duration bucket rather than a start date, a source type rather than a vendor. No location is held at any granularity. Only one goal is held. The adversary must first obtain the raw store (see Legal process and Compromise), then guess which bucket each of the target’s values fell in.

Stated limit: on the coarsened row, a determined adversary who holds the raw store and knows a target’s compound, age band, sex, goal, and dose band will find a small number of candidate rows at any dataset size below tens of thousands. We publish the uniqueness analysis that quantifies this. This is why the raw store is never published and why we hold nothing else.

Timing correlation

Threat: a submission timestamp is matched to a public post timestamp.

Enforced: no timestamp finer than a day is written to any durable store. A report is committed at the moment of confirmation, so the log preserves the exact order of commitment, and anyone who holds the store can recover that order for every row (the salt is on the row); what they cannot recover is a time finer than the day the received date gives. The published leaf list is in log order, but a leaf cannot be matched to a report without that report’s secret salt, which is never published, so nothing public places any report in the sequence. Row IDs are random. No real-time feed exists; counts are published only with releases.

Network metadata

Threat: the contributor’s IP address, TLS fingerprint, or user agent is recorded alongside the submission.

Enforced: access logging is disabled at every layer we control — web server, reverse proxy, TLS termination, and application. There is no CDN, WAF, or third-party edge in front of the origin. TLS session-ticket keys are held in memory only and rotated automatically by the server; nothing about a session is written to disk. Process logs (startup, certificate renewal, errors) are kept in memory and expire within a day; an address can reach them in two ways: a failed TLS handshake is logged with the address that failed (a connection that never became a request), and a handler error such as a 502 during a restart is logged with the request’s address, headers and path deleted by configuration. Referrer-Policy: same-origin is set (so no referrer ever leaves the origin) and query parameters are rejected on the intake route. A Tor onion service provides a second path with no IP for us to receive. The hosting provider necessarily receives the IP to deliver the page; we publish the provider’s name, region, and its own retention policy in SUBPROCESSORS.md.

Stated limit: we cannot promise our host has never seen an IP. We can promise we do not log it, do not store it, and have configured every layer under our control not to.

Third-party disclosure

Threat: a script, font, image, or error report sends a request to a third party from a page carrying health information.

Enforced: zero external origins. The Content-Security-Policy permits no external source of any kind. CI fails the build if any resource references an external origin. No analytics, no CAPTCHA service, no error-reporting SDK, no CDN-hosted library, no hosted fonts. This applies to every page on the origin, not only the form.

Draft and partial-submission leakage

Threat: the server records what a contributor typed and then changed, or a form they abandoned.

Enforced: no server-side draft store. No per-field validation endpoint. No per-keystroke or per-blur requests. Nothing is persisted until the contributor confirms on the review screen.

Database compromise and legal process

Threat: an attacker or a court obtains everything we hold.

Enforced: what we hold is the coarsened rows described above and nothing else. There is no identifier column, no key table, no log that references a submission. The honest description of what a subpoena would produce is: a set of rows with no field that resolves to a person, and no auxiliary data with which to attempt it. Our handling of legal process is stated in LEGAL-PROCESS.md.

Stated limit: see Linkage via public posts. A party who obtains the store and independently holds a target’s public statements has a bounded but nonzero ability to shortlist rows.

Small-cell disclosure and differencing

Threat: a published statistic reveals information about a small group, or the difference between two releases reveals a single report.

Enforced: the release specification fixes a minimum cell size below which no value is published and a display threshold below which no proportion is shown. Rare compounds are published only rolled into their mechanism class. No table is cross-tabulated on a rare compound. Releases are cumulative snapshots; the exclusion of quality-flagged rows is applied identically to every release so that no differencing between releases isolates a row. The total number of distinct tables that will ever be published is bounded by the specification.

Stated limit: a suppression threshold is not a privacy guarantee. An adversary who can submit crafted reports can push a target’s cell over any threshold. This is why the number of tables is bounded, why no interactive querying exists, and why the specification cannot be extended on request.

Fabricated submissions

Threat: one party submits many reports to move a published number.

Enforced: a honeypot field that automated submitters fill and people cannot see; in-memory rate limiting keyed on a salted hash of the client address (for IPv6, its /64 prefix), with the salt rotated hourly and never persisted (connections over the onion service have no address and share one generous ceiling instead). There is no CAPTCHA and no proof-of-work: both would need either a third party or client-side script, and the site runs neither. Published statistics are counts and distributions; no mean, average, or sum of any scale is ever published, so a burst of extreme reports cannot move a headline number. A coordinated-submission detector runs on the raw store; what it flags is excluded from the tables, listed by log position, and summarised in the Integrity log section of each release page. This is the weakest control in the design and is described as such in What we can and cannot promise.

Stated limit: an identifier-free system cannot prove submissions come from distinct people. We make fabrication costly and detectable, and we publish what we detect. We do not claim the data is clean.

Operator misuse and succession

Threat: a future operator, acquirer, or trustee uses the data in ways contributors did not agree to.

Enforced: the data that could be misused does not exist in reconstructable form — there is no row-level dataset that identifies anyone, no key table, and no contact list. The terms contain an irrevocable commitment never to sell, license, or transfer row-level data. The shutdown protocol in SHUTDOWN.md specifies destruction. This is a stronger promise than an organizational form: the 23andMe database was transferred in bankruptcy to a nonprofit controlled by its own founder.

Silent revision of published numbers

Threat: a published statistic is changed after the fact, or a release is withdrawn.

Enforced: every release is a signed git tag whose hash is submitted to a public transparency log we do not control. The release specification’s hash is submitted before the first report is accepted. The Merkle root of the submission log is published with each release. Releases are never deleted.

What this design does not do

It does not offer edit or deletion after confirmation. There is no identifier with which to locate a report, and building one would defeat the purpose. See What we can and cannot promise.
It does not verify that any report is truthful.
It does not provide differential privacy on published releases in version 1. Suppression and bounded table counts are the release controls. This may change; if it does, it will be stated in a versioned release specification, never described as a property of the site or the store.
It does not prove that the deployed server runs the published code. The code is public so that what it would do can be examined; the transparency log makes published outputs checkable. We do not claim more than that.

Change control

This document is versioned. A change to any enforced mitigation requires a version increment, a changelog entry, and — if the change weakens a protection — a notice on the site before it takes effect. The schema and release specification are frozen at launch and changed only on a published schedule.

Appendix B: shutdown protocol

Kill criterion, destruction protocol, and the commitment that the store is never transferred.

Projects like this usually end. This page says what happens when this one does, so that a contributor knows the answer before submitting rather than after.

Kill criterion

Written before launch, so it is cheap to mean it:

If, in the 30 days following a launch endorsed by at least one community moderator, fewer than 50 reports are received, the project will stop accepting submissions and enter shutdown.

Other triggers: the operator becomes unable or unwilling to maintain the site; a legal or regulatory change makes continued operation impossible or unsafe for contributors; the operator stops, or the entity, once one exists, is dissolved.

What happens on shutdown

In this order:

Submissions close. The form is removed. The site displays a notice with the date.
A final release is published, following the release specification, including the final Merkle root and Integrity log section. It is witnessed like every other release.
The submission store is destroyed. The SQLite file is securely deleted; every backup is deleted; the encryption keys for the backups are destroyed. This is done within 30 days of the closure notice. The date of destruction is published.
The public artifacts remain. The source code, the schema, the release specification, the threat model, and every published release stay online for as long as the domain and repository are maintained, and are mirrored to at least one archive we do not control.
The domain is not sold. It either continues to serve the archived site or lapses.

What is never done

The submission store is never transferred to any other party, for any consideration, under any circumstance — not on sale, not on merger, not on dissolution, not in bankruptcy. This is an irrevocable commitment in the site’s terms.
No “successor” project inherits the rows. A successor may inherit the code, the schema, and the methodology, and must collect its own data under its own commitments.
No row-level export is ever made, including to a researcher, an archive, or a regulator, as part of shutdown.

The reason this must be promised is the opposite of “the store is worthless.” The store holds the coarsened rows themselves — every report, unsuppressed, with age and sex alongside compound and goal — and the threat model states plainly that a party holding those rows has a bounded but nonzero ability to shortlist rows against a person’s own public statements. The releases hold only suppressed aggregates. The store is therefore the one artifact worth refusing to transfer, and it is destroyed rather than passed on. No identifier is in it; that is what makes the promise keepable, not what makes it unnecessary.

The 23andMe database was sold in bankruptcy to a nonprofit controlled by its own founder. An organizational form is not a data covenant. This protocol is written so that the covenant does not depend on the form.

The domain

The domain is never sold or transferred. It is kept registered, locked and auto-renewing for at least five years after any shutdown, so that no one can inherit the name and put a different site behind it; after that it is allowed to lapse.

Succession

If the operator is incapacitated, the following happens automatically:

The site continues to serve; no new submissions are affected because none are stored until confirm. The only scheduled process that reads the store is the encrypted backup (deploy/backup.sh), which writes nothing to it.
A designated person holds instructions and credentials sufficient to execute steps 1–5 above, and nothing more. They cannot read the store in any way the operator could not.

Last updated: 22 September 2026.