Most people have never opened Tor Browser. Most people who have, opened it once, loaded a news article about it, and closed it again. So when a practitioner says they run a site on the dark web, the instinct is to raise an eyebrow. That reaction is fair. It is also, I think, worth pushing past.
I run a small security research site as a Tor hidden service. It publishes under a separate pseudonym and aggregates feeds from roughly eighteen open-source threat intelligence and privacy research sources. It is not commercial. It carries no tracking. It exists because I wanted to understand, from the inside, how adversaries and defenders actually use the same infrastructure — and because the only honest way to understand that was to build something and maintain it over time.
This post is about why, what is running under it, and what surprised me. If you came here expecting edgy stories, you will be disappointed. The lesson of the project is that the interesting parts of this space are the boring parts.
The conventional wisdom, and the reality
The conventional wisdom is that the dark web is where crime happens. That is partially correct. Criminal markets and forums exist there, and they are well documented by researchers and law enforcement. But the same network also hosts:
- Mirrors of major newsrooms for readers in censored regions.
- SecureDrop instances for journalists and sources.
- Privacy-respecting search engines and email providers.
- Documentation and learning material for privacy engineering.
- Research sites by academics who study the space honestly.
Tor is a network, not a neighborhood. It has rough corners and it has libraries. Treating the whole thing as a threat is as lazy as treating the whole clearnet as a threat because phishing happens there.
What I actually wanted to learn
I have spent most of my career operating enterprise infrastructure. You learn a lot about attackers from incident response, from threat feeds, and from vendor reports. What you do not learn is what it feels like to build and maintain the kind of minimalist, adversary-aware infrastructure that privacy-conscious operators actually run. I wanted that feel in my hands.
The specific questions I wanted to answer:
- How hard is operational security, really, when you try to do it properly?
- What design choices does the Tor environment force that the clearnet lets you ignore?
- How does identity separation behave as a lived discipline, not a slide?
- What does a defensible, static-first publishing stack look like in 2026?
The stack, in short
The setup is intentionally boring. Boring is a security property.
- Whonix Gateway + Workstation on a dedicated hypervisor. All traffic from the workstation is forced through the gateway. The workstation never sees the clearnet directly.
- Tor hidden service (v3 onion) running on the gateway. Keys are kept off the workstation.
- A small Python static site generator. Markdown in, HTML out. No database, no server-side rendering, no authentication surface.
- Feed aggregation from roughly eighteen public threat intelligence and privacy sources, normalized and deduplicated, rebuilt on a schedule.
- A hardened content policy: no JavaScript, no external fonts, no third-party assets, no cookies, no analytics.
The whole thing is closer in spirit to a 2005 blog than a 2025 SaaS application. That is the point.
What surprised me
Discipline beats tools
The hardest part of running this was not the technology. It was remembering, every single session, to follow the same procedures in the same order. The network-level protections are strong; the human-level protections are only as strong as habits. Most real-world deanonymizations come from someone, once, doing the ordinary convenient thing.
Identity separation is its own engineering problem
Keeping my professional identity and the research identity genuinely separate takes more than different browsers. It takes different writing styles, different schedules, different tools, different machines, and a willingness to never reach across the boundary even once. I underestimated this at the start. It is the single most demanding part of the work.
I decided early that I would document both identities publicly rather than pretend they were unrelated. The professional work (this site) is mine. The research work under the pseudonym "TheMacwan" is also mine. What I will not do is blend them operationally. The logical link is public; the technical link does not exist.
Latency changes design
A fully loaded page over Tor can take five to ten seconds. That single fact disciplines every design decision. You stop using webfonts. You stop loading a framework to render a button. You write small HTML, small CSS, and almost no JavaScript. The result is faster, simpler, and more accessible than most commercial sites I've worked on. Users who have never touched Tor would benefit from the same constraints.
Static sites are vastly more secure
There is no SQL injection vulnerability in a site that has no SQL. There is no authentication bypass in a site that has no authentication. There is no server-side request forgery in a site that has no server-side anything. Moving from dynamic to static is not a convenience choice; it removes entire categories of vulnerability from your backlog.
Tor Browser's defaults kill most web assumptions
Script is off by default on the highest security setting. WebGL is off. Fonts are constrained. Many canvas APIs are neutered. If you design for the median web today, your site will simply fail to render for the users you are trying to reach. Designing for the strict baseline is a healthy corrective. It reminded me how much of the modern web is unnecessary weight.
On publishing without naming people
I work a day job. That job is unrelated to this research. I do not publish anything that references my employer, my colleagues, clients, or any incident I've worked on professionally. The research site draws only from public threat intelligence. That boundary is not optional and not subtle. It is the whole deal.
If you are considering similar work as a practitioner, I would argue the same discipline applies. Your employer is not a source. Your employer's systems are not a lab. The dark web is full of people who confused those lines and paid for it.
Why publish any of this at all
Partly because I think the field is underserved by people willing to speak plainly about this kind of work. The popular coverage alternates between breathless and dismissive, and practitioners who actually operate in the space often stay quiet. I think that is a loss.
Partly because the skills transfer. Everything the project taught me about minimal attack surface, operational discipline, and identity hygiene is directly useful in enterprise work. The privacy-first posture the Tor environment forces on you is a posture enterprise security would benefit from borrowing.
And partly because I like the problem. Curiosity is still, after all this time, the most reliable engine for learning I have found.
Where to go from here
If you want the research context and the address of the onion site, that lives on the research page. If you want to talk about any of this, I am easy to find on LinkedIn. The invitation is specifically to other practitioners — people who run infrastructure, lead teams, and want a more honest view of this corner of the field than the trade press typically offers.
The interesting part of the dark web, for a defender, is not what is hidden on it. It is how the people who operate there think about trust. That is a useful mirror to hold up to your own environment.