Yardland — home

Method

How this list is made

Yardland makes two kinds of claim about each address: where it came from and whether it answered. This page explains how both are established, what the measurements can and cannot prove, and what is deliberately excluded.

1. Provenance: where the address came from

The address itself is not evidence of anything. A v3 onion address is derived from the service's public key, so a real address and a phishing clone are equally random-looking strings. Only the source of the address tells you which you have.

Tier 1 Advertised by the organisation

Their clearnet site serves the address to Tor Browser, via an Onion-Location HTTP header or an equivalent <meta> tag. Three conditions are required for a header to be valid: the value is an http or https URL whose host ends in .onion; the advertising page is served over HTTPS; and the advertising page is not itself an onion service.

This is a live assertion, re-served on every visit — which is why it is the strongest tier and the least prone to rot.

Tier 1 Published on their own signed list

A few projects publish and sign an address list themselves rather than advertising a single onion. Debian is the reference example: onion.debian.org is Debian's own verifier for roughly a hundred Debian onion mirrors. These entries point at the verifier instead of inventing a single address for the project.

Tier 2 Published on their own domain, unadvertised

First-party, but second-best. Documentation pages and announcement posts are not updated when a service is retired, so a tier 2 address can be years stale while the page that carries it looks perfectly current. Every tier 2 entry is therefore liveness-tested before it is published — and if it fails, it stays in the record marked unreachable rather than being quietly deleted.

Tier 3 Third-party listings

Not accepted. Forums, aggregators, other directories, security-vendor blog posts. A copy of a copy is how a phishing address acquires the appearance of authority, and it is the single most common failure mode in existing onion link collections.

2. Liveness: whether the service answered

Every address is fetched through a Tor client and the result recorded with a timestamp and an attempt count.

Checks run one at a time, and that is deliberate. Tor builds a fresh rendezvous circuit for every onion service: fetch the descriptor, build the circuit, introduce, rendezvous. Running many checks concurrently starves the circuit builder, and every starved request fails with an ordinary timeout that looks exactly like a dead service. An early parallel run of this project declared twelve live services dead. Serial checking resolved twenty of twenty. Parallel probing here is not a speed trade-off; it is a correctness bug.

The two failure modes are reported differently. A timeout means Tor was slow and Yardland gave up — that is not evidence about the service, so it is retried. A host unreachable error is Tor reporting that it could not retrieve the service descriptor at all, which means nothing is answering at that address. Only the second is published as a finding.

Unreachable entries are kept and shown. Removing them would hide the most useful thing this site knows. A published address that no longer answers is a defect in somebody's documentation, and it is fixable — but only if it is visible.

3. What is excluded, and why

Illegal services

Marketplaces, vendors, and anything dealing in illegal goods or content. Out of scope, permanently, with no exceptions and no grey area.

Forums and imageboards

Mixed legal and illegal content with no accountable publisher. Not listable even when most of the material is lawful.

Unattributable services

If no identifiable organisation will put its name to the address, there is nothing to verify and it does not belong here. This is the rule that does most of the real work, and it is the one that has not moved.

Gated services are admitted, and labelled

A service that needs an account, an invitation or a credential is listed — but only when the identifiable organisation that operates it publishes the address. It carries an Account needed label, and that label means something precise: the address, and the fact that the service answers, were verified. The content behind the gate was not.

An earlier version of these rules excluded gated services outright. That conflated two different questions — what can be verified about the content behind a login, and whether an address is genuine — and it removed legitimate services that real organisations publish themselves, such as institutional mail, tip lines and account portals, while doing nothing extra to deter anything unlawful. An illegal service is excluded for being illegal, not for being gated.

Revised 2026-10-11. The change is recorded in the manifest as data, not only as prose on this page, and it applies to every entry — including the operator's own, which were the first to carry the new label.

4. Who operates this

Yardland is built and operated by Schoedel Design, which designs and runs onion services for organisations that need them: censorship-resistant publishing, anonymous tip intake, Tor-only mail and messaging, and onion address verification.

Which makes this page an advertisement, and it is worth saying so plainly rather than leaving you to infer it. The constraint is that it can only work in one direction: this directory is worth something exactly to the extent that being listed means something. So inclusion is not for sale, no entry can be added by request, and the operator's own services are put through the identical admission test and given no preferential placement — they sort by the same rule as every other entry.

The same criteria, applied to ourselves

Schoedel Design currently lists none of its own onion services, because it no longer operates any: all five were taken down in October 2026. They were removed from the directory on the same terms they were admitted on — they stopped answering, so they left, which is what happens to every other entry that stops answering. The retirement record is kept in raw/operator_publication.json so that 'no exemption for the operator' remains a checkable statement rather than a claim.

Every one of those decisions is recorded in the manifest's source data, so the criteria can be checked rather than taken on trust — see verifying what you read.

5. What Yardland does to you

Nothing. One document, no JavaScript, no cookies, no analytics, and no requests to any third party — styles, icons and type are all embedded in the page, because on a Tor circuit every additional request costs a round trip and creates another correlation opportunity. The page is readable with scripting disabled, which is Tor Browser's Safest mode. Addresses on the clearnet version are shown as selectable text rather than links, so an accidental click cannot trigger a DNS lookup outside Tor.

Yardland also does not link out to onion addresses from clearnet, and does not publish anything it has not itself checked.

6. Corrections

If you run one of these services and your entry is wrong — a dead address, a retired service, a stale tag on your own site — that is exactly the kind of report this project exists to act on. If an entry names an address you do not control, say so and it is removed.

Inclusion is not for sale and no entry can be added by request alone: an address is listed when the organisation publishes it and it can be confirmed. Corrections, removals and challenges are always in scope.

7. Verifying what you read

The manifest is signed. A signature proves the data is intact and came from the holder of the signing key. It proves nothing at all unless you already know that key's fingerprint from somewhere other than this server.

Signing key fingerprint

0D50 66E0 7245 80CB C201 B6EB FE77 4F31 7846 8E05

Ed25519 · created 2026-09-22 · expires 2031-09-21 · full fingerprint 0D5066E0724580CBC201B6EBFE774F3178468E05

What is signed

  • manifest.yaml.asc — detached signature over the manifest itself
  • SHA256SUMS.asc — detached signature over checksums covering the manifest and both builds of these pages, so you can confirm the HTML you were served matches the signed release

How to check

# fetch the manifest, its signature, the checksums and the public key
gpg --import yardland-signing-key.asc

gpg --verify manifest.yaml.asc manifest.yaml
# expect: Good signature from "Yardland Release Signing ..."
# expect the key ID FE774F3178468E05, and the fingerprint above

sha256sum --check SHA256SUMS
# expect: every line OK

Downloading the key from here is not enough, and neither is downloading it over Tor. If you fetch the data, the key and the signature all from this server, you have only learned that this server is internally consistent. Anyone who can serve you this page could serve a matching key and signature too.

So get the fingerprint from somewhere else. The same fingerprint is published over ordinary HTTPS at yardland.net, and in the source repository. Two independent channels that agree is a far stronger claim than one that is merely self-consistent — which is the whole reason the address is printed above in plain text, spaced for reading, instead of being left to whatever TLS certificate happens to be in play.

Onion services have no certificate authority. There is nothing to anchor trust except a value you obtained separately, and that is exactly what a fingerprint is for.

Signed files

Current measurement

46Entries
41Responding
2Unreachable
9Categories

Manifest v1, generated 11 October 2026. 51 individual Tor connection attempts are recorded for these entries.