Start with the claimed identity
Write down what the service claims to be: an established newspaper, a software project, a nonprofit, a discussion forum, or an independent publication. Verification requires comparing that claim with evidence controlled by the claimed operator.
Use an evidence hierarchy
1. First-party clearnet publication
The strongest ordinary evidence is an address published on the organization’s established HTTPS website. The page should fit the organization’s normal domain, design, and editorial structure—not a newly created lookalike.
2. Authenticated operator announcement
A signed release, established code repository, official social account, or other authenticated channel can support the address. Document why the channel is considered under the operator’s control.
3. Specialist directory with published methods
A specialist directory can be useful when it explains how entries are checked, records review dates, and removes entries when evidence changes. SecureDrop’s public directory is an example of a directory that distinguishes active, under-review, and maintenance states.
4. Independent corroboration
Multiple credible sources that reproduce the exact same address add confidence, especially when they link back to the operator’s own announcement. Ten copied lists that cite no origin are not ten independent sources.
5. Operational observation
A service that responds can be marked operationally observed. This confirms only that something answered at that address. It does not prove who operated it or whether its claims are true.
Compare the address exactly
Current onion hostnames are long. Use copy-and-compare tools that operate locally, or compare the text in a fixed-width font. Check the entire hostname, not only the first and last characters.
Do not rely on:
- a shortened screenshot;
- a QR code with no visible text;
- a link whose displayed text differs from its destination;
- a search snippet;
- a browser bookmark imported from another person;
- a message claiming that the old address “redirects” through an unknown gateway.
Record the evidence
For each directory entry, keep:
| Field | What to record |
|---|---|
| Claimed operator | Organization or project name |
| Onion hostname | Exact 56-character hostname |
| First-party source | The clearnet or authenticated publication |
| Source date | When the source was published or observed |
| First documented | When your directory first recorded it |
| Last reviewed | When a human reviewer rechecked the evidence |
| Operational status | Observed, offline, changed, or not checked |
| Reviewer note | What was proved and what remains uncertain |
Use precise labels
“Verified” is too broad unless it is defined. This publication uses:
- Owner-confirmed: the operator publishes the address through an established first-party channel.
- Cross-checked: several credible sources agree and the evidence is documented.
- Operationally observed: the address responded, but ownership was not established.
- Unverified: available evidence is insufficient.
- Offline or changed: a previously documented address no longer responds or has been replaced.
- Historical: retained for research and clearly separated from current listings.
Reverify after changes
An address should be reviewed when:
- the operator announces a replacement;
- the clearnet source changes;
- the service is unavailable for an extended period;
- a clone warning appears;
- the organization changes ownership;
- a certificate, design, or identity claim changes unexpectedly;
- a reader submits credible contrary evidence.
Verification is a maintained record, not a one-time badge.
What verification does not mean
Even owner confirmation does not establish that every page, user, or later action is safe. It establishes the relationship between an operator and an address. Separate editorial and safety decisions still determine whether the service belongs in a public-interest directory.