OPSEC: Mistakes That Deanonymize You

HiddenForge protects the network path to your server. It cannot protect you from mistakes you make everywhere else. The failures below are the ones that actually deanonymize onion services, and every one of them is on the operator, not the tool. Read this before you put anything real online.

Exposing the backend

The whole design rests on your backend being unreachable except through Tor. The moment you give it a published port or put it on an internet-facing network, someone can connect to it directly, and your server's real IP is discoverable.

• Never add a ports: mapping to your backend.
• Keep the backend on tor-internal only, never on tor-external.
• Don't "temporarily" expose it to test. Test through the .onion.

Losing or leaking the key

Your .onion is a private key. There are two ways to lose:

• Lose the key file and the address is gone forever. Back it up, encrypted and offline. See Backing Up Your Onion Address.
• Leak the key file and someone else can impersonate your service. Don't paste it, email it, or sync it to a third-party cloud in the clear. If it might have been exposed, generate a new address.

Metadata in your content

The network layer can be perfect and your own files can still name you:

• Photos carry EXIF data: GPS coordinates, camera serial numbers, timestamps. Strip it before publishing.
• Documents embed authors and revision history. Office files and PDFs often contain a real name, a username, or the path they were saved from. Export clean copies.
• Web apps leak. Error pages that print internal IPs or hostnames, Server: headers, default admin pages, analytics that call home. Turn off anything that talks to the outside world.

Mixing your hidden identity with your real one

Correlation, not code-breaking, is how most operators are found.

• Don't reuse usernames, email addresses, PGP keys, writing style, or profile photos between your onion identity and your real one.
• Don't log into personal accounts from the same browser or session you use to run the service.
• Don't post at times, or about things, that tie the two together.

Trusting the host you don't control

HiddenForge hardens the container, not the machine under it.

• If the host is compromised, the container's protections don't save you. Keep the host patched, minimal, and access-controlled.
• If the host can be physically seized, assume anything on its disk can be read. Generate keys offline and consider running from storage you can destroy.

Small technical slips that matter

• Clock drift. If the host clock is off by more than about half an hour, Tor can't validate the network and won't start. Keep time synced.
• Leaving logs on. HiddenForge turns off the container's host log by default. If you turn logging back on for debugging, remember it writes request data to the host disk. Turn it off again.
• Running as full root unnecessarily. Prefer rootless Podman where you can. A container escape then lands in an unprivileged user namespace, not on the host as root.

The mindset

Assume every layer will eventually be tested. HiddenForge makes the network layer strong so that your attention can go where the real risk is: your content, your identities, and the machine you run it on. The tool does its job silently. These are the parts only you can get right.