Anonymity mistakes that deanonymize you

This is the number-one deanonymizer. You buy BTC on Coinbase or Binance — which hold your government ID, selfie, and bank account — then send it directly to a hosting payment address. The exchange's records plus the public blockchain now draw a straight line from your verified identity to the server. A subpoena to the exchange resolves the whole graph. The host never KYC'd you; the exchange did, and Bitcoin is a permanent public ledger.

The fix: pay with Monero, or break the chain

NoKycVPS takes 10 cryptocurrencies and uses balance-based billing — you top up, then deploys debit the balance. The strongest option is Monero (XMR): amounts, sender, and receiver are hidden by ring signatures and stealth addresses, so there is no public graph to subpoena. XMR credits your balance in about 30 seconds. If you must use Bitcoin, never send it directly from a KYC exchange — acquire it non-KYC (peer-to-peer, an XMR→BTC atomic swap, a no-KYC ATM) or route it through Monero first. Top-up bonuses (+30% at $100, up to +70% at $1000) make pre-funding a balance once, then deploying repeatedly, both cheaper and less linkable than paying per-server. See anonymous server payment for the full chain-breaking flow.

You register the server with [email protected] — the same address on your LinkedIn. Or you pick the handle dragon_dev, which is also your GitHub, your old forum account, and a 2014 Reddit post with your city in it. One shared string collapses the clean identity into the known one. Username and email reuse is trivially searchable and is how most pseudonymous operators are unmasked — no exploit required, just a search.

The fix: a fresh, unlinked identity per project

• Email: NoKycVPS sends no verification email, so a disposable or alias address works. Generate a new one per project — never an address that has ever touched your real name.
• Username/handle: high-entropy and meaningless. Not a variation of any handle you have used elsewhere. Do not let a password manager autofill a name field.
• Password: unique, generated, stored only in a vault that is itself isolated from your daily one. A reused password links accounts the moment one database leaks.

Treat the identity as compartmentalized: it shares nothing — not a string, not a payment source, not a device fingerprint — with any identity that points at you. See the glossary entry on compartmentalization for the discipline this requires.

You deploy the server, open a terminal, and run ssh [email protected] from your home connection. Your residential IP is now in the server's /var/log/auth.log, and your ISP's NetFlow records the connection to that datacenter IP at that minute. If the server is ever seized or the ISP is queried, your home address is one log line away. The anonymous payment and email bought you nothing.

The fix: never touch the server from a network that identifies you

Egress through Tor or a VPN that is itself unlinked to you. The cleanest is Tor over a SOCKS proxy in your SSH config:

# ~/.ssh/config
Host myvps
  HostName 203.0.113.10
  User root
  ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %p

That routes the SSH session through the local Tor daemon (port 9050). Your home IP never reaches the server; the auth log shows a Tor exit node. A reputable no-logs VPN (paid anonymously) is acceptable when you need lower latency, but it shifts trust to the VPN. For a hardened baseline on the server side — key-only auth, no root password login, fail2ban — see SSH hardening. Note: the SSH key itself is an identifier (see Mistake 8), so generate a dedicated key for this identity.

You route traffic through Tor or a VPN, but your DNS lookups still go to your ISP's resolver in plaintext on port 53 — outside the tunnel. Your ISP (and anyone on the path) sees every hostname you resolve, defeating the tunnel entirely. This is the most common silent leak because the tunnel appears to work; only the name resolution escapes.

The fix: resolve over the tunnel and verify

With Tor, route DNS through it (tor-resolve, or set Tor as a DNS port and point the system at 127.0.0.1). With a VPN, use the VPN's own resolver and enable its kill switch and DNS-leak protection. Then verify — do not assume. On the client, watch for any plaintext DNS escaping the tunnel:

# any plaintext :53 leaving outside the tunnel interface = leak
sudo tcpdump -n -i any 'udp port 53 or tcp port 53'

If you see queries on your physical interface instead of the tunnel, DNS is leaking. Force all resolution through the tunnel resolver and re-test. Browser-based leak-test pages confirm the result quickly, but the packet capture is authoritative.

You access the panel and the anonymous identity from your normal browser. Even over Tor or VPN, your browser broadcasts a fingerprint — user-agent, screen resolution, installed fonts, canvas/WebGL rendering, language headers, plugins — that is often unique. The same fingerprint on your real-name accounts and the anonymous one links them, no IP needed.

The fix: a uniform, anti-fingerprinting browser

Use the Tor Browser, which deliberately makes every user look identical (same window size, font set, spoofed canvas, blocked WebGL). Do not maximize the window (it leaks exact screen size), do not install extensions (each one is a distinguishing bit), and do not log into any real-name account in the same browser or session. If you need a non-Tor browser, a hardened profile with resist-fingerprinting enabled and a strict separation from your daily browser is the minimum. The principle: the anonymous identity must look like everyone else, and must never share a browser session with an identity that points at you.

You register a domain and the registration form quietly publishes your real name, address, phone, and email in public WHOIS. Even with GDPR redaction at the registry, many registrars leak the registrant in historical WHOIS snapshots that third parties archive permanently. A single domain tied to the server, registered with your real details, undoes everything else.

The fix: register the domain through the same anonymous channel

NoKycVPS sells domains across 26 TLDs under the same no-KYC, crypto-only account — so the domain inherits the identity you already compartmentalized rather than creating a new KYC link at an outside registrar. Register it with the project's anonymous email, never real contact details, and prefer TLDs and registries that do not mandate verified registrant data. Then check what is actually published: query the domain's WHOIS after registration and confirm no real name, address, or daily-use email appears. Treat historical WHOIS as permanent — if your real details were ever published for that domain, the domain is burned.

You host or share a file and the metadata carries your identity. A phone photo embeds EXIF: GPS coordinates of where it was taken (often your home), the camera serial, the exact timestamp. A PDF or DOCX stores the author name, your OS username, and software version. A .tar.gz or .zip records file owner UIDs and your local paths (/home/john/...). None of this is visible in the content — it ships silently.

The fix: strip metadata before anything leaves the server

# strip ALL metadata from an image (overwrite, no original kept)
exiftool -all= -overwrite_original photo.jpg

# confirm it is clean
exiftool photo.jpg   # should show only basic dimensions

# for documents, use mat2 (Metadata Anonymisation Toolkit)
mat2 report.pdf      # writes report.cleaned.pdf

Build stripping into your workflow, not as an afterthought. Avoid usernames in archive paths, set file owners to a generic UID before packing, and never publish a file straight from a camera or office suite. One un-stripped photo with GPS has deanonymized more operators than any network attack.

Smaller signals correlate just as well in aggregate. A server whose clock is set to Europe/Paris, whose locale is fr_FR, and whose activity clusters at 9am–5pm CET narrows you to a country and a daily routine. Your SSH public key is a stable fingerprint — paste the same key into a real-name GitHub account and the anonymous server, and the keys match. Shell history, the From: header on cron mail, and package mirror selection all leak locale too.

The fix: normalize to UTC and use dedicated keys

# neutral timezone and locale on the server
sudo timedatectl set-timezone UTC
sudo update-locale LANG=C.UTF-8

# generate a key used ONLY for this identity
ssh-keygen -t ed25519 -f ~/.ssh/id_proj -C ""

Set the system to UTC and a neutral locale so timestamps and logs reveal nothing regional. Use a comment-free, project-dedicated SSH key (the -C "" strips the default user@host comment that otherwise embeds your real username). Choose the server region for legal reasons — Iceland or Switzerland — not to match your home timezone. Vary working hours if activity timing is part of your threat model. The whole point of compartmentalization is that no single signal, however small, points home.