The Hitchhiker's Guide to Online Anonymity: a handbook that is also a build pipeline

Written for people with a reason to be careful

The project describes itself as a full guide for online anonymity and OpSec, and the README sets out the purpose in plain terms: providing an introduction to various online tracking techniques, online ID verification techniques, and detailed guidance to creating and maintaining, in the documentation's own emphasis, truly anonymous online identities.

The audience sentence is the part that distinguishes this from the many anonymity write-ups that exist. The guide is written with hope for activists, journalists, scientists, lawyers, whistle-blowers, and good people being oppressed, censored and harassed anywhere. That is not a rhetorical flourish, it is a specification, because the advice changes depending on whether losing your identity is a mistake or a catastrophe.

There is a disclaimer about affiliation that is worth reading closely, because anonymity projects are often associated with the Anonymous collective, and the guide is explicit that it has no affiliation with it. The site and projects are free in the sense of freedom, and not affiliated with any donor or project discussed in the text, and are not sponsored or endorsed by any commercial or governmental entity. The guide is licensed under Creative Commons Attribution-ShareAlike 4.0 International, which means you are free to use it for pretty much any purpose, including commercially, as long as you attribute it. There are no ads and no affiliate links.

That combination, a serious threat model in the target audience and a permissive licence that forbids monetisation through advertising, is the shape of the project. The primary language on the project record is Python, which is a detail about the build rather than about the content, since the guide itself is Markdown.

Two ways to read it, one of them offline

The README gives a short section on ways to read or export the guide, and it is more than a list of links.

In your browser, the Hitchhiker's Guide is the hosted site at anonymousplanet.net, and the documentation adds that after a local build you can also open site/guide/index.html directly. That second path matters, because a guide about anonymity that you can only read online is a guide you cannot consult safely.

The local HTML preview is the documented way to work with the source. From the repository root, with Python 3 and MkDocs Material installed, you run:

pip install mkdocs-material
mkdocs serve

Then you open the URL printed in the terminal, for example http://127.0.0.1:8000.

So the full set of ways to read the guide is: the hosted site, a locally built copy served by mkdocs serve, and the built HTML opened directly from disk. The export/ directory in the repository listing suggests there is a further path beyond those, and the site is called the Hitchhiker's Guide while the project and package are named thgtoa, which is the traditional abbreviation for The Hitchhiker's Guide to the Galaxy and, in this context, the name of the guide itself.

The requirements file pins two things and nothing else, mkdocs at 1.6.1 and mkdocs-material with the imaging extra at 9.7.2. A two-line requirements file for a documentation site is a deliberate choice, and it has a practical consequence: anyone who has MkDocs Material in the same environment can build the guide without resolving a large dependency tree, which matters for the audience the guide is written for.

The repository carries the apparatus of a maintained publication

The top level listing is small and every entry has a job.

There is a docs directory holding the source content, an export directory, a scripts directory, and a pgp directory. There is mkdocs.yml as the site configuration and a requirements.txt with the two pinned dependencies. There is a CNAME file, which is the mechanism for pointing a custom domain at GitHub Pages, matching the anonymousplanet.net hostname. And there is a set of automation files: a .pre-commit-config.yaml, a .markdownlint.yaml, a .cz.toml for conventional commit messages, a CLA.md for the contributor licence agreement, and a .github directory whose workflow is named 03-release.yml, with the build badge pointing at it.

The pgp directory is the one that deserves comment, because it is not a documentation concern. A guide that tells people how to verify identities and communicate securely needs the keys, and publishing them in the repository means they are versioned, reviewable and tied to the releases rather than being scattered across web pages that can be changed silently.

The release workflow and the badge in the README point at the same 03-release.yml file, and the tags are named with a v prefix and a pre-release suffix, with the recent ones being v1.2.6-pre1 on 2026-07-13, v1.2.5 on 2026-06-28 and v1.2.4 on 2026-06-02.

The three numbers in that list tell a small story. There was a v1.2.4, then a v1.2.5, then a v1.2.6 pre-release, so the project is at a pre-1.2.6 state and using pre-releases to ship changes that are not yet deemed stable. The last push to the repository was on 2026-07-13, so the content moves in bursts rather than continuously.

Donations that are logged in public

The funding model is described in one sentence that is more specific than most project funding notes.

If you would like to make a donation to help this project, you can do so from the donations page, where you will also find the project goals. All the donations will be strictly used within the context of this project. And all donations and spendings are logged on the donations page.

That last clause is the interesting one, and it is a stronger commitment than a promise that money goes to the project. Logging both the incoming donations and the outgoing spending means anyone can check the claim, which for a project whose subject is trust in institutions is the point.

The Open Collective badge in the README shows the funding runs through Open Collective, which gives the project a public ledger of its own, so the donation log and the platform log are two independent records of the same thing.

The other part of the non-affiliation statement, that the site and projects are not affiliated with any donor or project discussed in the text, is doing quiet work. The guide discusses specific anonymity tools, and a reader has to be able to assume that recommending a tool is not a favour to a sponsor. A donation page that shows every donor, combined with an explicit statement of non-affiliation with the tools discussed, is a coherent way to make that assumption safe.

It also means the project is not a commercial product with a free tier. There is no paid edition, no enterprise feature and no vendor to pressure, and the licence permits commercial reuse of the content, so the value of the guide is entirely in whether it is accurate and current.

What a written guide can and cannot do

There is a real limitation here, and it is worth stating plainly for anyone building on this project rather than reading it once.

A guide is a snapshot. The techniques it describes, the tools it recommends and the verification procedures it walks through all have a shelf life, and the shelf life of each chapter is different. A chapter on how a browser leaks information ages when the browser changes. A chapter on a specific identity verification service ages when that service changes. Nothing in the repository listing indicates a per-chapter review date, so a reader cannot tell from the text how old a given piece of advice is, and the tags on the project record are thematic, activism, anonymity, anonymization, opsec, privacy, security, tails, tor and whonix, rather than a version per section.

The second limitation is scope. The README describes an introduction to tracking techniques, ID verification techniques, and guidance on creating and maintaining anonymous identities. That is an orientation, not an operational manual, and a reader who needs to set up a specific hardened environment for a specific threat will need the primary documentation of the tools as well.

The third is that a guide is advice rather than evidence. Where the tool that recommends a particular practice is well maintained and auditable, its recommendations are worth reading. Where it is not, the recommendation is an opinion with a licence attached, and the difference matters for a reader making decisions about their own safety.

None of this is a criticism of the project, which does what it says and is candid about its independence. It is the reason to read the version history and the release dates before treating any specific chapter as current advice, and the reason the CC BY-SA licence is practically important. A reader who knows when a chapter was last verified can act on it accordingly, and a reader who wants to update a chapter for their own context can do so and share the result, provided the result carries the same licence.

Editorial conclusion

The Hitchhiker's Guide to Online Anonymity fits a reader who has a concrete threat model and wants a structured starting point rather than a list of products, and it fits a trainer who needs a document they can hand out, translate and adapt. It is the wrong tool for someone who wants a technical answer about a specific tool or protocol, and it is the wrong tool if you need guidance that is current to the day, because a written guide ages at a different rate from the software it describes. Before relying on it, read the version history to see how recently the content was reviewed, check the pgp/ directory in the repository to see which keys the project publishes, and read the non-affiliation and donation statements so you understand who maintains it and who funds it.

Frequently asked questions

Official sources

1. Anon-Planet/thgtoa on GitHub
2. License: CC-BY-SA-4.0
3. Project website
4. README
5. Releases