Privacy, OPSEC & Self-Sovereignty | CypherpunkGuide on CypherpunkGuide

After Buying Bitcoin: A 10-Step Custody Drill (2026)

Mon, 27 Jul 2026 00:00:00 +0000

A note on funding: CypherpunkGuide carries no surveillance advertising — no ad networks, tracking pixels, or sponsored content. It is funded by transparent streams: reader donations now; subscription and editorially-aligned affiliate later. We answer to our readers, not to advertisers.

An exchange balance is not a completed custody handoff. Its status page is a custodian record; separately verify the on-chain output to an address your wallet tracks. A wallet holds keys that authorize transactions, not coins inside a device. With third-party custody, the provider controls key access; with self-custody, you do. This technical distinction does not settle legal ownership, which depends on provider terms and law (SEC Investor Bulletin, 2025).

The dangerous shortcut is to see a number and assume the handoff worked. In our isolated Bitcoin Core v31.1.0 drill, a funded wallet and a watch-only wallet both displayed 0.01000000 BTC. The watch-only copy had private keys disabled, returned complete=false when asked to sign a partially signed Bitcoin transaction, and rejected a direct spend with RPC error -4. A correct balance proved observation, not control.

The useful question is what evidence shows you can receive, sign, and recover without trusting a reassuring screen. This 10-step custody drill builds that evidence. Self-custody does not remove risk; it transfers risk to your keys, devices, backups, judgment, and emergency plan.

First principle: self-custody is a risk transfer
#

Self-custody replaces some provider risks with direct operational responsibility. It can reduce dependence on an exchange, but it can also turn one lost secret, damaged backup, or rushed transaction into permanent loss.

The SEC frames both sides: a custodian controls key access and can fail; a self-custody user assumes key security. “Withdraw everything now” is not universal advice. Move only what you can protect and recover.

Where the balance appears	Who has signing material?	Main risk you retain	What closes the handoff?
Exchange account	Provider or its custodian	Provider failure, account lock, terms, security, and withdrawal access	Receipt of a confirmed withdrawal; the custody handoff closes only after separate Signing and Recovery proofs
Self-custody wallet	You, or the signers in your policy	Secret loss, device compromise, bad backup, coercion, and user error	Receipt, Signing, and Recovery proofs
Watch-only wallet	Nobody in that wallet	False confidence from a visible balance	A separate signer must complete an authorized spend

A proof-based custody handoff ends with evidence of receipt, signing authority, and recoverability. It does not make self-custody universally best. If you cannot protect recovery material yet, keep the amount small while learning.

Receipt, Signing, and Recovery are different proofs
#

Receipt proves that bitcoin reached the intended wallet, Signing proves that the required key can authorize a transaction, and Recovery proves that an independent restoration can recreate that authority after loss.

The checks fail independently. A confirmed transaction can coexist with a bad backup. A watch-only wallet displays transactions without a private key. A seed can restore a different empty wallet when the passphrase, wallet format, account, address format, or key path differs.

Proof	Question answered	Strong evidence	What does not prove it
Receipt	Did the intended wallet receive the withdrawal?	Full address match, transaction ID, expected amount, and suitable confirmation status	Exchange status alone; a copied address checked only at its ends
Signing	Can the required signer authorize the exact spend?	A small transaction signed after reviewing destination, amount, and fee on a trusted display	A visible balance; a watch-only descriptor; `listunspent.spendable=true`
Recovery	Can the wallet be rebuilt after loss?	An isolated restore that finds the expected funds and signs a small spend	A test withdrawal; an unopened backup; seed words without the full recovery recipe

A watch-only wallet tracks transactions without signing keys. A PSBT, or partially signed Bitcoin transaction, lets one wallet prepare a transaction and another device sign it. Neither visible balance nor PSBT preparation proves signing authority.

The 10-step custody drill
#

Run the drill in order and stop when a result is ambiguous. Do not move the remaining balance until Receipt, Signing, and Recovery each have evidence you can explain without relying on a wallet’s headline number.

Step 1: Preserve the purchase and secure the exchange account
#

Preserve the original purchase record, including the date, amount, fiat value, fees, and order ID. Later add the withdrawal record and transaction ID, but never store a seed, private key, PIN, or passphrase with them. Use a unique password or passkey and strong multi-factor authentication while funds remain at the exchange.

Tax rules vary. Preserve the records, then ask your current local tax authority or adviser what fields and events apply; do not import another jurisdiction’s checklist. If you bought privately, also review our guide to buying bitcoin without know-your-customer (KYC) identity checks.

Step 2: Decide how much responsibility to take today
#

Choose an amount small enough that a setup error would not be catastrophic. A software wallet favors convenience; a hardware signer can isolate keys and provide an independent display; multi-signature can add resilience and failure modes. None is automatically safe.

List the threats that matter: malware, device loss, fire, physical access, coercion, incapacity, and death. If someone can force an unlock or signature, use the separate custody-under-coercion threat model before acting.

Step 3: Obtain the wallet from a verifiable source
#

Use the project’s official site or repository. Verify software releases as its instructions require. Inspect hardware packaging, initialize the device yourself, and never accept prewritten recovery words. Update only through the vendor’s authenticated flow.

Check maintenance status, backup format, address verification, and recovery documentation. The goal is not a brand; it is a workflow you can verify and repeat.

Step 4: Create the wallet and record the full recovery recipe
#

Generate recovery material on the intended wallet or signing device, offline when its official procedure requires it. Never photograph it, paste it into cloud notes, send it through chat, or type it into a website. Treat any request for those words as hostile unless you deliberately initiated an official recovery on a trusted device.

Do not write “seed phrase” and stop. BIP39 maps the mnemonic plus the exact passphrase to a seed; every passphrase yields a valid seed, so a typo can open a different wallet. BIP380 warns that key-only backups can omit script type and derivation information. Record the wallet/version, backup standard, account, script (address) type, key-derivation path (how the wallet locates keys), and whether a passphrase is required. A seed alone does not guarantee cross-wallet recovery. An extended public key (xpub) or public descriptor can monitor history but cannot sign, and sharing it leaks financial privacy; a private descriptor is secret.

Step 5: Check the backup before it carries the full balance
#

Use the maker’s official backup-check when available. Trezor’s Safe 3 check, for example, compares the entered backup with the device. It shows that the words match that device; it does not prove the passphrase, derivation, or ability to spend after restoration.

Never test a real backup in a website, chat, notes form, or untrusted computer. If no safe check exists, plan an isolated restore on known-compatible hardware. A dry run checks transcription; Step 10 tests the full path.

Step 6: Generate a fresh address and verify every character
#

Create a fresh Bitcoin receive address. On a device with an independent display, compare every character there with the wallet app and exchange form, not just the ends. Trezor’s wallet-address explanation documents the full-character check. The display proves what the device generated; it does not prove that you chose the right network or intended recipient.

For this on-chain drill, select native Bitcoin only where both the sender and receiving wallet support the same Bitcoin network. A mismatched network can make funds inaccessible; a deliberately different system such as Lightning needs its own documented receive flow. Address reuse and later consolidation of UTXOs (unspent transaction outputs—the spendable chunks tracked by Bitcoin) can reveal links; see on-chain privacy and Silent Payments.

Step 7: Make a risk-limiting test withdrawal
#

Withdraw an amount above the exchange minimum and large enough to remain useful after present and future fees. Recheck the full address at final confirmation. Record the withdrawal ID, fee, amount, and transaction ID privately.

This limits loss from an address, network, or workflow mistake only on this receipt path. Fees may make repetition impractical. Success proves neither Signing nor Recovery.

Step 8: Establish Receipt proof
#

Wait for a confirmation level appropriate to the amount and risk. Match the transaction ID, destination, and amount after the withdrawal fee. Confirmation shows that the transaction entered the blockchain; it does not show that your backup can recreate the signer.

Your own node reveals less query metadata than a public explorer. An explorer may learn the address and your network metadata. Do not share screenshots with balances, labels, addresses, or transaction IDs.

Step 9: Establish Signing proof with a small spend
#

Prepare a separate small transaction to a fresh address you control. If the signer has an independent display, inspect the full destination, amount, and fee there; otherwise recognize that destination verification shares the host’s compromise risk. Sign, broadcast, and confirm it. Account for the change output—the remainder returned to your wallet—and the privacy effect of combining UTXOs.

Our watch-only wallet prepared a PSBT but returned complete=false; a direct spend failed with -4. Observation can prepare a request, while the private key authorizes it. This round trip proves current Signing, not Recovery after loss.

Step 10: Establish Recovery proof, then close the operating plan
#

Restore independently in an isolated, known-compatible environment. Confirm the expected address or descriptor, funded UTXO, and a small signed transaction after checking every output. Do this before a device fails. Use a trusted spare device or an offline environment. After recording the non-secret result, reset any temporary restore target using its documented procedure; never destroy your only valid backup.

We backed up the receiver before funding it. The restored copy found 0.01000000 BTC, signed 0.00200000 BTC, and reached 1 confirmation. The backup therefore regenerated the tested keys and signing authority.

Document an update cadence, two failure-independent backup locations, and an emergency plan. Keep discovery instructions separate from signing secrets. After material wallet or passphrase changes, rehearse again. For the remaining balance, use a fresh address and repeat the full check; do not reuse one solely because its test succeeded.

What our isolated Bitcoin Core 31.1 drill found
#

Our 202.22-second regtest—Bitcoin Core’s private regression-test network—separated balance visibility from signing and recovery. It used no real bitcoin, disabled P2P networking, and ended with networkactive=false and 0 connections.

We matched Bitcoin Core v31.1.0 to SHA256 b80d9c3e04da78fb6f0569685673418cf686fadba9042d926d13fb87ff503f9e and Michael Ford’s signature (E777299FC265DD04793070EB944D35F9AC3DB76A). The results and script omit keys, addresses, transactions, backups, credentials, and host identifiers. The script combines the custody logic into one fresh run; the JSON records the separately verified release and the two observed stages that produced these measurements. The script expects already-verified binaries and does not repeat the archive checksum or signature check.

Lab observation	Measured result	Safe conclusion
Receipt wallet balance	0.01000000 BTC	The funded wallet observed the confirmed output
Watch-only balance	0.01000000 BTC	The same balance can be visible without private keys
Signing checks	`private_keys_enabled=false`; PSBT `complete=false`; direct spend -4	Balance visibility is not signing authority
`listunspent.spendable`	`true`	Not proof: Core 31.1 documents this deprecated field as always true
Pre-receive backup restore	0.01000000 BTC restored; 0.00200000 BTC spent; 1 confirmation	The tested backup recovered the keys needed to sign

This logical regtest is not a mainnet benchmark; 1 confirmation is only its completion condition. Bitcoin Core 31.1 local help labels listunspent.spendable “(DEPRECATED) Always true,” so it is not a signing gate. Our asset establishes the v31.1 behavior; archived Core 30 references define private_keys_enabled and watch-only balance buckets, while issue #21104 records the visibility counterexample. The article therefore uses an actual signed spend—not a field name—as the Signing proof.

Bottom line: finish the handoff before moving the balance
#

Secure the exchange record, choose a manageable custody scope, and send a test amount to an address checked in full. Then prove Receipt, Signing, and Recovery separately.

If a proof fails, stop. A confirmed withdrawal proves receipt, not recovery. A seed is incomplete without the right format, settings, and passphrase. Move the balance only after the new responsibilities are tested.

Frequently asked questions
#

The short answers preserve the same boundary: self-custody changes who bears risk, a test withdrawal proves only receipt, and recovery requires the complete wallet-specific recipe.

Should I withdraw bitcoin from an exchange immediately?
#

Not automatically. Exchange custody carries provider and account risk; rushed self-custody carries key and backup risk. Secure the account and begin with a test amount. Increase it only after Receipt, Signing, and Recovery pass.

Do I need a hardware wallet?
#

Not for every amount. A maintained software wallet may suit a small spending balance. A hardware signer reduces some online attack paths and adds an independent display, but it cannot repair a bad backup, prevent coercion, or inspect for you.

Does a successful test withdrawal prove self-custody?
#

It proves Receipt when the full address, transaction, amount, and confirmation match. A watch-only wallet can show that balance without Signing, and an incomplete or incompatible backup can still fail Recovery. Run all three gates.

Can any wallet recover my bitcoin from the seed phrase?
#

No. Recovery depends on the standard, exact passphrase, derivation, account, script type, and implementation. Follow documented compatibility or the original wallet’s official process. Never enter real seed words into a website.

What tax records should I keep after buying bitcoin?
#

Preserve the purchase and withdrawal records, then follow the current requirements of your local tax authority or adviser. Do not treat a US or online checklist as universal. This article gives no tax classification or personal tax advice.

Cora Aegis

Cora Aegis is the named pseudonym behind CypherpunkGuide, writing privacy-first guides grounded in primary sources and reproducible tests.

More about Cora →

Primary sources and archives
#

These primary or official sources support the safety-critical claims. Every original/archive pair below has an exact timestamp and a replay-checked identity match.

#	Source	Original URL	Archived
1	SEC, “Crypto Asset Custody Basics for Retail Investors” (2025)	https://www.investor.gov/introduction-investing/general-resources/news-alerts/alerts-bulletins/investor-bulletins/crypto-asset-custody-basics-retail-investors-investor-bulletin-0	https://web.archive.org/web/20260718185151/https://www.investor.gov/introduction-investing/general-resources/news-alerts/alerts-bulletins/investor-bulletins/crypto-asset-custody-basics-retail-investors-investor-bulletin-0
2	Bitcoin Core 30 `getwalletinfo`	https://bitcoincore.org/en/doc/30.0.0/rpc/wallet/getwalletinfo/	https://web.archive.org/web/20260217150325/https://bitcoincore.org/en/doc/30.0.0/rpc/wallet/getwalletinfo/
3	Bitcoin Core 30 `getbalances`	https://bitcoincore.org/en/doc/30.0.0/rpc/wallet/getbalances/	https://web.archive.org/web/20260509142424/https://bitcoincore.org/en/doc/30.0.0/rpc/wallet/getbalances/
4	Bitcoin Core issue #21104, watch-only balance classification	https://github.com/bitcoin/bitcoin/issues/21104	https://web.archive.org/web/20221205111908/https://github.com/bitcoin/bitcoin/issues/21104
5	BIP32, Hierarchical Deterministic Wallets	https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki	https://web.archive.org/web/20260711030310/https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
6	BIP39, Mnemonic code for deterministic keys	https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki	https://web.archive.org/web/20260711080112/https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
7	BIP380, Output Script Descriptors	https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki	https://web.archive.org/web/20260705135907/https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki
8	Trezor, wallet addresses and full-character verification	https://trezor.io/learn/basics/where-are-my-coins-stored-how-bitcoin-wallets-actually-work	https://web.archive.org/web/20260519102414/https://trezor.io/learn/basics/where-are-my-coins-stored-how-bitcoin-wallets-actually-work
9	Trezor, choosing a withdrawal network	https://trezor.io/guides/sending-receiving-staking-funds/moving-funds-from-exchanges/how-to-choose-the-right-network-when-withdrawing-from-or-sending-to-trezor	https://web.archive.org/web/20260215225443/https://trezor.io/guides/sending-receiving-staking-funds/moving-funds-from-exchanges/how-to-choose-the-right-network-when-withdrawing-from-or-sending-to-trezor
10	Trezor Safe 3, Check wallet backup	https://trezor.io/guides/backups-recovery/general-standards/check-backup-on-trezor-safe-3	https://web.archive.org/web/20260207110415/https://trezor.io/guides/backups-recovery/general-standards/check-backup-on-trezor-safe-3
11	Trezor, passphrase behavior	https://trezor.io/guides/backups-recovery/advanced-wallets/what-is-a-passphrase	https://web.archive.org/web/20260312222704/https://trezor.io/guides/backups-recovery/advanced-wallets/what-is-a-passphrase

Bitcoin Password Recovery: What AI Can and Can't Do (2026)

Sun, 23 Aug 2026 00:00:00 +0000

A note on funding: CypherpunkGuide carries no surveillance advertising—no ad networks, tracking pixels, or sponsored content. It is funded by transparent streams: reader donations now; subscription and editorially aligned affiliate later. We answer to our readers, not to advertisers. No recovery service or wallet vendor paid for this test.

A lost Bitcoin password is not one technical problem. It may be a custodial-account login, an encrypted wallet-file password, a BIP39 passphrase, missing recovery words, or simply a missing backup. Bitcoin Core cannot reset or reveal a forgotten wallet passphrase; that does not mean an offline tool can never test a small set bounded by memory (Bitcoin Core, Managing the Wallet).

The dangerous promise is that “AI recovery” changes the cryptography. It does not. We ran 11 synthetic BTCRecover candidate-generation tests with no wallet, seed, key, address, hash, funds, or real password. Adding remembered structure reduced one fictional search from 2,080 candidates to 16 while keeping the target. Expanding five typo classes from one possible change to two moved another search from 60 to 1,681 candidates.

The useful question is therefore not “Which AI can crack my wallet?” It is: which failure do you have, what non-secret evidence can narrow it, and where will the complete unlock set exist? An unlock set is the encrypted wallet or seed plus enough real candidate material to unlock it. Keep those halves apart until an offline check.

Can a lost Bitcoin password actually be recovered?
#

Bitcoin password recovery is candidate testing against the correct encrypted wallet—not a reset. It can work when memory bounds the guesses; it cannot recreate a missing key or a random secret from nothing.

Start by naming the access layer. The wrong label sends people toward the wrong tool—and sometimes toward a scam.

A mnemonic is the ordered recovery-word backup. A seed is the root secret derived from that backup, sometimes together with a passphrase; wallet software then derives the private keys that authorize spending.

What you lost	What it controls	Correct first path	What not to do
Exchange or custodial-app login	Access to a provider account	Use the provider’s official account-recovery flow	Do not download a “wallet cracker” or give a stranger the account login
Encrypted wallet-file password	Decryption of locally stored private keys	Preserve the wallet file; identify its exact format; test remembered candidates on a copy	Do not overwrite the original or upload it with candidate passwords
BIP39 passphrase	Derivation of a different seed from the same mnemonic	Use the exact mnemonic plus a known address or extended public key—a public identifier that cannot spend but can expose address history—entirely offline	Do not expect a “wrong passphrase” error; every passphrase derives a seed
Missing or mistyped mnemonic words	Reconstruction of the seed backup	Follow a wallet-specific seed-recovery path with a known target	Do not paste the words into a website or hosted AI
Missing wallet file	Location of the encrypted key material	Search old devices and backups without changing originals	Do not assume a password search can replace a file that no longer exists
Stolen or scammed bitcoin	Control has moved to another key	Report quickly to the relevant exchange, law-enforcement channel, and local adviser	Do not confuse tracing or legal recovery with forgotten-password recovery

A BIP39 passphrase is the optional text combined with a mnemonic to derive a wallet seed. Under BIP39, every passphrase produces a valid seed. A typo may therefore open a different, empty wallet instead of displaying an error. That is a different validation problem from unlocking an encrypted wallet.dat file.

If you do not yet have an independent backup and recovery proof, our 10-step Bitcoin custody drill explains how to avoid creating the same failure again.

What AI did in one reported 2026 recovery
#

One 2026 “AI cracked a Bitcoin wallet” report described file discovery, not broken cryptography. CoinDesk reported that Claude helped locate an older wallet backup; the owner then decrypted it with a password already written down.

In that report, the consequential actions were locating the older backup and using the existing password. More generally, an AI can help compare non-secret file metadata or turn abstract memory patterns into a template. Wallet software still decides whether a candidate decrypts the right key material.

A passwordlist contains one complete guess per line. A tokenlist contains remembered fragments that BTCRecover combines into complete candidates.

AI can help with	AI cannot establish	Safer evidence
Classifying a wallet format from non-secret metadata	Ownership of the wallet	Provenance records and an offline inspection of the original media
Turning remembered patterns into a passwordlist or tokenlist template	That the true password is inside the list	`--listpass`—a no-wallet candidate preview—and the resulting count on the offline machine
Locating likely backup files by name, date, and size	That a file contains the target keys	Wallet-specific parsing and a known address or public target
Explaining official tool options	That a generated command is safe for your exact wallet	Version-matched official documentation and a disposable test copy
Diagnosing a failed run from redacted errors	The missing secret itself	A successful fixed software check followed by a controlled spend

The case is useful because it shows AI’s strongest role: recovering context. It is not a success-rate estimate, a reproducible benchmark, or permission to upload an old computer to a cloud model. Old disks may contain tax records, identity documents, browser profiles, other wallets, and password remnants. Do not upload the disk or its real recovery material; use abstract patterns and placeholders, following the data-boundary method in our AI assistant privacy audit.

AI plans the candidates; software checks them
#

An AI-assisted recovery system is a planner around a fixed password checker. The model can order guesses; BTCRecover or Hashcat still decides whether one decrypts the wallet.

A deterministic checker is software that gives the same validation result for the same wallet and candidate. Calling its planning layer “AI” does not make an unbounded random-password space smaller.

In one published benchmark dated 2026-07-04, with 30 seconds allotted to each test, BTCRecover 1.13.0 on Windows 11 with a Ryzen 9 9950X and RTX 5090 measured 3,209.22 passwords per second for its Bitcoin Core SQLite sample and 11,948.17 for its Berkeley DB (BDB) sample (results JSON). Bitcoin Core calibrates key-derivation work when a wallet is encrypted, so the sample iteration counts and speeds are not backend constants or universal Core rates (Core source).

The scale is still instructive. At that sample’s 3,209.22 guesses per second, exhausting every ten-character lowercase string—26^10, or 141,167,095,653,376 candidates—would take about 1,393.9 years. A uniformly positioned target would take roughly 697.0 years on average. This is an illustration for one sample, not a model of human password habits.

BTCRecover also publishes an AI-skill evaluation. Its percentages are rubric ceiling scores for workflow behavior, not the share of wallets recovered. We calculated the paired differences from the official chat and Docker tables: five of six listed models had a lower Docker/tool-use score than chat, and the median change was -3.7 percentage points.

Model in BTCRecover table	Chat score	Docker/tool-use score	Change
qwen3.6-27b	70.9%	58.4%	-12.5 points
gemma-4-31b	67.5%	65.0%	-2.5 points
gemma-4-26b-a4b	57.6%	39.9%	-17.7 points
gemma-4-12b	54.2%	51.7%	-2.5 points
qwen3.5-9b	52.4%	47.5%	-4.9 points
gemma-4-e4b	30.8%	33.4%	+2.6 points

This evaluation does not prove that tools make models worse in general or explain why five scores fell. Chat mode provides advice without tools, while Docker mode lets the model under evaluation execute commands in a sandbox and applies runner-specific scoring instructions. The tables therefore compare different observable behavior, not a controlled causal effect of tool access. The BTCRecover AI workflow tries to constrain the workflow.

What our 11-run synthetic BTCRecover lab found
#

The Cora candidate-space lab measures how remembered structure changes the number of guesses. It uses fictional inputs only; it neither opens a wallet nor predicts recovery odds.

We cloned BTCRecover from its official origin at commit 1457088acf17630eb12a5b53989982ac34e55f2a, recorded the repository tree, confirmed the tracked worktree was clean, and hashed both the entry point and lab script. We then used version 1.13.0-Cryptoguide on Python 3.12.10 to run 11 --listpass scenarios. Every run retained its fictional target, and no run emitted duplicate candidates.

We kept four fragment families constant—two alternatives in each of two word families, plus two years and two symbols—then added knowledge one constraint at a time:

Candidate design	Unique candidates	Fictional target retained?	Change from unstructured
Eight related fragments on separate lines	2,080	Yes	Baseline
Same-family variants made mutually exclusive	632	Yes	69.62% fewer
All four fragment families required	384	Yes	81.54% fewer
Required and fixed to remembered positions	16	Yes	99.2308% fewer

The final structured set was one-130th as large as the unstructured set. This does not mean every memory is accurate. It means the most valuable work is often deciding which constraints are genuinely known and which are hopeful guesses.

We also started from one fixed fictional 16-character whole-password guess. Four targeted one-error searches generated only 12 to 17 candidates each. Enabling five typo classes together produced 60 candidates at one possible change and 1,681 at two—28.02 times as many.

The result supports a staged policy: exact whole guesses first, one plausible error class second, broader combinations last. A model can help express that plan, but it should not invent biographical tokens, dates, or patterns and present them as memory.

You can inspect the redacted results JSON and rerun the candidate-space lab against the pinned BTCRecover checkout. The assets contain fixed synthetic strings only. The script’s warning-suppression flag is limited to no-wallet enumeration and must not be copied into real recovery work.

BTCRecover vs Hashcat vs local AI vs a recovery service
#

The right recovery method matches the wallet format while exposing the least secret material. BTCRecover and Hashcat check candidates; AI plans; a human service adds a trust decision.

A Hashcat mode selects the validator for one stored wallet or hash format; it does not select the true password.

Method	Best fit	Main advantage	Main limit	Secret boundary
BTCRecover passwordlist	Several complete guesses	Lines are tested verbatim; conservative typo classes can be layered	A whole-password list is not combined into fragments	Keep the wallet or documented reduced extract separate until the offline run; an extract may still expose identifying or correlation data
BTCRecover tokenlist	Remembered fragments, variants, and positions	Mutual exclusion, required tokens, anchors, and wildcards encode memory	Bad structure can exclude the true candidate or explode the search	Build a placeholder template online; substitute real fragments offline if the matching wallet is present
Hashcat	A supported wallet mode plus masks (character patterns) or rules (candidate changes)	Mature GPU-oriented attack engine and explicit mode matrix	Mode support is not a recovery guarantee; extraction and rule design are format-specific	Follow the exact official mode documentation and never upload the full unlock set
Local AI agent	Triage, file search, template construction, command review	Can work with local files and adapt the procedure	“Local” is not automatically offline, non-logging, or safe	Verify network state, model hosting, logs, extensions, and the working directory
Hosted AI	Non-secret explanation and placeholder planning	Accessible and useful for narrow documentation questions	Provider receives prompts, attachments, account/network metadata, and possibly retention	Give it only abstract patterns and fictional placeholders—never a real wallet, seed, key, password, or actual candidate string
Human recovery service	High-value, technically difficult cases after due diligence	Specialist format knowledge and equipment	Fraud, opaque methods, fee disputes, identity exposure, and key theft	Prefer a documented reduced extract or retain one indispensable half; even a non-spending extract may remain privacy-sensitive

Hashcat’s official example-hashes page lists modes for Bitcoin Core/Litecoin wallet.dat, Electrum, Blockchain.com/My Wallet, Bisq, and other formats. That list proves that validators exist. It does not prove that your backup is intact, that the password is guessable, or that the selected mode matches your file.

A seven-step offline-first recovery protocol
#

An offline-first recovery protocol keeps wallet material and real guesses apart until a disconnected machine checks them. Going offline later cannot undo an earlier cloud disclosure.

Stop changing the original. Preserve the old device and create a byte-for-byte or tool-documented working copy where possible. Record a cryptographic hash—a digital fingerprint—of each file so you can tell whether the copy changed. Do not repair, migrate, or import your only wallet file in place.
Classify the failure before choosing software. Record non-secret facts: wallet product and approximate version, operating system, file name and size, creation period, whether you have a mnemonic, and the exact error. Do not record the seed, passphrase, private key, or candidates in the same online note.
Establish authorization and a target. Work only on a wallet you own or are legally authorized to recover. Preserve a minimal offline record of ownership, authorization, and file provenance without including wallet secrets. For a seed or BIP39-passphrase search, identify the documented account and path rules used to derive addresses, plus a known public target, without broadcasting your full address history.
Acquire and verify the tool while online. Start from the maintained project’s official repository. Pin the commit, confirm the tracked worktree and repository tree match that commit, and use the project’s signed-release check when one is documented. Test installation with bundled synthetic fixtures, not your wallet.
Design the smallest honest candidate stages. Put complete guesses in a passwordlist; put fragments that must be combined in a tokenlist. Start with exact guesses, then one remembered uncertainty, then broader typo or wildcard rules. Use placeholders online whenever the matching wallet or seed is on the same machine.
Join the unlock set only offline. Disconnect the recovery machine before it holds both encrypted wallet material and real candidates. Confirm that the candidate count is plausible before a long run. BTCRecover documents reduced wallet extracts for some formats; use one only when current official documentation says it cannot spend funds by itself, and still treat it as privacy-sensitive correlation data.
Treat a successful unlock as a migration event. On a trusted wallet, create and verify a fresh recovery setup, then move the funds after checking destinations and fees. Preserve a non-secret audit note, not the recovered password or private keys. Follow the password-manager migration audit for any related credential changes.

Do not combine “let the cloud model inspect everything” with “I will go offline before the final command.” The disclosure already happened. A hosted model should receive only abstract structure and fictional placeholders, not even a real candidate list without the wallet. Use the AI-age threat-model guide to map model hosting, logs, plugins, synced folders, and account identity before treating an agent as local.

How to evaluate a recovery service without surrendering the wallet
#

A recovery-service review is a secret-custody audit. The key question is not how impressive the success story sounds; it is whether the provider can do useful work without receiving every component needed to unlock and move the funds.

The FBI’s recovery-scheme warning focuses mainly on firms claiming to recover cryptocurrency lost to investment fraud. The FTC’s recovery-fraud guidance likewise warns about unsolicited contact, upfront fees, guarantees, and requests for financial information. Those sources do not prove every forgotten-password specialist is fraudulent, but their red flags belong in your review.

Ask these questions in writing:

What exact wallet formats and versions do you support, and how do you verify a match before receiving secret material?
Can you work from a documented reduced extract that cannot spend funds by itself, and what identifying or correlation data does it still expose? Otherwise, can I retain one indispensable half of the unlock set?
Will any wallet file, candidate list, key, log, or backup enter cloud storage, remote support software, subcontractor systems, or an AI provider?
How are fees calculated, what is payable before a result, and what does “success” mean in the contract?
Who controls the recovered keys before funds move, and can I direct the first transfer to a fresh wallet I prepared?
What deletion, retention, incident-response, and liability terms are written into the agreement?
Can you show a stable legal identity, technical method, and independent history without relying only on testimonials?

Reject guarantees that ignore wallet condition and password unpredictability. Treat unsolicited outreach, pressure, remote-access demands, and requests for both the wallet and its likely password as high-risk signals. Even a competent provider cannot recover a secret that is outside any feasible search space.

Bottom line: choose by failure type and secret boundary
#

Choose by failure type, then by secret boundary. Use provider recovery for a custodial login, a format-matched checker for a local wallet, and AI only for non-secret planning.

Use BTCRecover when the wallet format is supported and memory can be encoded as whole guesses or fragments. Consider Hashcat when you already have a verified supported mode and understand what its extracted data contains. Keep the combined validation offline.

If you cannot identify the wallet, preserve the media and search backups before guessing. If a hosted model would receive real wallet material or actual candidate strings, stop. If a service would receive every indispensable part, treat it as full key custody and redesign or accept that risk explicitly. A truly random password with no useful constraint may remain infeasible regardless of hardware or AI.

Frequently asked questions
#

AI helps only when remembered evidence keeps the candidate space finite. BTCRecover cannot reset a wallet, BIP39 passphrases require a known target, and any successful unlock should lead to a fresh wallet.

Can AI recover a forgotten Bitcoin wallet password?
#

Sometimes AI can help recover the context needed for a feasible search: old file locations, password structure, typo habits, and correct tool options. It cannot derive a random, hard-to-guess password from the wallet or bypass its encryption. Fixed software must still test a candidate that is actually correct.

Can BTCRecover brute-force any Bitcoin password?
#

No. BTCRecover supports many wallet formats and can generate candidates efficiently, but practical success depends on the correct wallet material, a supported format, a valid target, and a search space small enough to finish. Tool support is not a guarantee.

Is a BIP39 passphrase the same as a wallet password?
#

No. A wallet password commonly decrypts stored key material. A BIP39 passphrase combines with the mnemonic to derive a seed, and every passphrase derives a valid—but usually different—wallet. Recovery needs the exact mnemonic and a known target, all handled offline.

Is it safe to give a recovery service my `wallet.dat` file?
#

An encrypted wallet file is still sensitive. Bitcoin Core documents that its encryption protects private keys, not every database field; transaction information remains visible. Prefer a reduced extract only when official documentation says it cannot spend funds alone, and treat the extract as privacy-sensitive. If a provider requires the complete unlock set, treat that as full key custody.

What should I do immediately after recovering access?
#

Prepare and verify a fresh wallet on trusted equipment, then move the funds after checking the destination and fee. Assume old computers, candidate files, logs, and any third party involved may have expanded exposure. Do not keep using the recovered setup merely because it opened once.

Cora Aegis

Cora Aegis is the named pseudonym behind CypherpunkGuide, writing privacy-first self-custody guides grounded in primary sources and reproducible synthetic tests.

More about Cora →

Sources and archives
#

These claims rely on official software documentation, specifications, government fraud guidance, and one scoped news report. The originals were checked on 2026-08-21 or 2026-08-23; all 12 exact Wayback replays below returned HTTP 200 on 2026-08-23.

#	Source	Original URL	Archived
1	Bitcoin Core, “Managing the Wallet”	https://github.com/bitcoin/bitcoin/blob/bf8402c8803f085a50df96cb7956033cd252e9ab/doc/managing-wallets.md	Wayback
2	BTCRecover repository and README	https://github.com/3rdIteration/btcrecover/tree/1457088acf17630eb12a5b53989982ac34e55f2a	Wayback
3	BTCRecover Password Recovery Quickstart	https://github.com/3rdIteration/btcrecover/blob/1457088acf17630eb12a5b53989982ac34e55f2a/docs/TUTORIAL.md	Wayback
4	BTCRecover AI-Assisted Recovery	https://github.com/3rdIteration/btcrecover/blob/1457088acf17630eb12a5b53989982ac34e55f2a/docs/AI_Assisted_Recovery.md	Wayback
5	BTCRecover `SKILL.md`	https://github.com/3rdIteration/btcrecover/blob/1457088acf17630eb12a5b53989982ac34e55f2a/SKILL.md	Wayback
6	BTCRecover Performance Benchmarks and raw result	https://github.com/3rdIteration/btcrecover/blob/1457088acf17630eb12a5b53989982ac34e55f2a/benchmark-results/benchmark_9e6d7d9006b08e8e_20260704_154622.json	Wayback
7	Hashcat example hashes and wallet modes	https://hashcat.net/wiki/doku.php?id=example_hashes	Wayback
8	BIP39, Mnemonic code for generating deterministic keys	https://github.com/bitcoin/bips/blob/7fe0b034ec967b52a5a28276419117326df93263/bip-0039.mediawiki	Wayback
9	FBI/IC3, cryptocurrency recovery-scheme warning	https://www.ic3.gov/PSA/2023/psa230811	Wayback
10	FTC, Refund and Recovery Scams	https://consumer.ftc.gov/articles/refund-and-recovery-scams	Wayback
11	CoinDesk, reported Claude-assisted 2026 wallet recovery	https://www.coindesk.com/tech/2026/05/14/claude-helps-recover-usd395-000-in-bitcoin-trapped-on-a-computer-for-years	Wayback
12	Bitcoin Core wallet encryption source	https://github.com/bitcoin/bitcoin/blob/bf8402c8803f085a50df96cb7956033cd252e9ab/src/wallet/wallet.cpp	Wayback

Methodology — how KYC Drift records hosted-AI claims

Tue, 14 Jul 2026 00:00:00 +0000

Pilot status: Evidence-backed pilot: 44 current facts across 8 services; 44 provider-stated and 0 interface-observed. 45 of 136 service-by-dimension cells contain at least one current scoped record; this is not full coverage of every region, plan, or platform.

Disclosures: nature of this page · affiliations · corrections

This page is a factual record — not advice, not a recommendation, not a solicitation, not an endorsement. Inclusion is not approval. Policies change; check the provider's primary documents before you rely on any value.
We currently have no affiliate relationship with any listed service. If that ever changes, we will disclose it inline, it will not affect what is listed or how it is ordered, and the change will be recorded here.
Listed provider and believe a value is wrong? If our review confirms an error, we correct it and record the correction publicly — write to editor@cypherpunkguide.com
How this data is collected and checked (methodology)

Current pilot status
#

This is an evidence-backed pilot, not a complete market audit. It contains 44 current fact observations across eight hosted-AI services. All 44 are provider-stated and zero are interface-observed. The comparison defines 17 dimensions, producing 136 possible service-by-dimension fields. Of those, 45 fields contain at least one current scoped record; 91 contain no current scoped record. These are inventory counts, not a completeness percentage or a claim that every scope was studied.

What this dataset records
#

The basic unit is an atomic fact observation for one service, attribute, lifecycle stage, and applicable scope. Lifecycle stages are registration, continued use, payment, recovery, and deletion. An observation can record the provider’s stated requirement, how information is collected or checked, what it becomes linked to, its recipient, the region, plan, platform, or signup method to which it applies, its dates, and supporting evidence.

Starting July 26, 2026, the dataset is append-only. A policy change adds a new observation that explicitly supersedes the earlier one; a correction points to the observation it corrects. The initial 44 records form a legacy baseline, and we do not claim that they preserve a complete pre-boundary change history. Current comparison views are derived from the history; they do not replace it.

What it deliberately does not measure
#

Network anonymity. IP addresses, device fingerprinting, Tor/VPN treatment, and site analytics are a separate layer. A provider’s published network-data claim may be recorded under a separate label, but no cell establishes that a user is anonymous on the wire.
Payment-intermediary exposure. A provider may state that it accepts a payment method; what an intermediary learns about the payer remains outside this dataset.
Legal-process access. We can record the provider’s stated entity and jurisdiction. We do not turn that into a claim about what a court order or national-security process can reach.
Backend enforcement. A policy can show what a provider published. It cannot demonstrate that the product or backend followed those words.

Where values come from
#

Provider documents and controlled interface runs are parallel evidence roles, not ranks in one source hierarchy:

Provider documents answer what a provider published in its policies, terms, or help material. A provider-stated fact is limited to the document’s wording and scope.
Controlled interface runs answer what one defined product path did under recorded conditions such as date, region, plan, platform, and signup method. An interface-observed fact requires a retained run artifact whose digest is bound into the release manifest. It does not generalize beyond that run’s scope.
Provider support, archived interface copies, and third-party reports can identify questions or corroborate a record, but they do not become a displayed value unless registered as qualifying evidence in the appropriate role.

Neither role silently overrides the other. Under the current P0 release path—the first implementation stage—a disagreement within comparable scope defers that release. Provider and interface evidence remain in separate streams for adjudication, but P0 does not publish a new conflicting state. Once P1 implements an append-only structured conflict relation, the two records can be published side by side without either overwriting the other. The current pilot is provider-only: it contains provider documents and zero controlled interface-run facts.

Collection and requirement are also kept separate. A privacy policy saying that a provider may collect a phone number does not establish that registration requires one. A provider-stated value is marked required only when the provider’s own material uses mandatory language. An interface-observed value is marked required only when the controlled run shows that its defined flow cannot proceed without it.

Controlled vocabulary and blank-zero rule
#

Cells use a controlled vocabulary, including required · optional · conditional · available · collected-if-provided · may-collect · not-assessed · conflicting · region-dependent · plan-dependent · not-applicable.

not-assessed means there is no current scoped record for the service and dimension shown.
conflicting is reserved and unused in the current pilot. P0 rejects a new conflicting value and defers release when evidence disagrees within comparable scope. The value can be used after P1 implements an append-only structured conflict relation that can bind both records without overwriting either one.
not-disclosed is reserved and unused in the current pilot. It would require a registered assessment of a defined document corpus; absence from the facts collected so far is not enough.

No cell is left blank. Silence in a document and absence from our research are different states, and neither is evidence that a requirement does not exist.

Evidence, dates, and integrity
#

For provider documents:

Archive-first. Provider pages are captured through web archives. The archived copy, not a fresh direct request from our infrastructure, is the cited record.
Content check. A capture counts as current supporting evidence only when every quote used by its current facts remains present in the decoded archived body. The source capture and the latest supporting re-check are displayed separately.
What sha256 does. The sha256 value fingerprints the decoded archived body. It lets us compare a retained copy and detect a change in bytes. It does not prove when those bytes existed.
Where capture time comes from. The capture date comes from the Wayback record. Cryptographic timestamping is not yet implemented, so existing captures must not be described as carrying a capture-time cryptographic proof.
Quotes and retention. Short sanitized excerpts remain in the source language. Relied-upon bodies are retained locally so a broken archive link does not erase the record.

For controlled interface runs, the evidence record must state the run conditions and result, retain the designated artifact under the repository-controlled interface-run path, and bind that artifact’s digest into the release manifest. Document archives and interface artifacts therefore have different integrity checks and remain separate evidence streams.

A date is labeled effective date only when the provider explicitly states that the policy or term takes effect then. A page’s “last updated” date is a document date, not an effective date. A capture date or observation date is never promoted silently into either one.

Claim source, integrity, enforcement, freshness, and conflict
#

These are separate labels because they answer different questions:

Claim source identifies whether a value is provider-stated or interface-observed.
Evidence integrity reports the applicable document-archive or interface-artifact checks.
Enforcement remains untested unless a separate controlled test supports it. Archived policy text never earns that label by itself.
Fact checked-through follows every evidence stream cited by the fact to its current supporting successor, then uses the oldest latest-check date across those streams.
Dataset checked-through is the oldest checked-through date among current facts. A partial refresh therefore cannot advance the date for the whole pilot.
Conflict is a reserved display label. The current pilot publishes no such state; a comparable-scope disagreement instead defers the P0 release until P1 implements a structured conflict relation that can bind both records.

None of these labels is a composite confidence score.

Drift, corrections, and disputes
#

A policy change is dated only as precisely as the evidence permits. A snapshot date is not silently promoted into an effective date. Editors do not make a disagreement disappear by choosing one source: P0 defers the release while the evidence remains in separate streams. After P1 implements the append-only structured conflict relation, both records can remain publicly visible side by side.

Errors in this dataset are corrected publicly. A provider or reader can write to editor@cypherpunkguide.com. We normally aim to acknowledge a dispute within 14 days and mark the affected value while it is reviewed. That is an operating target dependent on the monitored correction channel, not a guaranteed response time.

Update target and current limit
#

The intended operating cadence is a monthly re-check of the source set followed by human adjudication of detected changes. That cadence is not yet an active SLA. It becomes a service commitment only after the capture, validation, diff, adjudication, and release pipeline completes two consecutive production-equivalent cycles with every gate GREEN and an observable heartbeat. Until then, updates and corrections are manual. The displayed checked-through dates remain the authoritative freshness boundaries.

Why there are no scores
#

A composite privacy score would embed one threat model in every reader’s decision. A phone requirement, downstream routing, account linkage, and retention period are not interchangeable units. KYC Drift therefore publishes facts, dates, scopes, missing fields, and sources without turning them into a quality order or recommendation. Once P1 implements structured conflict relations, unresolved disagreements can also be published as parallel records; the current pilot publishes none.

Selection and licensing
#

The current eight services form a convenience pilot selected because at least one content-verified primary provider source was available for each without creating an account. The set is neither exhaustive nor representative of the whole hosted-AI market. Metadata and annotations are licensed under CC BY 4.0; quoted provider text remains the provider’s. The machine-readable export is available at /en/data/kyc-drift/index.json.

Cite as: Cora Aegis, “KYC Drift: Hosted AI Identity & Data Practices — Pilot” (v2026.07), https://cypherpunkguide.com/en/data/kyc-drift/, CC BY 4.0

Bitcoin Custody Under Coercion: A Survivor's Guide 2026

Mon, 29 Jun 2026 00:00:00 +0000

If you are in danger, your safety comes before any of this. Reading this page can leave a trace on a shared or monitored device. Open it from a device the person you fear cannot reach, and speak with a domestic-violence advocate before you change anything. Sudden changes to shared accounts, devices, or money can alert an abuser — and the period around leaving is the most dangerous (WomensLaw). In the US you can reach the National DV Hotline at 1-800-799-7233; elsewhere, search for a local advocate. Nothing here replaces a safety plan made with a trained person.

Almost every guide to holding your own Bitcoin pictures the same enemy: a hacker somewhere far away, trying to reach across the internet for your keys. So the advice is built for distance — a hardware wallet, a seed phrase written down, a strong PIN. It quietly assumes you are alone in a room no one else controls.

For a great many people that assumption is false, and the gap is widest exactly where the stakes are highest. Economic abuse — a partner controlling, sabotaging, or seizing your money — affects roughly 15% of women, and women experiencing food insecurity are more than four times as likely to face it (Mellar et al., 2024). Self-custody is sold as financial independence, yet the standard playbook never names the adversary who shares your bed, knows your passcode, and can simply demand that you unlock the wallet. (Physical coercion is not a fringe concern even outside the home: recorded physical attacks on Bitcoin holders rose 169% in 2025 — CNBC, citing Jameson Lopp’s database of reported incidents.)

So what changes when the threat lives with you? We read the major self-custody guides and the leading domestic-violence digital-safety resources side by side, and found they almost never meet. This article tries to close that gap — not with a tidy checklist, but with a way to think: an adversary-capability model that starts from what the person near you can actually do, and a staged plan that puts your physical safety ahead of any wallet setting.

We write as privacy researchers, not as survivors or advocates. What follows is a threat model and a set of options, not a prescription — following the trauma-informed principle of offering choices rather than directives (SAMHSA). You know your situation better than any guide can, and some of the “clever” tricks circulating in Bitcoin communities can get someone hurt. We flag those plainly.

Why standard custody advice fails when the threat lives at home
#

Standard Bitcoin custody guidance is built around a remote adversary and a physically secure user. Its core moves — keep the seed phrase off the internet, use a hardware wallet, set a PIN — all assume nobody trustworthy-looking is watching you type, holding your phone, or able to apply pressure in person. Intimate partner abuse breaks every one of those assumptions at once, which is why “just use a hardware wallet” can be not only unhelpful but unsafe.

The mismatch is structural, not a matter of one missing tip. Mainstream custody resources optimize against theft (someone takes your keys without your cooperation). Abuse-aware safety planning optimizes against control and coercion (someone makes you act against your own interest, then punishes deviation). A hardware wallet defeats the first and can worsen the second: a visible new device is a question you may not be safe answering.

There is also a quieter failure. Domestic-violence advocates organize their advice around the abuser’s access and leverage; Bitcoin guides organize theirs around tools and procedures. Bridging them means translating “what can the person near me do?” into concrete custody and privacy choices — which is the rest of this article.

The adversary-capability matrix
#

Instead of asking “am I a woman / a creator / an activist?”, ask what the person who threatens you can actually do. This is the single most useful shift, because the same defenses map cleanly onto capabilities, and most real situations are a mix of a few. The matrix below is our framing; the defenses are summarized here and expanded in later sections.

Adversary capability	What it means	First-order defense	Honest limit
1. Physical device access	They can pick up your phone/laptop, or it is shared	Separate device they cannot reach; screen-lock hygiene	A device they have touched may already be compromised
2. They know your PIN/passcode	Shoulder-surfed, demanded, or shared earlier	A new device with a PIN they do not know	Changing a known PIN — or disabling biometrics — is itself a visible act, and a fingerprint or face can be physically compelled
3. They can force a signature	Violence or threats to make you send funds	Time-delays; not keeping large sums reachable on demand	Cryptography cannot stop a wrench (the “$5 wrench attack”)
4. They track your location	Stalkerware, shared accounts, AirTags	Treat phone as monitored; out-of-band help	Finding a tracker can escalate danger
5. They read your cloud/email/2FA	Shared iCloud/Google, SIM access	New accounts on a safe device, app-based 2FA	Account changes may notify the other party
6. They can dox or expose you	Threats to publish where you went	On-chain and address privacy; redaction	Public ledger history is hard to undo

The point of the matrix is sequencing. Capabilities 1, 2, 4, and 5 are not Bitcoin problems — they are device-and-account problems that exist before any wallet. If the phone in your pocket is monitored, the most carefully chosen hardware wallet is irrelevant: whatever you set up is seen as you set it up. That is why the order of operations matters more than the choice of wallet, and why the next section comes before any custody advice.

Before Bitcoin: secure the device and the plan first
#

Before touching a wallet, establish a device and a safety plan the other person does not control — because every later step assumes a private surface to act on. Stalkerware — apps that silently relay location, messages, photos, and calls — is widespread and built to be hard to spot; the Coalition Against Stalkerware and NNEDV’s Safety Net project document its routine use in abuse — 97% of domestic-violence programs report that abusers misuse technology to stalk, harass, and control (NNEDV Safety Net survey, 2014). If your device might be monitored, assume that anything you do on it is visible.

Crucially, do not rush to “clean” a suspected device. DV advocates warn that removing spyware or a tracker can tip off an abuser and escalate the danger (NNEDV Safety Net). The safer pattern is usually to leave the monitored device behaving normally and move sensitive activity to a separate device the other person cannot access — bought, set up, and kept out of reach.

A practical first sequence, if you suspect monitoring:

Pause. Do nothing abrupt on the suspect device. Behaving differently is itself a signal.
Get a separate surface. A cheap phone — or a friend’s device, but only someone you are certain the other person does not contact or monitor — with a new email and an app-based authenticator, not SMS (which can be intercepted via a shared phone plan).
Reach help out-of-band. Contact an advocate from the safe device or in person, not over channels the other party may read.
Plan before you change anything reachable. Especially money: a sudden transfer from a watched account can be the trigger, not the escape.

Only once you have a surface the other person does not control does the rest of this guide become safe to act on. Our broader work on how monitoring tools see you and age-verification and vulnerable users covers the device and data side in more depth.

Custody choices under coercion — and their honest limits
#

Under coercion, the goal of custody design shifts from “keep thieves out” to “limit what can be taken from you under pressure without putting you in greater danger” — and several popular tricks fail that second test. Self-custody’s hardest truth here is blunt: keeping your keys perfectly does not help if you can be forced to sign. This is the well-known “$5 wrench attack,” and it means custody choices must be judged by what happens to you, not only to your coins.

Below are the options most often suggested, with their real limits in an abuse context. None of these is a recommendation; each is a trade-off that can go wrong.

Option	The idea	The honest danger in coercion
Decoy / duress wallet	Show a small “real” balance to satisfy a demand	If suspected or discovered, the lie can trigger worse violence. There is no published DV research validating decoys as safe; advocates warn any noticed deviation can escalate. Treat as high-risk, not clever.
Hidden passphrase (an extra secret word on top of your seed phrase — the BIP-39 “25th word”)	One seed, two wallets; the hidden one is plausibly deniable	Technically real (BIP-39), but a forgotten passphrase means permanent loss, and under interrogation deniability can fail. Recoverability and duress risk both rise.
Time-delayed / multisig spend	A delay or extra key gives a window to cancel a coerced transaction	The delay only helps if cancelling later is safe. If the other person is present and watching, a cancelled transaction is a noticed deviation.
Multisig with a trusted third party	Split keys so no single device holds funds	A hallmark of abuse is isolation — cutting victims off from friends and family (NCDV). The “trusted person” may not exist, may be pressured, or contact with them may itself be dangerous.

Two principles cut across all of these. First, deception-based defenses are the most dangerous in coercion, because their failure mode is physical retaliation, not lost coins. Second, secrecy fights recoverability: an estimated 11–18% of all Bitcoin is already lost to forgotten keys and missing plans (Chainalysis estimate, via CryptoSlate), and stacking hidden passphrases on geographically split backups can lock you out as easily as anyone else. A plan you cannot safely use is not a plan.

If your situation is “I need to move funds out before I leave,” the cleaner approach is usually not a clever wallet but a new wallet on a safe device, funded deliberately — see acquiring coins privately in buying Bitcoin without KYC (KYC means the identity verification exchanges require), with the caveats below about the public ledger.

Bitcoin’s public ledger is its own exposure
#

Beyond keys and devices, Bitcoin carries a privacy risk most newcomers miss: the ledger is public and permanent, so payments can be linked back to you long after they happen. Reusing the same address ties all of its transactions together, and connecting any of them to a KYC exchange withdrawal can attach your real name and address to that history (Bitcoin Wiki: Privacy; Coldcard). For someone trying to leave without being traced, this is not abstract — a withdrawal address handed to an abuser, or recovered from a shared account, can become a tracking handle.

The exposure is broader than addresses. Lightning (Bitcoin’s instant-payment layer) invoices can reveal the recipient’s node public key — a persistent identifier an attacker can search to help identify you (Casa). Shipping addresses for hardware, PO boxes, and exchange accounts under a shared identity all leak in the same way. The defensive moves — fresh addresses, avoiding address reuse, careful separation of KYC and non-KYC coins — are real but come with genuine friction: fees, jurisdiction limits, and a learning curve that is unfair to demand of someone already in crisis. We cover the mechanics in Bitcoin on-chain privacy; here the takeaway is narrower: assume anything you put on-chain may be linked to you, and keep the wallet you rely on for safety separate from any address the other person has ever seen.

A staged response: match the move to the moment
#

Because the right action depends entirely on how acute the danger is, match your moves to the stage you are in rather than doing everything at once. The most common mistake we see in technical advice is treating this as a one-time setup; in coercion it is a sequence, and doing the “right” technical step at the wrong moment can be the trigger.

Stage	Priority	Bitcoin-specific move
Immediate danger	Physical safety, not technology. Contact a hotline/advocate; do not make noticed changes	None. A transfer now can escalate, not protect
Device feels monitored	Get a separate, private device; leave the watched one normal	Set up any new wallet only on the safe device
Planning to leave	Quiet preparation; documents, money, route — leaving is highest-risk	Fund a new wallet the other person has never seen; keep amounts unremarkable
After separation	Address and location privacy; account recovery hygiene	Fresh addresses; sever links to shared accounts and old withdrawal history

This staging reflects the core finding from DV safety planning: safety comes from a plan, not from any single tool, and the moment of leaving carries the highest risk of lethal violence (WomensLaw). Bitcoin can be part of that plan — money an abuser cannot freeze through a bank can matter — but it sits inside the safety plan, never ahead of it.

When Bitcoin isn’t the answer
#

Self-custody is one option among several, and honesty requires saying that it is often not the best one for someone in crisis. Bitcoin’s strengths — censorship-resistance, no bank able to freeze or report your account — are real, but they come with a steep tax: high technical knowledge, irreversible mistakes, and a public ledger. For someone managing acute danger, that friction can itself be a hazard.

The honest comparison is situational, and we have found no published analysis weighing these specifically for abuse survivors, so treat this as a starting frame, not a verdict:

Cash is the hardest to trace and needs no device, but it cannot be hidden in unlimited amounts and can be physically found or taken.
Prepaid cards sidestep some bank monitoring and identity linkage, at the cost of fees and limits.
A separate bank account is traceable and freezable, but accessible, reversible on error, and familiar.
Bitcoin self-custody resists freezing and seizure, but demands skill, leaks on a public ledger, and is unforgiving of mistakes.

The right mix depends on the amount, how closely you are watched, your comfort with the tools, and whether you have somewhere safe to keep a backup. If you are weighing this, weigh it with an advocate, not from a guide alone.

Bottom Line — build a plan that fits your risk
#

There is no single correct custody setup for living under coercion, only choices that fit your specific danger. The throughline of everything above is that the device and the safety plan come first, and the wallet serves them — never the reverse. Bitcoin can give someone leverage an abuser cannot quietly revoke, but only if the setup survives an adversary who is already inside your trust, your home, and sometimes your phone.

Key Takeaways

Threat model: Standard custody advice assumes a remote hacker; under intimate partner abuse the adversary has physical access, may know your PIN, and can force a signature — a different problem entirely.
Sequence: Secure a private device and a safety plan before any wallet; an estimated 97% of DV programs report abusers misusing technology to monitor and control.
Deception is dangerous: Decoy and duress wallets have no published DV-safety validation; if discovered they can escalate violence. Treat them as high-risk, not clever.
Public ledger: Address reuse plus a KYC withdrawal can deanonymize your history; keep any safety wallet separate from addresses the other person has seen.
Bitcoin isn’t always the answer: Cash, prepaid cards, and bank accounts each trade off traceability against accessibility — decide with an advocate, not from a guide.

Frequently asked questions
#

Can a hardware wallet protect me if my partner watches me use it?
#

Only partially. A hardware wallet protects keys from a remote attacker, but if someone can watch you enter your PIN, hold the device, or pressure you to sign, the wallet’s protections are bypassed. In that situation the device-and-access problem (capabilities 1–3 in the matrix above) matters more than the wallet model. Secure a private device first.

Is a decoy or “duress” wallet safe to use under coercion?
#

We do not recommend it as a safety measure. The idea — show a small balance to satisfy a demand — assumes the deception holds. In abuse, a noticed or discovered lie can trigger worse violence, and there is no published domestic-violence research validating decoys as safe under coercion. DV safety planning warns that any change an abuser notices can escalate danger. Treat it as a high-risk option, not a clever trick.

Should I name a friend or family member in a multisig?
#

Be cautious. Collaborative custody (splitting keys so no single device holds funds) is sound in general, but it assumes a trustworthy, reachable third party. A defining tactic of abuse is isolation — cutting you off from exactly those people — so the “trusted person” may not exist, may be pressured, or contact with them may itself be unsafe. If you use one, choose someone the other person cannot reach or influence.

What should I do first if I think my device is monitored?
#

Do not abruptly wipe or “clean” it — that can alert the other person. Leave it behaving normally, move sensitive activity to a separate device they cannot access (with a new email and app-based 2FA), and reach a domestic-violence advocate out-of-band before changing anything reachable, especially money.

Is Bitcoin better than a bank account for leaving safely?
#

Not necessarily. Bitcoin resists freezing and seizure, which can matter, but it demands technical skill, is unforgiving of mistakes, and records payments on a public ledger. For many people in crisis, a mix — some cash, a prepaid card, a separate bank account, and only a small, carefully kept Bitcoin wallet — is safer than relying on self-custody alone. Decide with an advocate who knows your situation.

References
#

#	Source	URL	Archived
1	Mellar et al., economic abuse and health (2024)	https://pmc.ncbi.nlm.nih.gov/articles/PMC11465629/	https://web.archive.org/web/20260613075557/https://pmc.ncbi.nlm.nih.gov/articles/PMC11465629/
2	Coalition Against Stalkerware	https://stopstalkerware.org/	https://web.archive.org/web/20260623120558/https://stopstalkerware.org/
3	NNEDV Safety Net — resources for survivors	https://www.techsafety.org/resources-survivors	https://web.archive.org/web/20260628175219/https://www.techsafety.org/resources-survivors
4	WomensLaw — safety planning	https://www.womenslaw.org/safety-planning	https://web.archive.org/web/20260505163930/https://www.womenslaw.org/safety-planning
5	NCDV — isolation tactics in domestic abuse	https://www.ncdv.org.uk/isolation-tactics-how-victims-of-domestic-abuse-fall-into-the-trap/	https://web.archive.org/web/20260218092206/https://www.ncdv.org.uk/isolation-tactics-how-victims-of-domestic-abuse-fall-into-the-trap/
6	Bitcoin Wiki — Privacy	https://en.bitcoin.it/wiki/Privacy	https://web.archive.org/web/20260616215546/https://en.bitcoin.it/wiki/Privacy
7	Coldcard — address reuse	https://coldcard.com/learn/transaction-security/bitcoin-address-reuse	https://web.archive.org/web/20260629074529/https://coldcard.com/learn/transaction-security/bitcoin-address-reuse
8	Casa — Lightning privacy 101	https://blog.casa.io/lightning-privacy-101/	https://web.archive.org/web/20260314173520/https://blog.casa.io/lightning-privacy-101/
9	CNBC — physical attacks on Bitcoin holders (2025)	https://www.cnbc.com/2025/04/06/bitcoin-self-custody-crypto-risks.html	https://web.archive.org/web/20260313145505/https://www.cnbc.com/2025/04/06/bitcoin-self-custody-crypto-risks.html
10	SAMHSA — trauma-informed approach	https://www.samhsa.gov/mental-health/trauma-violence/trauma-informed-approaches-programs	https://web.archive.org/web/20260508115444/https://www.samhsa.gov/mental-health/trauma-violence/trauma-informed-approaches-programs

Cora Aegis

Privacy and self-custody writer focused on the threat models mainstream guides leave out — here, the gap between Bitcoin custody advice and domestic-violence digital safety. Writes as a researcher, not a survivor or advocate, under a consistent pseudonym by choice and on principle.

More about Cora →

What Is the Cypherpunk Manifesto? A 2026 Primer

Sun, 28 Jun 2026 00:00:00 +0000

This site is named for a movement, and the movement is named for a document. Before there was a privacy-tools industry, before Bitcoin, before the word “cypherpunk” appeared in a headline, a small mailing list of cryptographers in the San Francisco Bay Area decided that privacy was not something you could wait to be given. In March 1993 one of them, Eric Hughes, wrote it down in under a thousand words.

That essay — A Cypherpunk’s Manifesto — is still the clearest statement of why privacy work exists, and most explainers flatten it into a historical footnote on the road to Bitcoin. That reading misses the point. We re-read the manifesto line by line against the surveillance landscape we document on this site every week — AI-scale correlation, undeletable footprints, identity checkpoints at the door of the open web — and found that it does not read like nostalgia. It reads like a specification that 2026 is still failing to meet.

So what does the manifesto actually say, who wrote it, and which of its claims survived three decades of contact with reality? Below is the primer: the text, the people, and an honest scorecard of its predictions — including the one woman whose name belongs at the front of the story and is almost always left out.

What the Cypherpunk Manifesto Actually Says
#

The Cypherpunk Manifesto is a 1993 essay by Eric Hughes arguing that privacy is necessary for an open society in the electronic age, that it will not be granted by institutions, and that it must therefore be built directly with cryptography. Published to the cypherpunks mailing list on 9 March 1993, it is short, declarative, and structured as a chain of claims rather than a call for legislation. Its force comes from refusing to treat privacy as a favor.

It opens by separating two ideas that are still routinely confused:

“Privacy is not secrecy. A private matter is something one doesn’t want the whole world to know, but a secret matter is something one doesn’t want anybody to know. Privacy is the power to selectively reveal oneself to the world.” — Eric Hughes, A Cypherpunk’s Manifesto, 1993

That distinction does the heavy lifting. If privacy were secrecy, demanding it would look like hiding something. By defining privacy as selective disclosure — the power to choose what you reveal, to whom — Hughes reframes it as a precondition for participating in society on your own terms, not a refuge for wrongdoing. The example he uses is mundane on purpose: paying cash for a magazine, where the merchant has no need to know who you are.

From there the manifesto makes its central political claim, the one that separates cypherpunk thinking from ordinary privacy advocacy: you cannot petition your way to privacy. “We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy out of their beneficence,” Hughes wrote. Privacy that depends on an institution’s goodwill is privacy that the institution can revoke. The conclusion is therefore not a policy ask but an engineering mandate — privacy in an open society requires anonymous transaction systems, and if such systems do not exist, the people who care must build them. The famous line is the whole ethic compressed: “Cypherpunks write code.”

This is why the manifesto still matters as more than history. It is not a complaint about surveillance; it is a design principle. It says that durable privacy is a property of mechanisms — math you can verify — rather than promises you have to trust. Every honest privacy tool since has been an attempt to honor that principle or an illustration of what happens when it is ignored.

Three Texts, One Idea: May, Hughes, and Chaum
#

The Cypherpunk Manifesto did not appear from nothing — it crystallized ideas already moving through three foundational texts: David Chaum’s academic work on untraceable payments (1985), Tim May’s Crypto Anarchist Manifesto (written 1988), and Hughes’ essay (1993), bound together by the cypherpunks mailing list that Hughes, May, and John Gilmore founded in late 1992. Reading the three together shows the manifesto was the activist distillation of a decade of cryptographic thought.

The intellectual groundwork was Chaum’s. As an academic cryptographer, he had shown that privacy and accountability were not opposites — that you could build payment and credential systems revealing nothing beyond what a transaction strictly required. His 1985 Communications of the ACM paper carried a title that reads like a thesis statement for the whole movement: Security Without Identification: Transaction Systems to Make Big Brother Obsolete. He spent the following years trying to ship it, founding the company DigiCash to bring an “ecash” system to market before it filed for bankruptcy in 1998 — a first, instructive lesson that the hard part was never only the math.

Where Chaum was the engineer and Hughes the organizer, Tim May was the provocateur. His Crypto Anarchist Manifesto, written in 1988 and circulated to the early cypherpunks in 1992, opened with deliberate menace: “A specter is haunting the modern world, the specter of crypto anarchy.” May’s contribution, and his warning, was that strong cryptography would enable fully anonymous systems whether society was ready or not — and he was candid that this cut both ways, predicting illicit markets alongside the liberation. An honest primer keeps that ambivalence in view rather than sanding it off.

Founding text	Author	Year	Core claim
Security Without Identification	David Chaum	1985	Transactions can be secure without identifying the participants
The Crypto Anarchist Manifesto	Tim May	1988 (circulated 1992)	Cryptography will enable anonymous systems regardless of law
A Cypherpunk’s Manifesto	Eric Hughes	1993	Privacy must be built with code, not requested from institutions

What turned three texts into a movement was the mailing list. Beginning in late 1992, the cypherpunks met monthly in the Bay Area and argued in public over a list that, by the late 1990s, ran to thousands of subscribers. The manifesto was its founding document not because it was the first idea but because it was the clearest instruction.

The Woman Who Named It: Jude Milhon
#

The term “cypherpunk” was coined by Jude Milhon — a writer and self-taught programmer who went by the handle “St. Jude” — as a pun blending “cipher” with “cyberpunk,” and her authorship of the movement’s name is the detail most histories reduce to a footnote. Restoring it is not trivia. It corrects a record that has quietly written a woman out of the founding of a movement about who gets to control information.

Milhon (1939–2003) was not a peripheral figure who happened to land a good pun. She had been a programmer since the 1960s, was part of the Community Memory project — one of the first public computerized bulletin-board systems — and served as a senior editor at the cyberculture magazine Mondo 2000. Her politics were explicit and ahead of their time; her rallying cry, “Girls need modems!”, framed access to technology as a feminist demand decades before “digital divide” entered common usage. When the Bay Area cryptographers needed a name, it was Milhon who supplied the one that stuck.

We surface this for a reason beyond accuracy. The cypherpunk ideal — that privacy is a precondition for autonomy — lands hardest on the people most exposed when it fails, and that population is not gender-neutral. The threat surfaces we cover most closely, from synthetic-identity abuse in OPSEC in the AI Age to the intimate-partner surveillance embedded in age-verification mandates, fall disproportionately on women and on anyone with a motivated, close-range adversary. A movement that a woman named, read through 2026, points directly at the harms a male-coded “lone actor” threat model tends to miss. Milhon belongs in the primer, not the footnotes.

Scoring the 1993 Predictions Against 2026
#

Read as a set of predictions, the manifesto is uncomfortably accurate: its claim that institutions would not grant privacy, that surveillance would scale, and that only built-in mechanisms would hold has been confirmed repeatedly — while one prediction from its sibling text, Tim May’s, inverted into something its authors did not foresee. This is the part worth dwelling on, because the manifesto’s value today is as a scorecard, not a relic.

We built the table below by mapping each core claim onto a threat we document elsewhere on this site — not onto headlines. Where the original is a 1993 sentence, the 2026 column is a mechanism we have actually traced.

Manifesto claim (1993)	2026 reality	Verdict
Institutions won’t grant privacy “out of their beneficence”	Platforms’ “delete” is a display change, not erasure; copies persist in brokers, caches, and model weights	✅ Confirmed
Surveillance would outpace manual limits	AI joins scattered fragments into profiles at a scale no human investigator could reach	✅ Confirmed
Privacy requires anonymous transaction systems	Identity checkpoints are being mandated at the door of ordinary services, the opposite of anonymous access	✅ Confirmed (by its violation)
Reputation would be “central” in anonymous systems (May, 1988)	Reputation systems exist — but as state- and platform-controlled identity scores (KYC checks, chain-analytics risk ratings), not user-owned	⚠️ Inverted

The first three rows are the manifesto vindicated. Its claim that deletion would not save you is the precise subject of How Permanent Is Your Social Media Footprint: once your words are absorbed into a model’s training data, there is no delete button that reaches the weights. Its claim that surveillance would scale beyond human limits is the entire premise of the AI-age threat model. And its demand for anonymous transaction systems is confirmed, ironically, by the global push for the opposite — the age-verification and digital-ID checkpoints that make the open web conditional on showing your papers.

We can offer one small piece of first-party evidence for the scale claim. We keep this site’s own server logs under watch for the self-identifying AI crawlers — GPTBot, ClaudeBot, PerplexityBot, Google-Extended and their peers — and they arrive continuously, on their own schedule, indexing a privacy site to answer questions about it. The machine readership Hughes could only infer is now measurable in a log file.

The fourth row is the interesting failure. May predicted that in anonymous systems, reputation would become the organizing principle — and he was right that reputation became central, but wrong about who would own it. Instead of user-controlled reputations attached to pseudonyms, 2026 runs on reputation systems controlled from above: KYC scores, transaction-monitoring risk ratings, the chain-analytics heuristics that decide whether your coins are “clean.” The cypherpunks imagined reputation as a tool of individual sovereignty. It arrived as an instrument of institutional control. That inversion — the right mechanism captured by the wrong owner — is the sharpest lesson the manifesto’s predictions hold for anyone building privacy tools now.

“Cypherpunks Write Code”: The Ethic in 2026
#

The manifesto’s most quoted line, “Cypherpunks write code,” is not a slogan about programming but a way of knowing — an epistemics: privacy claims must be verifiable in the mechanism rather than trusted in the promise, which translates today into “verify, don’t trust” and “prefer structure over policy.” Three decades on, that ethic is the most practical thing the document offers a non-programmer.

You do not have to write cryptography to live by it. The cypherpunk test for any privacy claim is to ask where the guarantee lives. A promise in a privacy policy lives in an institution’s goodwill — exactly the kind Hughes said would not hold. A guarantee in open, auditable code or in a protocol with no central operator to compel lives in math and structure. This is why the durable defenses we recommend are almost always structural rather than tactical: choosing a tool whose privacy is a property of its design beats trusting a service that merely says the right things. It is the same reasoning behind treating any government-held database as already breached, the assume-breach posture in When the Government Leaks Your Data.

The ethic also explains why pseudonymity sits at the center of this tradition rather than at its edge. Writing under a consistent name that is not your legal one — as the cypherpunks did on their list, and as this publication does — is not evasion; it is the selective disclosure the manifesto defined as privacy itself. Judged by code and argument rather than by credentials, the work either holds up or it does not. That is the standard the cypherpunks set, and it is a more honest one than authority by identity.

Bottom Line — Why a 1993 Essay Still Sets the Spec
#

The Cypherpunk Manifesto endures because it is a design principle, not a period piece: “privacy must be built, not granted” is a claim each passing year tests and has not yet refuted. Privacy is selective disclosure, not secrecy. It will not be granted, so it has to be built. And the only guarantees that hold are the ones written into mechanisms you can verify rather than institutions you have to trust.

For a reader in 2026, that converts into a way of seeing. When the next identity checkpoint is announced in the name of safety, the manifesto tells you to ask not “do I trust this provider” but “does this design require trust at all.” When a platform offers a privacy setting, it tells you to look for the guarantee in the code, not the copy. The document is thirty years old and reads like it was written about this week — which is either a triumph of foresight or an indictment of how little we have built since. Most honestly, it is both.

Key Takeaways

What it is: A Cypherpunk’s Manifesto is Eric Hughes’ 1993 essay defining privacy as the power to selectively reveal oneself, and arguing it must be built with cryptography rather than requested from institutions.
The founding trio: Chaum’s untraceable-payments work (1985) and May’s Crypto Anarchist Manifesto (1988) set the stage; Hughes’ 1993 essay turned the ideas into an instruction on the cypherpunks mailing list founded in 1992.
The name’s author: Jude Milhon (1939–2003), known as “St. Jude,” coined “cypherpunk” — a woman’s contribution that most histories wrongly relegate to a footnote.
The scorecard: Its predictions that institutions won’t grant privacy, and that surveillance would scale, are confirmed; May’s prediction that reputation would be central inverted into state-controlled KYC scoring.
The usable ethic: “Cypherpunks write code” means verify the mechanism, don’t trust the promise — prefer structural guarantees over policy ones, even if you never write a line of code.

Frequently Asked Questions
#

What is the Cypherpunk Manifesto?
#

It is a short essay written by Eric Hughes and published to the cypherpunks mailing list on 9 March 1993. It argues that privacy is necessary for an open society, that institutions will not grant it voluntarily, and that it must therefore be built directly using cryptography. Its best-known line, “Cypherpunks write code,” compresses the whole argument: privacy has to be engineered into mechanisms, not requested as a favor.

Who wrote the Cypherpunk Manifesto, and who coined the word “cypherpunk”?
#

Eric Hughes wrote the manifesto in 1993. The word “cypherpunk” itself was coined separately by Jude Milhon, a writer and programmer known as “St. Jude,” as a pun on “cipher” and “cyberpunk.” Hughes, Tim May, and John Gilmore founded the cypherpunks mailing list in late 1992, where the manifesto was published.

How is the Cypherpunk Manifesto different from the Crypto Anarchist Manifesto?
#

They are two distinct texts. Tim May’s Crypto Anarchist Manifesto (written 1988) is the more radical, predicting that cryptography would enable anonymous systems beyond the reach of the state, for good and ill. Hughes’ Cypherpunk Manifesto (1993) is more constructive and focused: it defines privacy, insists it must be built rather than granted, and calls on its readers to write the software. May framed the consequence; Hughes framed the duty.

Is the Cypherpunk Manifesto still relevant in 2026?
#

Yes, arguably more than when it was written. Its core predictions — that institutions would not grant privacy and that surveillance would scale beyond human limits — are confirmed daily by AI-scale data correlation, undeletable digital footprints, and mandatory identity checkpoints. Its central instruction, to trust verifiable mechanisms over institutional promises, is a directly usable test for evaluating any privacy tool or law today.

Do I have to be a programmer to be a cypherpunk?
#

No. “Cypherpunks write code” is an ethic, not a job description. For a non-programmer it translates into a habit of mind: ask where a privacy guarantee actually lives. Prefer tools whose privacy is a property of open, auditable design or of a protocol with no central operator to compel, over services that merely promise good behavior in a policy. Choosing structural privacy over policy privacy is practicing the manifesto without writing a line of code.

#	Source	URL	Archive
1	Eric Hughes — A Cypherpunk’s Manifesto (1993)	https://www.activism.net/cypherpunk/manifesto.html	https://web.archive.org/web/*/https://www.activism.net/cypherpunk/manifesto.html
2	A Cypherpunk’s Manifesto — Nakamoto Institute library	https://nakamotoinstitute.org/library/cypherpunk-manifesto/	https://web.archive.org/web/*/https://nakamotoinstitute.org/library/cypherpunk-manifesto/
3	Tim May — The Crypto Anarchist Manifesto	https://www.activism.net/cypherpunk/crypto-anarchy.html	https://web.archive.org/web/*/https://www.activism.net/cypherpunk/crypto-anarchy.html
4	David Chaum — Security Without Identification (CACM 28(10), 1985)	https://www.semanticscholar.org/paper/Security-without-identification%3A-transaction-to-big-Chaum/a6020d6bce5c69e476dfee15bdf63944e2a717b3	https://web.archive.org/web/*/https://dl.acm.org/doi/10.1145/4372.4373
5	Jude Milhon — Wikipedia	https://en.wikipedia.org/wiki/Jude_Milhon	https://web.archive.org/web/*/https://en.wikipedia.org/wiki/Jude_Milhon
6	Cypherpunk — Wikipedia	https://en.wikipedia.org/wiki/Cypherpunk	https://web.archive.org/web/*/https://en.wikipedia.org/wiki/Cypherpunk
7	“Girls Need Modems!” — Jude Milhon (Capitol Technology University)	https://www.captechu.edu/blog/girls-need-modems-battle-cry-of-hacktivist-jude-milhon	https://web.archive.org/web/*/https://www.captechu.edu/blog/girls-need-modems-battle-cry-of-hacktivist-jude-milhon

How Permanent Is Your Social Media Footprint in 2026?

Thu, 11 Jun 2026 00:00:00 +0000

Most people meet their digital footprint as a button. Delete account. Deactivate. Download your information. The interface is reassuring: one click, and the past is gone. For roughly two decades of social media, billions of us have trusted that button to mean what it says.

It does not. Deletion, on almost every platform, is a change to what is shown — not a change to what is kept. Your profile vanishes from public view while copies persist in server backups, in the inboxes of everyone you ever messaged, and in data-broker records already sold — in one 2014 FTC study, a single broker held 3,000 data segments on nearly every American. In 2026 a newer copy joins them: the training corpora behind large language models, where a deleted post can survive inside a model’s weights long after the original is gone.

So what actually persists when you press delete — and what can you still do about it? This is not a guide to a magic erase tool, because none exists. It is a threat-model-first audit playbook: a way to see your footprint clearly, decide what genuinely matters, and spend your effort where it changes your real exposure rather than where it merely soothes you.

“Delete” Is a User-Interface Illusion
#

Deletion on most platforms is a permission change, not a destruction event. The platform stops displaying your content to the public, and often stops you from seeing it too — but the underlying records remain in systems you cannot reach. Understanding the gap between hidden and gone is the entire foundation of footprint hygiene.

Four reservoirs keep your “deleted” data alive, and every serious privacy guide agrees on them:

Reservoir	What persists	Does “delete” reach it?	Your lever
Platform backups & logs	Account data, and the DMs you sent (in recipients’ inboxes)	No — retained for defined periods	Erasure request (partial)
Data brokers	Records already scraped, sold, or syndicated	No — downstream copies outlive the source	Per-broker opt-out (recurring)
Shadow profiles	Data inferred about you from other people’s uploads and tags	No — built without your account	Minimise what others can link to you
Caches & screenshots	Anything that ever drew attention	No — copied before you removed it	None retroactively — prevent at posting

There is also a distinction the platforms rely on you to miss: deactivation is not deletion. Deactivating merely hides a profile and keeps everything warm for your return; only an explicit delete request begins the (partial) purge. Before you delete, download your own archive — you cannot audit what you can no longer see.

If you live under the EU’s GDPR or California’s CCPA/CPRA, you have a legal lever here — the right to erasure and the right to delete — and we will use it deliberately in the playbook below. But a legal right is a request, not a guarantee of total removal, and it reaches only the data you chose to surrender. The records the state compels you to hand over leak on their own schedule — a parallel problem with its own playbook, When the Government Leaks Your Data.

The 2026 Vector — Your Posts Are Now AI Training Data
#

Here is what the privacy-SaaS pages and the platform help-centres do not tell you, because it does not sell a deletion service: a large share of the public web has already been ingested to train AI models, and “deleting the source” does not remove what a model has already learned.

Public posts, captions, comments, and images have been collected into large web-scale datasets — Common Crawl, used to train models from most major labs, is the best-known — and used to train language and image models. Once a piece of text or a photo has been absorbed into a model’s parameters, there is no “delete” button that reaches inside the trained weights. Researchers studying machine unlearning — the problem of making a trained model forget specific data — treat it as genuinely hard and still unsolved at scale; the reliable fix is to retrain without the data, which model owners rarely do on an individual’s request. Separately, security researchers have demonstrated that fragments of training data can be extracted back out of large models, which means ingestion is not a one-way blur but a form of storage.

Three consequences follow, and they reframe everything in the previous section:

A web archive is a permanence engine, not just a memory. The Internet Archive’s Wayback Machine and similar crawlers keep snapshots of pages you have since deleted — and those snapshots are themselves re-ingestible into future datasets. Deletion at the source does not reach the snapshot.
Timing beats cleanup. Because ingestion happens continuously, the only fully effective control is not publishing the sensitive thing in the first place. Every defense after publication is partial.
The law is catching up, unevenly. Frameworks such as the EU AI Act are beginning to regulate training data and transparency, and GDPR’s erasure right is being tested against model training. This is a live, shifting frontier — useful to track, not yet something to rely on.

The practical takeaway is uncomfortable but clarifying: treat anything you post publicly as potentially permanent at the level of a machine’s memory. That is not a reason for despair. It is the reason the audit below starts with a threat model instead of a delete spree.

What Justine Sacco’s 12-Hour Flight Still Teaches in 2026
#

To see why permanence matters, look at the case that defined it. In December 2013, a senior director of corporate communications named Justine Sacco posted a single tasteless tweet to a then-small following before boarding a roughly eleven-hour flight from London to Cape Town.

“Going to Africa. Hope I don’t get AIDS. Just kidding. I’m white!”

Posted to about 170 followers. By the time her plane landed, the hashtag #HasJustineLandedYet was trending worldwide, strangers were refreshing for her arrival, and she had lost her job. She never had a chance to delete it before the world had already copied it.

— The Justine Sacco case, December 2013

Whatever you make of the tweet — and it was indignantly judged — the mechanism is the lesson, and the mechanism has only strengthened since. A message to about 170 followers became a global event in hours. Deletion was irrelevant: the content had been screenshotted, quoted, and reported into permanence before its author could act. More than a decade later, her name still surfaces the episode on the first page of search results, in journalism, and now in the training data of the models people ask about her.

The case teaches three durable rules. Reach is not visible at the moment of posting — small followings are not small exposure. Deletion races a crowd it cannot beat — once attention arrives, copies outrun you. And permanence is asymmetric — a single bad minute outlives years of context. The defense is not faster deletion. It is a deliberate pause before publishing, which we formalise next as the 24-hour cooling protocol. (Cora’s Series E examines documented OPSEC failures like this one in depth.)

The Old-Account Audit Playbook — A Six-Step Self-Assessment
#

This is the part no competitor publishes, because it sells nothing. It is the six-step audit I have built for this guide and recommend to readers — a routine that moves from seeing your footprint to shaping it. Work it once thoroughly, then revisit it annually.

Step	Goal	Example tools
1. Inventory	See the full map	Search your name & old handles; Wayback Machine
2. Threat model	Name the adversary & the asset	Pen and paper; the Privacy pillar
3. Triage	Find the few genuinely risky items	Location, routine, identity-link review
4. Delete deliberately	Remove in the right order	Download archive; Delete not Deactivate; unlink apps
5. Erasure & opt-out	Use the legal levers	GDPR Art.17 / CCPA requests; broker opt-outs
6. Pseudonym + cooling	Prevent future permanence	Identity separation; the 24-hour rule

Step 1 — Inventory what is actually out there. List every account you have ever created, including abandoned ones. Search your real name, every old username, and your email addresses. Check the Wayback Machine for snapshots of profiles you have already deleted. You are not fixing anything yet; you are drawing the map.

Step 2 — Model the threat before you touch a setting. Name your adversary and your asset. Are you protecting against a future employer, an ex-partner, a stalker, a doxxer, or simply your own future reputation? The honest answer determines everything that follows — a public-facing professional and an abuse survivor need opposite strategies. (This is the privacy-as-threat-modelling habit that underlies all of Cora’s work; if it is new to you, start with the Privacy & OPSEC pillar.)

Step 3 — Triage by real risk, not by volume. Most of your footprint is harmless. Find the few items that are not: home or workplace location, photos exposing routines or relationships, anything tying a pseudonym to your legal identity, and anything that contradicts the persona you maintain today. Rank these. You will spend your limited effort here.

Step 4 — Delete deliberately, in the right order. Download your archive first. Then delete rather than deactivate, unlink third-party app connections before closing an account, and remove high-risk individual posts even on accounts you intend to keep. Order matters: revoke connected apps before deletion, or they may retain access.

Step 5 — Exercise your erasure rights and opt out of brokers. Where you have legal standing — GDPR’s right to erasure, CCPA/CPRA’s right to delete — file the requests in writing and keep records. Submit opt-out and deletion requests to the major data brokers; this is tedious and recurring, not one-and-done, because brokers re-acquire data.

Step 6 — Migrate to a pseudonym and adopt a 24-hour cooling protocol. Going forward, separate a durable pseudonym from your legal identity for anything you do not want permanently attached to your name, and keep that separation clean. And institute the rule Sacco never had: for any post that is emotional, political, or about another person, wait 24 hours before publishing. The cooling protocol is the single highest-leverage habit here, because it is the only defense that acts before the permanence engines do.

When the Stakes Aren’t Symmetric — Footprint Risk for Women and Targeted Individuals
#

A footprint guide that treats every reader identically is quietly failing the readers who need it most. The risk of a persistent digital trail is not evenly distributed. For women, abuse survivors, activists, and other targeted individuals, an old post revealing a location, a routine, or a relationship is not an embarrassment — it is a physical-safety exposure that an adversary can act on.

This is where privacy stops being abstract. Stalkers and doxxers do not need a breach; they assemble a target from the footprint you left in public — the gym you tag, the school in the background, the predictable Friday pattern. Deletion after the fact is weakest exactly where the stakes are highest, because a motivated adversary has already copied what they need. For these readers, the audit’s emphasis inverts: Steps 2 and 3 — threat modelling and location triage — matter far more than completeness, and the 24-hour cooling protocol becomes a standing discipline about what to reveal at all.

I write about this from a particular conviction: privacy is not secrecy, and it is not paranoia. It is — as Eric Hughes wrote in A Cypherpunk’s Manifesto (1993) — the power to selectively reveal yourself to the world: to choose what is seen, by whom, and when. That power is a matter of dignity, and it is unequally taxed. Defending it deliberately is not hiding; it is self-respect made operational. Readers carrying asymmetric risk should treat footprint discipline as continuous practice, and may want to continue with the Sovereignty pillar, where self-determination over your own life is the through-line.

Bottom Line — Which Approach Fits You?
#

There is no single correct level of footprint discipline; there is the level that matches your threat model.

If you are a casual user with no specific adversary: run the audit once, fix the few genuinely risky items, adopt the 24-hour cooling habit, and stop there. Completeness is not worth your weekend.
If you are public-facing — a professional, creator, or candidate: assume permanence, curate deliberately, exercise erasure rights on the worst items, and treat every new post as a long-term liability or asset. The Sacco mechanism is aimed at you.
If you carry asymmetric risk — women facing harassment, survivors, activists, or anyone with a motivated adversary: prioritise location and relationship exposure above all, separate a pseudonym from your legal identity, treat the cooling protocol as a publishing gate, and revisit the audit on a schedule. Here, prevention is the only reliable control.

Across all three, the same truth holds: you cannot reliably delete your way to safety after the fact. You can only see clearly, decide deliberately, and publish less of what you would not want to be permanent.

Key Takeaways

Delete ≠ erase: On most platforms, deletion hides content from public view while backups, recipients’ copies, data brokers, and shadow profiles retain it.
AI is the 2026 permanence vector: Once a public post is absorbed into a model’s training data, no “delete” reaches the trained weights — machine unlearning remains unsolved at scale, so prevention beats cleanup.
Reach is invisible at posting time: Justine Sacco’s tweet reached about 170 followers and became a worldwide event within one 11-hour flight — small followings are not small exposure.
Audit before you delete: Inventory → threat-model → triage → deliberate deletion → erasure rights → pseudonym + cooling protocol. Effort goes where real risk lives.
The 24-hour cooling protocol is the highest-leverage habit: It is the only defense that acts before caches, archives, and training crawlers copy you.

Frequently Asked Questions
#

Does deleting your social media account really delete your data?
#

No — not completely. Deletion removes your profile from public view and begins the platform’s internal purge, but copies persist in backups, in the inboxes of people you messaged, in data-broker records already sold, in web archives, and potentially in AI training datasets. Deletion reduces your exposure; it does not guarantee erasure.

Can I remove my posts from AI training datasets?
#

In most cases, no — not retroactively. Once content has been ingested into a trained model, there is no reliable per-user delete, because making a model forget specific data (“machine unlearning”) is an unsolved problem at scale. Some platforms and jurisdictions are beginning to offer opt-outs from future training, which is worth using, but the dependable control is to avoid publishing sensitive material in the first place.

Does GDPR or CCPA force platforms to delete everything?
#

They give you a powerful but bounded lever. GDPR’s Article 17 (right to erasure) and CCPA/CPRA’s right to delete require covered businesses to honour valid deletion requests — subject to exceptions such as legal retention and the defence of legal claims under both, plus security-incident detection under the CCPA. They apply to data the business can identify as yours, and enforcement against downstream copies and model training is still being tested. File the requests; do not assume they reach every copy.

What is a 24-hour cooling protocol?
#

It is a self-imposed rule to wait 24 hours before publishing any post that is emotional, political, or about another person. Because caches, archives, and AI crawlers can copy a post within minutes, deletion rarely beats them — so the only consistently effective defense is the pause before publication. It is the single habit that would have prevented most documented footprint disasters.

References
#

#	Source	URL	Archived
1	GDPR Article 17 — Right to erasure (‘right to be forgotten’)	https://gdpr-info.eu/art-17-gdpr/	https://web.archive.org/web/*/https://gdpr-info.eu/art-17-gdpr/
2	California CCPA — Right to Delete (California Attorney General)	https://oag.ca.gov/privacy/ccpa	https://web.archive.org/web/*/https://oag.ca.gov/privacy/ccpa
3	Jon Ronson, “How One Stupid Tweet Blew Up Justine Sacco’s Life,” NYT Magazine, 2015 (paywall; also in So You’ve Been Publicly Shamed, Riverhead, 2015)	https://www.nytimes.com/2015/02/15/magazine/how-one-stupid-tweet-blew-up-justine-saccos-life.html	NYT blocks archive crawlers (2025–); see Ronson (2015) book
4	EU Artificial Intelligence Act — European Commission (official)	https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai	https://web.archive.org/web/*/https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
5	U.S. FTC — “Data Brokers: A Call for Transparency and Accountability” (2014)	https://www.ftc.gov/reports/data-brokers-call-transparency-accountability-report-federal-trade-commission-may-2014	https://web.archive.org/web/*/https://www.ftc.gov/reports/data-brokers-call-transparency-accountability-report-federal-trade-commission-may-2014
6	Carlini et al., “Extracting Training Data from Large Language Models” (USENIX Security 2021; preprint arXiv:2012.07805)	https://arxiv.org/abs/2012.07805	https://web.archive.org/web/*/https://arxiv.org/abs/2012.07805
7	Internet Archive — Wayback Machine	https://web.archive.org/	— (the archive itself)
8	Eric Hughes, “A Cypherpunk’s Manifesto” (1993)	https://www.activism.net/cypherpunk/manifesto.html	https://web.archive.org/web/*/https://www.activism.net/cypherpunk/manifesto.html

The Pilot Matrix — Every Service, Every Defined Dimension

Wed, 15 Jul 2026 00:00:00 +0000

Disclosures: nature of this page · affiliations · corrections

This page is a factual record — not advice, not a recommendation, not a solicitation, not an endorsement. Inclusion is not approval. Policies change; check the provider's primary documents before you rely on any value.
We currently have no affiliate relationship with any listed service. If that ever changes, we will disclose it inline, it will not affect what is listed or how it is ordered, and the change will be recorded here.
Listed provider and believe a value is wrong? If our review confirms an error, we correct it and record the correction publicly — write to editor@cypherpunkguide.com
How this data is collected and checked (methodology)

Scroll sideways for all 8 service columns →

Dimension	ClaudeAnthropic	DeepSeekDeepSeek	GeminiGoogle	Le ChatMistral AI	ChatGPTOpenAI	OpenRouterOpenRouter	PerplexityPerplexity	VeniceVenice
Identity at signup & use Which identity details the provider requires or collects at each touchpoint.
Account required	conditionalprovider-stated upgrading to a paid plan · global default · free/paid · web/API	no current scoped record	conditionalprovider-stated signed-in use · global default · free/paid · web/app	conditionalprovider-stated varies by product (some products require an account) · global default · free/paid · web/app	no current scoped record	requiredprovider-stated global default · free/paid · web/API	no current scoped record	optionalprovider-stated global default · demo · web
Signup identifiers	no current scoped record	email or phoneprovider-stated global default · free/paid · web	requiredprovider-stated global default · free/paid · web/app	no current scoped record	no current scoped record	no current scoped record	requiredprovider-stated global default · free/paid · web	no current scoped record
Phone at signup	requiredprovider-stated supported locations · free/paid · web/desktop/mobile · Google SSO/email	email or phoneprovider-stated global default · free/paid · web	no current scoped record	collected if you provide itprovider-stated global default · free/paid · web/app	no current scoped record	no current scoped record	no current scoped record	no current scoped record
Email at signup	conditionalprovider-stated choosing the email signup path (Google SSO is the alternative) · supported locations · free/paid · web/API	email or phoneprovider-stated global default · free/paid · web	no current scoped record	collectedprovider-stated global default · free/paid · web/app	no current scoped record	conditionalprovider-stated global default · free/paid · web/API	no current scoped record	no current scoped record
Sign-in methods (SSO/wallet)	Google SSO or email magic-linkprovider-stated global default · free/paid · web/desktop/mobile	no current scoped record	no current scoped record	no current scoped record	no current scoped record	no current scoped record	no current scoped record	email, social login, or Web3 walletprovider-stated creating an account (the demo needs none) · global default · free/paid · web
Minimum age	18+provider-stated global default · free/paid · web/API	no current scoped record	no current scoped record	13+provider-stated global default · free/paid · web/app	no current scoped record	no current scoped record	no current scoped record	no current scoped record
Later identity or phone checks	conditionalprovider-stated provider's discretion ('in certain circumstances') · global default · free/paid · web/API	no current scoped record	no current scoped record	no current scoped record	no current scoped record	no current scoped record	no current scoped record	no current scoped record
Payment and billing identity	no current scoped record	no current scoped record	no current scoped record	no current scoped record	requiredprovider-stated upgrading to a paid plan · global default · paid · web	cryptocurrency acceptedprovider-stated global default · paid · web/API	no current scoped record	no current scoped record
Data handling What happens to your inputs and data: storage, retention, training, human review, and sharing.
Inputs sent to downstream providers	no current scoped record	no current scoped record	no current scoped record	no current scoped record	no current scoped record	sent to downstream providerprovider-stated global default · free/paid · web/API	no current scoped record	zero data retention (imposed downstream)provider-stated global default · free/paid/demo · web
Inputs used for training	on by default; opt-out availableprovider-stated global default · free/paid · web	on by default; no stated opt-outprovider-stated global default · free/paid · web	no current scoped record	on by default; opt-out availableprovider-stated global default · free · web/app	on by default; opt-out availableprovider-stated global default · free/paid · web	varies by downstream provider — selectableprovider-stated global default · free/paid · web/API	email content excludedprovider-stated global default · free/paid · web	no current scoped record
Human review of chats	no current scoped record	no current scoped record	yesprovider-stated global default · free/paid · web/app	no current scoped record	no current scoped record	no current scoped record	no current scoped record	no current scoped record
Retention	no current scoped record	no current scoped record	up to 3 yearsprovider-stated conversation picked for human review · global default · free/paid · web/app	until you delete itprovider-stated global default · free/paid · web/app	no current scoped record	no current scoped record	no current scoped record	not retainedprovider-stated global default · free/paid/demo · web
Deletion and identifier reuse	availableprovider-stated global default · free/paid · web	availableprovider-stated global default · free/paid · web	no current scoped record	availableprovider-stated global default · free/paid · web/app	availableprovider-stated global default · free/paid · webreusable after deletionprovider-stated global default · free/paid · web	no current scoped record	no current scoped record	no current scoped record
Optional privacy controls	no current scoped record	no current scoped record	availableprovider-stated global default · free/paid · web/app	availableprovider-stated global default · free/paid · web/app	no current scoped record	no current scoped record	no current scoped record	no current scoped record
Data controller's stated jurisdiction	no current scoped record	China (CN)provider-stated global default · free/paid · web	no current scoped record	France (FR)provider-stated global default · free/paid · web/app	no current scoped record	no current scoped record	no current scoped record	no current scoped record
Network layer (separate) Outside this dataset's provider-account identity scope. Recorded separately: IP address, device data, and site analytics belong to the network layer.
Third-party site analytics	no current scoped record	no current scoped record	no current scoped record	no current scoped record	no current scoped record	presentprovider-stated global default · free/paid · web	no current scoped record	no current scoped record
Metadata collected (including IP)	no current scoped record	no current scoped record	collectedprovider-stated global default · free/paid · web/app	no current scoped record	no current scoped record	no current scoped record	no current scoped record	collectedprovider-stated global default · demo · web

Columns are alphabetical. · Provider statements and controlled interface observations are labeled separately; neither overrides the other. · A populated cell means at least one scoped record, not full coverage across regions, plans, or platforms. · no current scoped record = no current scoped record in this pilot — this is NOT evidence that no requirement exists · ⚠ = conflicting sources · ↻ = changed over time · No scores, no rankings, no recommendations.

How to read this
#

Each visible value comes from a registered evidence role. Provider documents record what the provider published. A controlled interface run would record what one defined path did under its stated conditions. The roles are displayed separately; neither silently overrides the other. The current pilot contains provider-stated values only.
Scope is part of the value. Region, plan, platform, signup method, and other shown conditions limit what a record can support. One scoped record does not establish every variant of a service.
“Not assessed” means no current scoped record. The dataset has no current record for that service and dimension in the displayed scope. It is not evidence that no requirement exists, and this table never turns silence into “no requirement.”
⚠ is reserved for a registered evidence conflict and is unused in the current pilot. Under P0, a disagreement within comparable scope defers the release. After P1 implements an append-only structured conflict relation, the two roles can be shown without giving either automatic priority.
↻ marks drift. Requirements change. Where we have evidence of an earlier state, the service page shows what changed and when we could bracket it.
Columns are alphabetical. There is no ranking, score, or “best.” What counts as acceptable coupling depends on your threat model, not ours. The pilot findings walk through what the data shows; the methodology explains every marker and evidence check.

Back: service index · findings · methodology

Eight Hosted-AI Services: Three Policy Contrasts in a 44-Fact Pilot

Tue, 14 Jul 2026 00:00:00 +0000

Disclosures: nature of this page · affiliations · corrections

This page is a factual record — not advice, not a recommendation, not a solicitation, not an endorsement. Inclusion is not approval. Policies change; check the provider's primary documents before you rely on any value.
We currently have no affiliate relationship with any listed service. If that ever changes, we will disclose it inline, it will not affect what is listed or how it is ordered, and the change will be recorded here.
Listed provider and believe a value is wrong? If our review confirms an error, we correct it and record the correction publicly — write to editor@cypherpunkguide.com
How this data is collected and checked (methodology)

KYC Drift currently holds 44 fact records about eight hosted-AI services. All 44 come from a provider’s terms, privacy policy, or help material and point to archived evidence. There are no controlled interface-run observations yet. This page therefore reads providers’ published positions; it does not report how the systems behaved in a fresh registration or controlled test.

What the pilot can support today
#

The comparison has eight services and 17 dimensions, or 136 possible service-by-dimension fields. Forty-five fields contain at least one current scoped record; 91 contain no current scoped record. These counts describe the present inventory, not a completeness percentage or a claim that every scope was studied. Each record applies only to its displayed region, plan, platform, signup method, and other stated conditions.

Forty-four evidence-linked records are enough to expose concrete differences in published rules, but not enough to order the services on a single privacy scale. Every contrast below stands on its own dimension. You may care about phone requirements and not downstream routing, or the reverse. The pilot supplies dated evidence for those decisions without turning unlike choices into a score.

Three independent contrasts
#

Provider documents describe different identifiers at account setup. Anthropic’s help material states that SMS phone verification applies to all new Claude users, cannot be skipped, rejects VoIP and several other number types, and limits each phone number to one account. DeepSeek’s privacy policy says that account setup may collect an email address and/or telephone number. This is a contrast between two official statements, not a claim that either registration path was reproduced here. The Claude record and DeepSeek record show the exact scope and archived text; the pilot has no interface run for either path.

“Delete” refers to different retention rules. Venice states that it does not retain prompts or outputs. Claude and ChatGPT state time-bounded removal for deleted data, subject to their stated exceptions. Mistral says chats remain until the user deletes them and describes longer retention for some account and identity data. Gemini states that some human-reviewed conversations can remain for up to three years even after activity deletion. DeepSeek allows chat-history deletion while describing retention more broadly as lasting as long as necessary. These are separate provider statements, not a finding that any one system enforced its policy.

Routers divide responsibility between two providers. OpenRouter and Venice both state that prompts can reach downstream model providers. OpenRouter says retention and training depend on the selected downstream provider and offers controls for choosing providers with particular data policies. Venice says it imposes zero-data-retention conditions downstream. The relevant question is not whether one architecture is better; it is which party receives the prompt, which written commitment applies, and whether that commitment has been independently tested. In this pilot, enforcement remains untested for both.

What the pilot cannot establish
#

The dataset does not measure network anonymity, payment-intermediary exposure, or legal-process access. It does not test the product interface, confirm regional availability, or audit backend enforcement. A value labeled provider-stated means the cited document contained the claim when its archived body was checked. It does not mean CypherpunkGuide verified the provider’s system.

The 91 fields with no current scoped record are equally important. Not assessed means that the dataset has no current record for that service, dimension, and displayed scope; it never means the provider has no requirement or practice. The service pages expose these gaps so sparse documentation cannot look like a favorable result.

A monthly re-check is the operating target, not a live service-level promise. It becomes a committed cadence only after the capture, validation, diff, adjudication, and release pipeline completes two consecutive production-equivalent cycles with every gate GREEN and an observable heartbeat. Until then, a fact’s checked-through date is derived conservatively from its current supporting evidence streams. The pilot-wide checked-through date is the oldest such fact date, so a partial refresh cannot make the entire dataset look newer.

Corrections, disputes, and missing services: the methodology explains the rules. Write to editor@cypherpunkguide.com. If our review confirms an error, we publish the correction. We normally aim to acknowledge a dispute within 14 days, but that is an operating target rather than a guaranteed response time.

How Is AI Closing the Open Web in 2026?

Tue, 30 Jun 2026 00:00:00 +0000

The open web — the one where anyone could publish at a URL and anyone could find it by following a link — has spent two years being quietly re-plumbed around AI. The change is easy to miss because nothing was announced and no wall went up overnight. What happened instead is measurable in traffic logs. When Google shows an AI-generated answer, the share of searches that send a click to an outside site falls from roughly 15% to about 8% (Pew Research, 2025); across thousands of news sites, search referrals dropped about a third over the year to late 2025 (Chartbeat data, reported by the Reuters Institute); and the AI tools that absorbed that attention send back, in return, on the order of 0.1–0.5% of web visits.

So the web is being read more than ever — just not by people, and not in a way that returns to the source. Is the open web dying, then? The question is worth holding for a moment, because the answer decides what you do next — mourn it, optimize for the machines reading it, or build something they cannot enclose. “Dying” turns out to be both too dramatic and too comforting a word; the honest diagnosis is narrower, and it points toward construction rather than nostalgia or surrender.

A note on where I stand: this site is published the way this article will end up recommending — self-hosted, syndicated over RSS and open social protocols, dependent on no single platform to exist. That is not a victory lap. It is a small, practical experiment, and what follows is as honest about its limits as about its case.

The Web Is Being Read More Than Ever — Just Not by People
#

The change is not that the web is being crawled — it always was — but that the crawl no longer returns a visit: search was a directory that routed people to sources, while AI answer engines are a terminus that ends the journey at the answer. That distinction is the whole argument, and it is easy to get wrong.

It would be a mistake to point at the sheer volume of AI crawling as the harm. Some bots are extraordinarily extractive — one analysis put a major AI crawler’s ratio, in 2025, at over twenty thousand pages fetched for every visitor it referred back — but search engines have always crawled far more than they sent traffic to. Crawling more than you refer is normal; it is how indexing works. The number that matters is not the ratio but the severed return path: the page is read, the answer is served, and the reader never arrives.

That severance is what the cleaner figures isolate. The same search, with and without an AI summary, loses roughly half its outbound clicks (about 15% down to 8%), and only about 1% of users click the citations inside an AI answer (Pew Research, 2025). Zero-click searches — those that end without a visit anywhere — rose from about 56% to 69% in the year to May 2025 (Similarweb data, via Search Engine Roundtable). To be fair to the data, the broad referral decline has several causes at once — social platforms throttling outbound links, core-algorithm shifts, paywalls, audiences moving to apps — so the honest causal claim rests on the with-and-without-AI comparison, not on blaming AI for every lost visit.

	The web as directory (search)	The web as terminus (AI answer)
What the crawl is for	Indexing, to route a human to the page	Ingestion, to synthesize an answer in place
What the reader gets	A list of sources to visit	A finished answer; the sources are optional
What the source gets back	A visit — attention, subscribers, revenue	A citation almost no one clicks (~1%)
The bargain	Allow indexing in exchange for discovery	Allow ingestion in exchange for ~0.1–0.5% referral

But People Are Choosing the Answer Box
#

The uncomfortable truth the enclosure story tends to skip is that most people prefer the answer to the ten blue links — and they are not wrong to. Any argument that treats readers as pure victims of AI search is going to misread why AI search won, and it will be easy to dismiss for exactly that reason.

The open web that users are leaving was, very often, a hostile place to land: search-optimized filler that buried the answer under a personal anecdote, ad units that shifted the text as it loaded, cookie banners, newsletter pop-ups, autoplay video. An answer that skips all of that is a genuine improvement in daily life, not a trick played on the gullible. Honesty about that is the price of being taken seriously.

But two things follow that the convenience does not cancel. First, the answer is assembled from work the answer engine did not do and, increasingly, neither pays for nor points back to — the cost is transferred to the people who wrote the underlying pages, with no mechanism to recover it. Second, and more corrosive in the long run, is the sustainability paradox: an answer box that starves its sources eventually has nothing fresh or true left to summarize. By mid-2025, researchers at Stanford, Imperial College and the Internet Archive estimated that 17.6% of newly published websites were entirely AI-generated — a subset of the roughly 35% that were AI-generated or AI-assisted (reported by Gizmodo, 2025); “slop” — low-quality content generated at scale by AI — was named Merriam-Webster’s word of the year for 2025. A web that increasingly reads and rewrites itself is a hall of mirrors. So the problem is not that users are wrong to want answers. It is that the current arrangement quietly spends down a commons that no one is refilling.

Every Response on Offer Is a Petition or a Palliative
#

The fixes currently on the table — block the crawlers, charge them, optimize for them, or sue them — share a hidden assumption: that a web you control can be restored by persuading the enclosers, or a new middleman, to behave. Each is worth taking seriously on its own terms, and each, taken seriously, falls short of returning control.

Blocking is the reflex, and the weakest. A robots.txt rule is a request, not a fence: it has no reliable legal force on its own, and a well-funded crawler can ignore it or simply relabel its traffic. The most effective version delegates the blocking to an intermediary — Cloudflare began blocking AI crawlers by default for new sites in July 2025 (Cloudflare) — which works, but only by moving the gate to Cloudflare.

Charging is the response that looks most like a solution, and it deserves the strongest version of its case. Cloudflare’s “pay-per-crawl” marketplace (launched July 2025) and the large licensing deals — Reddit’s reported ~$60 million a year from Google, News Corp’s reported $250-million-plus, five-year pact with OpenAI — are not nothing. They are the first real compensation many publishers have ever had for machine reading, and a price signal where there had been only free extraction. The trouble is structural. Pay-per-crawl installs a central tollbooth as the interface between every site and every model; it concedes the principle that access is fine so long as you pay the gatekeeper; and it routes the money to the handful of publishers with the leverage to negotiate, leaving the independent web with a cheaper version of the same dependency. It is enclosure with a revenue-share — call it Enclosure 2.0 — not a web the publisher controls.

Optimizing for AI search (“generative engine optimization”) is adaptation that has already accepted the terms. And litigation, the most institutional path, is genuinely consequential: the copyright suits against OpenAI are live — a judge ordered the company to produce twenty million ChatGPT logs in January 2026 (National Law Review) — the UK’s competition regulator now lets publishers opt out of Google’s AI summaries (Press Gazette, 2026), and the EU AI Act’s remaining transparency obligations, including disclosure rules for AI-generated content, reach their enforcement phase in August 2026. These matter, and the next section is not an argument against them. But they are slow, jurisdiction-bound, and uncertain, and every one of them asks an institution to grant what cypherpunks have long said institutions do not grant out of beneficence.

Response	What it actually does	Honest upside	Why it is still a petition
`robots.txt` block	Politely asks bots not to read	Free, simple, widely honored by reputable bots	No legal force alone; ignored or relabeled by aggressive crawlers
Pay-per-crawl / licensing	Charges machines via a CDN or deal	First real compensation; a price signal	New central tollbooth; concedes “access if you pay”; favors incumbents
AI-search optimization	Formats content for the answer box	Some visibility inside the enclosure	Accepts the terms; you are now optimizing for the gatekeeper
Copyright litigation	Sues for training/use	Can reshape licensing and disclosure	Slow, jurisdictional, uncertain; asks institutions to grant control

The Open Web Was Already Enclosed — Which Is the Whole Point
#

Before mourning the open web, it is worth admitting it had already been enclosed once: for fifteen years, most discovery ran through a single search box and most of the money through one ad exchange. AI did not pave a free commons. It is the second enclosure, and it is taking the one consolation the first one left publishers — the referral visit.

That correction matters because it kills the nostalgia, and the nostalgia is the trap. The goal was never to restore the Google-era web, which was already someone else’s toll road. The useful instruction is older and was written down in 1993: privacy — and, it turns out, openness — is not something you petition institutions to grant, because privacy that depends on an institution’s goodwill is privacy it can revoke. The cypherpunk conclusion is to build the guarantee into a mechanism instead, which is the argument of the Cypherpunk Manifesto applied now to the web itself rather than to the message in transit.

The person who saw the shape of this earliest was Richard Stallman. His 1997 story The Right to Read imagined a near future in which the act of reading is metered and access to text is controlled by whoever owns the software — not a bad description of a web where reading is increasingly mediated by a service you query rather than pages you open. And his objection to that kind of service is precise rather than merely rhetorical. He argues that doing your computing on someone else’s server “inherently trashes your computing freedom,” because you cannot get a copy of a hosted AI and run it yourself; the only way to use it is on a machine you do not control. He is blunter still about its reliability — he refuses to call it intelligence at all, preferring “bullshit generator” for a system that, in his words, “generates output ‘with indifference to the truth.’” You need not adopt the polemic to keep the structural point, which is the cypherpunk one: a capability you cannot run, inspect, or fork is a capability someone else controls.

“Privacy that depends on an institution’s goodwill is privacy that the institution can revoke.” The same is now true of access, discovery, and reading. The durable version of any of them has to be a property of a mechanism, not a promise.

The Honest Sovereign-Web Revival Path
#

The constructive answer is not to quit the mainstream web tomorrow — almost no one can — but to build a parallel layer whose openness needs no company’s permission, starting with how you read and ending with how you publish. What makes this different from the usual “just use the decentralized web” advice is that it states the limits as plainly as the tools.

Reading sovereign comes first, because it is the easier half:

Follow sources directly with RSS — the open web’s surviving circulatory system. It is a feed you control, with no algorithm deciding what you see and no engagement metrics shaping what gets written; interest in it is climbing again as readers look for an exit from algorithmic feeds.
Read through Tor Browser for unintermediated access to the web and to onion services. This is load-bearing rather than fringe: the New York Times, the Guardian and Der Spiegel all run onion services for sources.
Answer your own questions with a local, open-weights model — the step most “decentralize everything” guides skip. Decentralizing your data accomplishes little if the only intelligence allowed to read it is a frontier model running on someone else’s GPUs, which is where the real concentration of power now sits. Running a smaller model locally, over indexes and feeds you choose, is what makes the read sovereign rather than merely relocated. Sovereignty over the model matters as much as sovereignty over the data.

Publishing sovereign is the harder half, and the more important one:

Self-host on a cheap virtual server — a home no platform can delete.
Syndicate over RSS and open social protocols — Nostr and the Fediverse’s ActivityPub — where the relationship with your audience is not a platform’s to revoke.
Offer an onion mirror if your readers need to reach you from somewhere hostile.

None of this is frictionless, and pretending otherwise is how the last decade of “own your platform” advice lost credibility. So, the limits, stated plainly. The Fediverse is on the order of one to two million monthly-active users, not a billion; it is a town, not a continent. IPFS trades real latency and a steep learning curve for its censorship resistance. Self-hosting is a privilege of time and skill before it is anything else. None of these replaces the reach of mainstream search or a large social platform, and anyone who tells you a migration is imminent is selling something.

Which is why building this layer is not a substitute for politics. Antitrust enforcement, statutory licensing, the kind of opt-out the UK regulator just won, public-interest search indexes, data trusts — all of it is worth fighting for, and code does not replace any of it. The sovereign web is the floor beneath that fight: the thing that holds when the law is slow or captured, so that you are not helpless in the meantime. The cypherpunk claim was never that software replaces collective action; it is that rights you can run yourself do not depend on winning the politics first.

This is not theoretical here. This site is self-hosted, posted to Nostr and the Fediverse, and reachable without any platform’s leave; we also watch the self-identifying AI crawlers arrive on our own server logs every day, as we noted in our manifesto primer. The honest report is that the sovereign web is a place to stand, not yet a place to win — smaller and slower to find than it would be if we optimized purely for the answer box. To be square about our own interests: an independent site can benefit from being cited in an AI answer, and we are not against that. The point is not to refuse the machines but to refuse dependence on a channel a company can close. Be citable; do not be captured. The same logic runs through the rest of our work on AI-scale surveillance — from the AI-age threat model to the way deletion no longer reaches a model’s training data in the permanence of your footprint — and through the identity checkpoints going up at the door of the web in the fight over age verification.

Layer	The move	What it gives you	The honest limit
Read — feeds	RSS reader you control	Discovery with no algorithm or metrics	You curate it yourself; no serendipity engine
Read — access	Tor Browser + onion services	Unintermediated, censorship-resistant reading	Slower; some sites mis-treat Tor traffic
Read — intelligence	Local, open-weights model	Answers from software you run, not a logged service	Smaller and less capable than frontier models
Publish — hosting	Self-host on a cheap VPS	A home no platform can delete	Time, skill, and maintenance are on you
Publish — reach	Nostr + Fediverse + RSS	An audience tie no platform owns	~1–2M-active scale, not mass reach

Bottom Line — Build, Don’t Petition
#

The open web is not dying of natural causes; it is being enclosed for the second time, and the most honest response is neither nostalgia nor adaptation but construction. Search was the first enclosure; the AI answer box is the second, and it removes the referral visit that the first one left behind. Readers genuinely prefer answers, which is exactly why the source web has to be defended on grounds of sustainability and sovereignty rather than sentiment. The petitions and palliatives on offer — blocking, charging, optimizing, suing — each leave a gatekeeper in charge. The older instruction is the durable one: build openness into mechanisms no one can revoke — the model as well as the data — and treat that as the floor under the law and collective action, not a replacement for them. It will not out-scale the answer box this year. It is, still, somewhere to stand when the walls finish going up.

Key Takeaways

The harm is a severed return path, not crawling itself: with an AI summary present, outbound clicks roughly halve (about 15% to 8%), and only ~1% of people click the citations inside an AI answer.
It is the second enclosure: the pre-AI web already ran through one search box and one ad exchange, so the goal is not nostalgia for the Google era but openness built into mechanisms no one can revoke.
Users are not wrong to prefer answers — but an answer box that starves its sources runs into a sustainability paradox, with ~17.6% of new sites already entirely AI-generated by mid-2025.
Every mainstream fix leaves a gatekeeper in charge: robots.txt has no legal force alone, pay-per-crawl installs a central tollbooth, optimization accepts the terms, and litigation is slow and jurisdictional.
Sovereignty needs the model, not just the data: decentralizing content while the only intelligence is a frontier model on someone else’s GPUs changes little — a local, open-weights model is what makes reading sovereign rather than relocated.

Frequently Asked Questions
#

Is AI really closing the open web, or just changing it?
#

Both, but the precise claim is narrower than “the web is dying.” Web content is more accessible to machines than ever; what is closing is the path back to humans and to the sites that produced it. When an AI answer appears, outbound clicks fall by roughly half, and the AI tools that captured that attention refer back only about 0.1–0.5% of web traffic. The web is being read more than ever — just not by people in a way that returns to the source. “Enclosure” fits better than “death”: the commons is still there, but access to its value is being walled and metered.

What is “pay-per-crawl,” and does it fix the problem?
#

Pay-per-crawl is a system — Cloudflare launched a marketplace for it in July 2025 — that lets a site charge AI crawlers for access instead of blocking them, alongside direct licensing deals between big publishers and AI companies. It is a real improvement on uncompensated scraping and the first money many publishers have seen for machine reading. But it does not return control of the web to publishers: it installs a central intermediary as the tollbooth between every site and every model, accepts the principle that access is fine if you pay the gatekeeper, and favors large publishers with negotiating leverage. It is enclosure with a revenue-share, not an open web.

Should I block AI crawlers with robots.txt?
#

You can, and reputable crawlers will usually honor it, but understand what it is: a request, not a fence. A robots.txt directive has no reliable legal force on its own, and aggressive or relabeled crawlers can ignore it. Blocking also trades away any chance of being cited in answers people do read. A more durable posture than block-or-allow is to stop depending on any single channel you do not control — publish where your audience tie cannot be revoked, and treat crawler policy as a tactic, not a strategy.

What is the “sovereign web,” realistically?
#

It is the set of ways to read and publish that do not depend on a company’s permission: RSS for feeds, Tor and onion services for access, locally-run open-weights models for answers, and self-hosting plus open social protocols (Nostr, the Fediverse) for publishing. Realistically, it is niche today — the Fediverse is on the order of one to two million monthly-active users, self-hosting demands time and skill, and IPFS trades latency for censorship resistance. It will not replace mainstream search or social this year. Its value is as resilient parallel infrastructure — a place to stand — not as a finished replacement.

Do I have to be technical to escape the answer-box web?
#

No, not to start. The lowest-effort, highest-return move is reclaiming how you read: install an RSS reader and follow sources directly, so an algorithm and an answer box stop deciding what reaches you. Tor Browser is a one-click download for unintermediated access. The more technical steps — running a local model, self-hosting, offering an onion mirror — are a ladder you can climb over time, not a prerequisite. The principle does not require code: prefer tools and protocols whose openness is a property of their design over services that merely promise to behave.

#	Source	URL	Archive
1	Pew Research — clicks fall when an AI summary appears (2025)	https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/	https://web.archive.org/web/2025/https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/
2	Reuters Institute — Journalism Trends 2026 (Chartbeat ~one-third referral decline)	https://reutersinstitute.politics.ox.ac.uk/journalism-media-and-technology-trends-and-predictions-2026	https://web.archive.org/web/2026/https://reutersinstitute.politics.ox.ac.uk/journalism-media-and-technology-trends-and-predictions-2026
3	Search Engine Roundtable — Similarweb zero-click 56%→69%	https://www.seroundtable.com/similarweb-google-zero-click-search-growth-39706.html	https://web.archive.org/web/2025/https://www.seroundtable.com/similarweb-google-zero-click-search-growth-39706.html
4	Cloudflare — controlling content use for AI training (July 2025)	https://blog.cloudflare.com/control-content-use-for-ai-training/	https://web.archive.org/web/2025/https://blog.cloudflare.com/control-content-use-for-ai-training/
5	Cloudflare — Pay Per Crawl changelog (2025-07-01)	https://developers.cloudflare.com/changelog/2025-07-01-pay-per-crawl/	https://web.archive.org/web/2025/https://developers.cloudflare.com/changelog/2025-07-01-pay-per-crawl/
6	The Decoder — Reddit–Google AI training deal (~$60M/yr)	https://the-decoder.com/reddit-signs-60-million-annual-training-data-deal-with-google/	https://web.archive.org/web/2024/https://the-decoder.com/reddit-signs-60-million-annual-training-data-deal-with-google/
7	Variety — News Corp–OpenAI licensing deal	https://variety.com/2024/digital/news/news-corp-openai-licensing-deal-1236013734/	https://web.archive.org/web/2024/https://variety.com/2024/digital/news/news-corp-openai-licensing-deal-1236013734/
8	Gizmodo — 17.6% of new sites entirely AI-generated (Stanford/Imperial/Internet Archive)	https://gizmodo.com/dead-internet-theory-is-17-of-the-way-to-becoming-reality-study-finds-2000751718	https://web.archive.org/web/2025/https://gizmodo.com/dead-internet-theory-is-17-of-the-way-to-becoming-reality-study-finds-2000751718
9	Merriam-Webster — Word of the Year 2025 (“slop”)	https://www.merriam-webster.com/wordplay/word-of-the-year	https://web.archive.org/web/20251201000000*/https://www.merriam-webster.com/wordplay/word-of-the-year
10	National Law Review — court orders 20M ChatGPT logs (Jan 2026)	https://natlawreview.com/article/openai-loses-privacy-gambit-20-million-chatgpt-logs-likely-headed-copyright	https://web.archive.org/web/2026/https://natlawreview.com/article/openai-loses-privacy-gambit-20-million-chatgpt-logs-likely-headed-copyright
11	Press Gazette — UK CMA publisher opt-out from AI summaries (Jan 2026)	https://pressgazette.co.uk/platforms/google-regulation-uk/	https://web.archive.org/web/2026/https://pressgazette.co.uk/platforms/google-regulation-uk/
12	GNU Project — Richard Stallman, The Right to Read (1997)	https://www.gnu.org/philosophy/right-to-read.en.html	https://web.archive.org/web/2025/https://www.gnu.org/philosophy/right-to-read.en.html
13	stallman.org — Reasons not to use ChatGPT	https://stallman.org/chatgpt.html	https://web.archive.org/web/2025/https://stallman.org/chatgpt.html
14	Tor Project — official site / onion services	https://www.torproject.org/	https://web.archive.org/web/2025/https://www.torproject.org/

Buy Bitcoin Without KYC in 2026: 5 P2P Markets Compared

Tue, 23 Jun 2026 00:00:00 +0000

Buying bitcoin usually means handing a photo ID to a regulated exchange that keeps a permanent record linking your name to every coin you withdraw. Peer-to-peer marketplaces are the alternative: you trade directly with another person, no document upload, your keys your coins. The demand is real — one of the top results for “buy bitcoin no KYC” is a forum thread titled “Where to actually buy BTC NO KYC?”, the actually doing a lot of work.

Here is why that frustration is earned, and it is the uncomfortable measure of the threat: three of the marketplaces that “best no-KYC” lists still recommend — LocalBitcoins, Paxful, and LocalMonero — shut down between 2023 and 2025, and one of the survivors lost 11.59 BTC to an exploit in May 2026. Choosing from a stale list can mean sending money to a dead brand’s clone, or badly misjudging where your coins actually sit while a trade is open.

So which of the surviving markets fits you? The honest answer is that it turns on three things the listicles flatten into a star rating: the escrow model (where your coins sit mid-trade), how disputes resolve, and what “no-KYC” actually means for each service. I buy and hold under a pseudonym, so I treat a KYC paper trail as a permanent, irreversible liability — and for this guide I mapped each marketplace’s escrow design and dispute rules against its own documentation and source code, then re-checked which services still exist. Below is that decomposition for HodlHodl, Bisq, RoboSats, Peach, and Vexl.

The list says	The 2026 reality
“Use LocalBitcoins or Paxful”	Both shut down (2023, 2025) — a search can still send you to a clone
“Non-custodial means your coins are safe”	Four different escrow models, each with a different failure mode
“No-KYC means no ID, ever”	ID can still be demanded — in a dispute, or above a spending limit
“Bisq is battle-tested”	Bisq v1 lost 11.59 BTC to an exploit in May 2026 (reimbursed; v2 is separate)

What “No-KYC” Actually Means in 2026 (and What It Doesn’t)
#

No-KYC trading means you can open an account and trade without submitting government identification — but it is not a promise that identification can never be required. The trigger differs by marketplace: some can demand ID only during a dispute, one enforces a spending threshold above which verification kicks in, and a couple never ask at all. Treating “no-KYC” as a single binary is the first mistake, because the exception is exactly where your privacy can break.

The distinction matters because the point of buying without KYC is to avoid a permanent record tying your identity to your coins. A service that can compel ID during a dispute still creates that record the moment something goes wrong — which is precisely when you are least able to walk away. The honest version of the comparison is a table of triggers, not a row of green checkmarks.

Marketplace	No-KYC to trade?	When ID can still be required
HodlHodl	Yes (email + password)	In a dispute, or on fraud/AML suspicion; refusal can suspend the account
Bisq 2 (Easy)	Yes (no central account)	Never to the platform; a counterparty may see payment details in a dispute
RoboSats	Yes (Tor, random robot identity)	Never to the platform
Peach	Yes, up to a low daily ceiling	Above the no-KYC limit, or if you opt in for higher volume (Swiss rules)
Vexl	Yes (built on your contacts)	Never — but no escrow protects you either

One detail the privacy-minded should weigh: because Peach operates as a regulated Swiss company, it states that it retains certain dispute, device, and payment data for ten years after account deletion to meet Swiss anti-money-laundering law. “No-KYC” and “no record” are not the same promise.

Where Your Coins Actually Sit — The Custody Question
#

Every P2P market headlines the word “non-custodial,” but that single phrase compresses four very different escrow designs — and the design, not the marketing, determines what can go wrong. The question that actually matters is who can move your coins during the minutes or hours a trade is open. I treat the escrow model as the first question, before the brand, because it is the one thing you cannot fix after a trade goes wrong.

There are four models in play across these markets, and they sit on a spectrum from “a mediator who cannot act alone” to “no escrow at all.” Multisig escrow locks the coins in an address that requires multiple signatures to move; a Lightning hold-invoice locks a payment that only settles on confirmation; a reputation model forgoes central escrow for social stake; and an introduction service holds nothing whatsoever.

Marketplace	Escrow model	Who can move funds mid-trade	If it fails
HodlHodl	2-of-3 multisig	Any two of {you, counterparty, HodlHodl}	HodlHodl mediates but cannot take funds alone
Peach	2-of-2 multisig	Both you and the counterparty	Neither can act alone — a dispute needs both to cooperate (deadlock risk)
RoboSats	Lightning hold-invoice	Coordinator locks; releases on confirmation	Funds are exposed only during the settlement window (default ~3 hours)
Bisq 2 (Easy)	Reputation / security deposit	You hold your keys throughout	Trust is reputation-weighted; designed for small amounts
Vexl	None — introduction only	You, always	No escrow; you settle directly, protected only by social trust

The takeaway is that “non-custodial” is necessary but not sufficient information. A 2-of-3 multisig gives you a mediator who can break a deadlock but cannot rob you; a 2-of-2 removes the third party entirely but means a vanished or uncooperative counterparty can freeze the trade; a hold-invoice keeps your exposure to a short window; and a pure introduction app like Vexl gives you no recourse at all if the other person simply does not pay. None of these is “safest” in the abstract — each trades one risk for another.

Five No-KYC Markets, Compared
#

The five marketplaces still worth using in 2026 occupy genuinely different niches — Lightning-native privacy, regulated mobile convenience, desktop self-custody, strong multisig escrow, and pure social introduction — so the right pick depends on your trust model, not on a single ranking. Here is the head-to-head, followed by the honest one-line version of each.

Marketplace	Custody	No-KYC limit	Regulatory posture	Rails	Active in 2026?
HodlHodl	2-of-3 multisig	None (but ID on dispute)	UK company (Hodlex Ltd)	On-chain + Lightning	Yes — operating since 2016
Bisq 2 (Easy)	Reputation / deposit	None	No license sought	On-chain (+ Lightning)	Yes — desktop, with a new Android app
RoboSats	LN hold-invoice	None	No central entity (federation)	Lightning-native	Yes — active development, multi-coordinator
Peach	2-of-2 multisig	Low daily ceiling	Swiss company, FINMA-regulated	Mobile-first, 100+ fiat methods	Yes
Vexl	None (social graph)	None	Czech (SatoshiLabs group)	You arrange directly	Yes — tens of thousands of users

HodlHodl is the veteran: a web platform with 2-of-3 multisig escrow and a human mediation team, running since 2016, with the deepest liquidity of this group. The trade-offs: it can demand ID in a dispute, and it blocks US residents.
Bisq 2 (Bisq Easy) is desktop-first, self-custodial, and routes over Tor (the anonymity network) by default. Bisq Easy is a reputation-based protocol built deliberately for small purchases, with no central escrow — convenience and privacy in exchange for not being the venue for large trades.
RoboSats is the Lightning-native privacy choice: Tor-only, throwaway robot identities, and a hold-invoice escrow. In 2026 it runs as a federation — multiple independent coordinators under one client — which is resilient but means you choose a coordinator and inherit its reputation.
Peach is the mobile, regulated option: a Swiss company with 2-of-2 multisig, 100+ fiat payment methods, and a no-KYC ceiling of about CHF 1,000 per day (CHF 1,000 per month for anonymous methods like cash, and CHF 100,000 per year) under Swiss law. Best for small, regular buys; least friction; most regulatory baggage (including the ten-year data retention noted above).
Vexl is the outlier: a no-escrow app from the SatoshiLabs group that matches you with people in your extended contact network. It holds nothing and tracks nothing — which also means it offers no escrow protection. It is for trades where you already trust the other side.

When a Trade Goes Wrong — Dispute Resolution Compared
#

The moment that separates a sound marketplace from a dangerous one is not the happy-path trade — it is the dispute, and here the escrow models diverge sharply. One of them carries a deadlock risk that almost no review mentions, and two offer no published timeline at all. Before you send fiat to a stranger, you should know exactly who arbitrates and how long your coins can be frozen.

Marketplace	Who arbitrates	Stated timeline	The risk to know
HodlHodl	HodlHodl mediation team	Up to 60 days; ~12h first response	ID can be demanded as dispute evidence
Peach	Needs both parties (2-of-2)	Not published	Deadlock if a party vanishes; data kept 10 years
RoboSats	The coordinator you chose	Not published — coordinator-dependent	You must vet the coordinator’s reputation yourself
Bisq 2 (Easy)	Reputation-based mediation	Not published	Payment details may be revealed; small-amount design
Vexl	No arbitration	—	No recourse — social trust is the only protection

HodlHodl is the only one of the five that publishes a concrete dispute policy — a mediation team, a 60-day ceiling, and a roughly 12-hour first response — which is a meaningful advantage even though that same process is where ID can be requested. RoboSats’ federation is resilient against any single coordinator being taken offline, but it pushes a real burden onto you: dispute handling is only as good as the specific coordinator you picked, and there is no network-wide service-level guarantee. And Peach’s 2-of-2 design, elegant as it is for removing the middleman, means a dispute requires the counterparty’s cooperation to resolve — a counterparty who disappears can leave coins stuck.

What Changed in 2026 — and the Markets That Died
#

A no-KYC guide is only as safe as its freshness, because this corner of Bitcoin churns fast. Two facts reorder the 2026 landscape: a serious security incident on a long-trusted platform, and the quiet death of three services that old lists — and even AI answers — still recommend. When I re-checked the names that still top “best no-KYC” results, the gap between the lists and reality was wide enough to lose money in.

Start with the incident, stated plainly because it matters to anyone weighing Bisq:

On May 1, 2026, an attacker exploited a trade-protocol validation bug in Bisq v1 and stole 11.59 BTC from a small number of users. The project reimbursed those affected and hardened the protocol in v1.10.0 (May 16, 2026). Bisq 2 (Bisq Easy) is a separate implementation and was not affected — but its own security hardening is slated to finish around August 2026, so “Bisq 2 is hardened” is a not-yet, not a fact.

The lesson is not “avoid Bisq” — the team disclosed the bug, reimbursed users, and shipped a fix, which is more than most platforms manage. The lesson is to run the current client, keep Bisq Easy to small amounts as designed, and not assume a separate codebase inherits a maturity it has not yet reached.

Then there are the ghosts. Old guides, and some current AI summaries, still send people to markets that no longer exist:

LocalBitcoins closed on February 17, 2023. LocalMonero shut down in 2024. Paxful ceased operations on November 1, 2025. Searching their names can surface phishing clones trading on a dead brand’s trust. Verify you are on a live, official service before you send anything — a wound-down or impersonated platform is one of the easiest ways to lose funds in this space.

One more name belongs in the “verify first” column rather than the comparison: AgoraDesk, the successor to LocalMonero, announced a shutdown in 2024 and its current status is unclear, and it is Monero-first rather than Bitcoin-first — so I left it out of the table above rather than recommend a service whose availability I could not confirm. That same discipline — never send to a service you have not confirmed is live — is the cheapest safety habit in this entire guide.

There is a deeper reason all of this churns: the legal pressure documented in how Bitcoin on-chain tracing works in 2026 fell on coordinators and money transmitters, and the markets built to survive it are the coordinator-less and self-custodial ones. Buying without KYC is also only half of staying private — if you reattach your identity the moment those coins touch a reused address, or describe the trade in a forum post a model can read, the privacy is gone. The on-chain half is in that same guide; the off-chain, inference half is how AI-scale deanonymization undoes the privacy you thought you had.

Bottom Line — Which Is Right for You?
#

There is no single “best” no-KYC market; there is the one that fits your trust model — how much you value Lightning privacy, how large your trades are, how much escrow protection you need, and whether you already trust the counterparty. Define that first, because the wrong match is where people lose either privacy or funds. Match the market to your situation, not to a ranking.

Small, regular buys with the least friction: Peach (mobile, 100+ fiat rails, a no-KYC daily ceiling) or Bisq Easy (reputation-based, built for small amounts). Both accept the trade-off of modest limits for convenience.
Maximum privacy, Lightning-native: RoboSats — Tor-only, throwaway identities, short escrow exposure. Accept that you must choose and trust a coordinator, and there is no published dispute timeline.
Larger trades and the strongest escrow: HodlHodl — 2-of-3 multisig and a real mediation process. Accept that ID can be demanded in a dispute and that US residents are blocked.
You already trust the counterparty (a friend, a meetup): Vexl — but go in clear-eyed that there is no escrow; the social graph is the only protection.

Whichever you choose, the sequence is the same: confirm the service is live, judge it by its escrow and dispute model rather than its star rating, keep early trades small, and — once you hold coins acquired without KYC — protect them on-chain so you do not undo at the ledger what you protected at the point of purchase. The framework for that last step is the companion to this one: think in terms of your threat model in the AI age, then defend the specific links that matter to you.

Key Takeaways

Old lists are dangerous: LocalBitcoins (2023), Paxful (2025), and LocalMonero (2024) are gone — a search can still surface a clone of a dead brand, which is a live way to lose funds.
“Non-custodial” hides four escrow models: 2-of-3 multisig (HodlHodl), 2-of-2 (Peach), a Lightning hold-invoice (RoboSats), and none at all (Vexl) — the model decides what can go wrong.
“No-KYC” is not absolute: HodlHodl can demand ID in a dispute, Peach is no-KYC only up to a low daily ceiling, and Peach retains dispute data for ten years under Swiss law.
Bisq’s 2026 incident is real but handled: Bisq v1 lost 11.59 BTC to a protocol bug in May 2026 (users reimbursed; fixed in v1.10.0); Bisq 2 is a separate codebase with its own hardening due around August 2026.
Match the market to your trust model: RoboSats for Lightning privacy, Peach or Bisq Easy for small buys, HodlHodl for stronger escrow, Vexl only when you already trust the counterparty.

Frequently Asked Questions
#

Is it legal to buy Bitcoin without KYC?
#

This is not legal advice, and it depends on your jurisdiction and conduct. In most places, buying bitcoin peer-to-peer is lawful, and the 2024–2025 U.S. prosecutions targeted the operators of mixing and money-transmission services, not individuals seeking transactional privacy. But obligations like tax reporting still apply to you regardless of how you acquired the coins — consult a qualified professional for your situation.

Is Bisq still safe to use after the May 2026 hack?
#

The exploit affected Bisq v1, where a trade-protocol validation bug let an attacker steal 11.59 BTC from a small number of users; the project reimbursed them and hardened the protocol in v1.10.0. Bisq 2 (Bisq Easy) is a separate implementation that was not affected, though its own security work is due to finish around August 2026. If you use Bisq, run the latest client and keep Bisq Easy trades small, as the protocol is designed for.

What is the safest escrow model for a P2P trade?
#

It depends on the risk you most want to avoid. A 2-of-3 multisig (HodlHodl) adds a mediator who can break a deadlock but cannot take your funds alone. A 2-of-2 multisig (Peach) removes the third party entirely but can deadlock if a counterparty disappears. A Lightning hold-invoice (RoboSats) limits your exposure to a short settlement window. No escrow at all (Vexl) means social trust is your only protection.

Which no-KYC market is best for small amounts?
#

Peach and Bisq Easy are both built for small, regular buys. Peach is mobile-first with a no-KYC daily ceiling and many fiat payment methods; Bisq Easy is a reputation-based, desktop protocol with no central escrow. For Lightning-denominated privacy on small sums, RoboSats is the strongest privacy option.

Do these still work now that LocalBitcoins and Paxful have shut down?
#

Yes. HodlHodl, Bisq, RoboSats, Peach, and Vexl are all active in 2026. The caution is the opposite: LocalBitcoins (2023), Paxful (2025), and LocalMonero (2024) have closed, so verify you are on a live, official service — clones trading on a dead brand’s name are a common way people lose funds.

#	Source	URL	Archived
1	Bisq — “Where Bisq Stands After the Security Incident” (May 2026)	https://bisq.network/blog/where-bisq-stands-after-security-incident/	https://web.archive.org/web/*/https://bisq.network/blog/where-bisq-stands-after-security-incident/
2	LocalBitcoins — Service closure notice (Feb 2023)	https://localbitcoins.com/service_closure/	https://web.archive.org/web/*/https://localbitcoins.com/service_closure/
3	Paxful — Closure announcement (Nov 2025)	https://paxful.com/blog/paxful-closure-announcement	https://web.archive.org/web/*/https://paxful.com/blog/paxful-closure-announcement
4	RoboSats — Escrow documentation (Lightning hold-invoice)	https://learn.robosats.org/docs/escrow/	https://web.archive.org/web/*/https://learn.robosats.org/docs/escrow/
5	RoboSats — Federation model	https://github.com/RoboSats/robosats/blob/main/federation.md	https://web.archive.org/web/*/https://github.com/RoboSats/robosats/blob/main/federation.md
6	Peach Bitcoin — How to buy BTC with no KYC	https://peachbitcoin.com/how-to-buy-btc-no-kyc/	https://web.archive.org/web/*/https://peachbitcoin.com/how-to-buy-btc-no-kyc/
7	HodlHodl — Dispute rules	https://hodlhodl.com/pages/dispute_rules	https://web.archive.org/web/*/https://hodlhodl.com/pages/dispute_rules
8	Bisq — Bisq 2 / Bisq Easy (wiki)	https://bisq.wiki/Bisq_2	https://web.archive.org/web/*/https://bisq.wiki/Bisq_2
9	LocalMonero / AgoraDesk — wind-down coverage (2024)	https://www.tftc.io/agoradesk-shuts-down-after-seven-years/	https://web.archive.org/web/*/https://www.tftc.io/agoradesk-shuts-down-after-seven-years/

When the Government Leaks Your Data: A 2026 Defense Playbook

Fri, 12 Jun 2026 00:00:00 +0000

You can delete a social media account. You cannot delete yourself from the tax authority, the health service, or the national ID database. The data you hand to a government is not a choice you get to reconsider — it is the price of existing as a citizen. That asymmetry is the whole problem. When a company loses your data you can, at least in principle, leave. When the state loses it, you are still required to keep handing over more.

And in 2026, the state is losing it at scale. In a single span of weeks this spring, a contractor to CISA, the United States’ own cyber-defense agency, left administrative keys to government cloud systems sitting in a public code repository for six months; a federal health agency published doctors’ Social Security numbers in an online directory; and Britain’s National Health Service (the NHS) confirmed that a private analytics company’s staff could reach identifiable patient records. None of these were sophisticated nation-state attacks. They were ordinary institutional failures — the kind that recur because the incentives that produce them never change.

So if you cannot prevent the leak and cannot withhold the data, what can you actually do? This is not a guide to trusting better institutions. I wrote it as a playbook built on a clear threat model — a plain account of what you are protecting, from whom, and what happens when it leaks — and on one assumption: every database holding your data will eventually be breached, so your defense has to live in layers you control, not in the institution’s promises.

The Three Failures of 2026
#

Start with the evidence, because the pattern only becomes actionable once you see it repeat. Three documented 2026 incidents, across two governments and the public-private boundary, show the same structural weakness from three angles. A breach here means sensitive data became reachable by someone who should not have had it — whether through error, exposure, or over-broad access.

Incident	What was exposed	Root cause	Status
CISA contractor GitHub leak	Admin keys to 3 government cloud accounts + plaintext passwords (844 MB)	Contractor synced work files via a public repo, with secret-scanning disabled	Repo removed; agency review ongoing
CMS Medicare directory	Medical providers’ Social Security numbers	SSNs typed into the wrong field of a public database	Portal taken offline
Palantir × NHS access	Identifiable patient records reachable by a vendor’s staff	Contractual admin access, not a hack	Contract active; access ongoing

The CISA leak is the clearest case. A contractor to the Cybersecurity and Infrastructure Security Agency — the very body charged with defending American networks — maintained a public repository on GitHub (a popular code-hosting site) containing administrator credentials for three government cloud accounts, plaintext password files, signing certificates, and access tokens: roughly 844 megabytes of internal material. According to KrebsOnSecurity, the employee was using the repo to sync files between work and home machines and had deliberately turned off the platform’s built-in protection that blocks secrets from being uploaded. The exposure ran roughly six months before the security firm GitGuardian discovered it; the cloud keys reportedly stayed valid for about 48 hours after the repo came down.

The CMS leak shows the same carelessness with the one identifier you can never replace. The Centers for Medicare and Medicaid Services (CMS — the U.S. agency that runs public health insurance for older and lower-income Americans) published a new public directory of Medicare providers — and, as The Hill reported after the Washington Post first surfaced it, at least dozens of those providers’ Social Security numbers — later reported as more than a hundred — were exposed because the numbers had been entered into the wrong field. The agency pulled the portal offline. A Social Security number is the closest thing Americans have to a permanent skeleton key for identity; once it is public, it stays compromised for life.

The Palantir–NHS case is different in kind, and the distinction matters. This was not a hack. As The Register reported, NHS England confirmed that staff at Palantir — the U.S. data-analytics company running its £330 million Federated Data Platform (the NHS’s central patient-data system) — could hold administrative access to identifiable patient information. No attacker was needed; the access was written into how the system works. The civil-society group Medact documented the resulting concern, and Greater Manchester remained the one regional body refusing to join. The lesson is not “a villain broke in.” It is that concentrating a nation’s health records under a single vendor is itself the exposure, before anyone misuses it.

These are not the only ones. Step back a year and the same shape appears again: beginning in late 2024 and discovered in early 2025, the government contractor Conduent — which runs Medicaid, child-support, and food-assistance systems for multiple states — was breached, exposing the Social Security and health data of more than 25 million Americans. Its systems were restored, though litigation continues and the leaked identifiers do not expire. Several incidents this spring, one the year before, two countries, public and private: the actors change and the failure does not.

Why Governments Leak Structurally
#

The comfortable explanation is bad luck — a careless employee, a typo, a bad vendor. The useful explanation is that these are not accidents but outputs of how the systems are built. Four structural forces make government data leakage close to inevitable, and naming them is what lets you defend against the category rather than chasing each headline.

Structural force	Mechanism	Seen in
Contractor dependence	Responsibility diffuses with every handoff to an outside vendor	CISA keys held by a contractor; NHS data held by Palantir
Shadow IT	Unsanctioned tools route secrets around the safeguards	The contractor’s public GitHub repo
Aggregation	One error exposes millions once records are centralised	NHS platform; Conduent’s 25M records
Asymmetric accountability	The institution pays a fine; you inherit the permanent risk	All three 2026 cases

Contractor dependence diffuses responsibility. Modern states do not run most of their own technology; they hire it out. The CISA keys sat with a contractor; the NHS records sit with Palantir; the 25 million records sat with Conduent. Each handoff adds an organisation whose security you cannot see and whose incentives are not yours. The agency owns the consequence; the contractor owns the laptop.

Shadow IT — the tools people use without approval — routes secrets around the safeguards. The CISA employee’s public repo was shadow IT: an unsanctioned convenience that bypassed every control the agency thought it had. Whenever a process is too slow, humans build a faster path beside it, and the faster path rarely has the guardrails.

Aggregation turns a small mistake into a catastrophe. When records are scattered, an error exposes a few. When a federated platform or a national directory concentrates them, the same error exposes millions. Centralisation is sold as efficiency; it is also a single point of catastrophic failure.

Accountability is asymmetric. When a breach happens, the institution issues a statement, perhaps pays a fine, and continues. You inherit the permanent risk. This imbalance is the deepest reason to assume breach: the party that loses your data does not carry the cost of losing it, so it never has enough reason to stop.

Put these together and the conclusion is not cynicism — it is design guidance. You cannot reform four structural forces from the outside. You can build a personal architecture that expects them to fail.

The Defense Architecture: Assume 100% Breach
#

Here is the part no breach-response checklist gives you, because it cannot be sold as a one-time fix: a standing architecture that assumes every institution holding your data will eventually lose it. Think of it as five layers, ordered from mindset to mechanics. You will not complete all five at once; you build them the way you build any defense, one layer at a time, strongest where your exposure is greatest.

Layer 1 — Adopt the assume-breach mindset. A threat model is simply a clear answer to “what am I protecting, from whom, and what happens if it leaks?” The shift here is to stop modelling institutions as safe and start modelling them as temporary custodians of data that will eventually escape. This is not paranoia; it is what the 2026 record shows. Once you assume the database will leak, every later decision — what you submit, under which identity, with what fallback — gets easier.

Layer 2 — Minimise what you hand over. You cannot refuse the tax authority, but most data extraction is not legally mandatory. The loyalty programme, the optional profile field, the “verify with your ID” prompt on a service that does not need it — each is a reservoir that can leak later. Treat every optional disclosure as a future breach notification with your name on it. The single most effective privacy control is the data that was never collected. For a practical audit of what has already escaped from years of social media use — and why deletion rarely erases it — see how permanent your social media footprint really is.

Layer 3 — Compartmentalise your identity. I keep a different email address for each major context — finance, health, public life — so that one leaked database cannot be joined to the others. A password manager such as the open-source Bitwarden makes unique credentials per site practical, and a provider like Proton Mail supports per-service aliases that you can burn if they leak. Compartmentalisation does not stop a breach; it stops one breach from becoming all of them. (For the deeper version of this — pseudonyms and jurisdictional separation — see Cora’s work on self-sovereign identity.)

Layer 4 — Lock down the identifiers you cannot change. Some data is permanent: your Social Security number, your date of birth, your biometrics. Because you cannot rotate them, you defend them at the point of use. In the United States, freeze your credit at all three major credit bureaus — the firms that hold your borrowing history: Equifax, Experian, and TransUnion — which blocks new accounts being opened in your name; it is free and reversible. Add fraud alerts. And move your important logins to hardware-based multi-factor authentication (a physical security key, the strongest second factor), so a stolen number alone cannot open the door. This is the one layer where the breach-response checklists and this architecture agree — the difference is that here it is permanent hygiene, not a panic reaction.

Layer 5 — Separate your tools and jurisdictions. Spread your trust across providers and legal regimes that are not all reachable by the same actor. Encrypted messaging for sensitive conversation, a no-logs VPN (Virtual Private Network) such as Mullvad to break the link between your network and your activity, and storage that is not concentrated under one company or one government. The goal is that no single breach, subpoena, or vendor relationship exposes the whole picture.

Notice what this architecture does not require: it does not require the institution to be trustworthy. That is the point. Each layer is a control you hold, not a promise you are given.

If You’re Already Exposed
#

If your data is in one of these breaches — and statistically, it already is — the immediate steps are narrow but worth doing today, before the standing architecture above. These are the steps I treat as non-negotiable; treat this as triage, not the whole treatment.

Freeze your credit at all three bureaus (free, online, reversible). This is the highest-leverage single action.
Set fraud alerts on your financial accounts and turn on transaction notifications.
Assume permanent identifiers stay compromised. A leaked Social Security number does not expire; rotate everything you can (passwords, account numbers) and defend the rest at the point of use.
Move to hardware MFA on email and finance first — email is the recovery path for everything else.
Watch for targeted phishing. Breached data makes scams personal; a caller who knows your real details is using leaked data, not proof of legitimacy.

These steps close the immediate window. The layered architecture is what keeps the next breach — and there will be a next one — from costing you the same way twice.

Key Takeaways

Assume breach: You cannot opt out of giving the state your data, so model every government database as a temporary custodian that will eventually leak.
The pattern is structural: Contractor dependence, shadow IT, aggregation, and asymmetric accountability made the 2026 CISA, CMS, and Palantir-NHS failures predictable — not unlucky.
Defend in layers you control: Minimise disclosure, compartmentalise identity (unique emails + password manager), and lock down permanent identifiers (credit freeze + hardware MFA).
No reliable legal remedy: Sovereign immunity and damage caps make breach litigation slow and uncertain — your layered architecture is the remedy you actually control.
Triage today, architecture tomorrow: If you’re already exposed, freeze credit and move to hardware MFA now; then build the standing five-layer defense.

Frequently Asked Questions
#

Can I sue the government for leaking my data?
#

Sometimes, but it is rarely a remedy you can count on. Sovereign-immunity rules, caps on damages, and the difficulty of proving specific harm make government breach litigation slow and uncertain. Treat legal action as a possible afterthought, not a defense — your layered architecture is what actually reduces your exposure.

Is freezing my credit enough?
#

No, but it is the best single action. A credit freeze blocks most new-account fraud, yet it does nothing for medical-identity theft, tax fraud, or the misuse of a leaked Social Security number outside credit applications. Pair it with fraud alerts, hardware MFA, and identity compartmentalisation.

If the data is already leaked, isn’t defense pointless?
#

No. Most harm from a breach happens after exposure, when leaked data is used to open accounts, impersonate you, or craft targeted scams. Freezing credit and hardening your logins blocks the exploitation step even when the underlying data is already out.

Does this only apply to the United States?
#

The specifics differ — credit freezes are a U.S. mechanism, and the NHS case is British — but the architecture is universal. Every country aggregates citizen data and outsources its handling. Minimisation, compartmentalisation, and protecting permanent identifiers apply wherever you live.

References
#

#	Source	URL	Archived
1	CISA Admin Leaked AWS GovCloud Keys on GitHub — KrebsOnSecurity	https://krebsonsecurity.com/2026/05/cisa-admin-leaked-aws-govcloud-keys-on-github/	archived
2	How We Got a CISA GitHub Leak Taken Down — GitGuardian	https://blog.gitguardian.com/how-we-got-a-cisa-github-leak-taken-down-in-26-hours/	archived
3	CMS Publishes Social Security Data — The Hill	https://thehill.com/policy/healthcare/5860959-cms-publishes-social-security-data/	archived
4	Medicare Portal Exposed Providers’ SSNs — Washington Post	https://www.washingtonpost.com/health/2026/04/30/medicare-portal-social-security-numbers-exposed/	archived
5	NHS England Confirms Palantir Staff Can Access Patient Data — The Register	https://www.theregister.com/databases/2026/05/12/nhs-england-confirms-palantir-staff-can-access-patient-data/5238712	archived
6	Briefing: Palantir and NHS Data Systems — Medact	https://www.medact.org/2026/resources/briefings/briefing-palantir-fdp/	archived
7	Right to Erasure (Art. 17) — GDPR	https://gdpr-info.eu/art-17-gdpr/	archived

We Watched the AI Crawlers: A 17-Day Log Study (2026)

Wed, 08 Jul 2026 00:00:00 +0000

Every guide to keeping AI models out of your writing ends at the same three levers: add the crawler’s name to robots.txt (the text file that politely asks bots what not to visit), publish an llms.txt (a newer, AI-specific version of the same idea), or tell your host to “block GPTBot.” All three assume the same thing — that the bot knocking at your door is who its user-agent says it is. A user-agent is just a line of text a program sends to announce itself; it is typed, not proven, and anything can type anything.

So we stopped theorizing and looked. For 17 days — June 19 to July 5, 2026 — we recorded every self-identifying AI crawler that touched this site: 1,635 requests across 14 different commercial AI user-agents, from ClaudeBot and GPTBot down to names most publishers never see. Then we did the step the advice skips: we checked each request’s real source address against the address list the named company itself publishes. The result splits cleanly into three groups, and only one of them is good news. This is the measurement behind a promise we made earlier — that we keep this site’s own crawler logs under watch — and it is the empirical floor under the enclosure of the open web we argued elsewhere.

The uncomfortable finding is not that AI crawlers lie. It is that the ones you most want to stop are exactly the ones your tools cannot touch — because the whole opt-out regime works only when the crawler is both honest enough to obey and transparent enough to be checked. Below is what 17 days of one small site’s logs revealed about which is which.

What We Measured, and How You’d Reproduce It
#

We collected 17 consecutive days of edge logs, grouped every request by its user-agent string, and kept the 14 that name a commercial AI system. That is the raw claim — a bot said “I am GPTBot.” Verification is a separate, harder question, and it has an objective answer: does the request’s source IP fall inside the address range that OpenAI, Anthropic, Google or Amazon publishes for its own crawler? Every major operator posts that list precisely so servers can tell a real bot from an impostor.

The 1,635 hits sorted into a sharp hierarchy. The full per-agent tally ships with this article as a plain-text summary — aggregate counts only, no visitor data, crawler networks named only at the /24 level — a /24 being a block of 256 consecutive IP addresses, the smallest unit these networks are handed out in (verification summary).

AI user-agent	Requests (17 days)	Verifies against published IPs	Verification source (as of)
ClaudeBot	553	546 (99%)	Anthropic bot list (2026-05)
Amazonbot	344	120 (35%)	Amazon crawler IPs (2026-04)
GPTBot	310	301 (97%)	OpenAI GPTBot list (2025-10)
meta-externalagent	179	no method published	—
Bytespider (ByteDance)	112	no method published	—
PerplexityBot	24	5 (21%)	Perplexity bot list (2025-02)
GoogleOther	12	12 (100%)	Google crawler list (2026-06)

Seven more low-volume agents — another 101 requests — round out the 14; the full list is in the summary file.

A verified request is one whose source IP the named company vouches for. The percentages are weighted by request count, and where a bot’s volume is small we say so outright — PerplexityBot’s “21%” is 5 hits out of 24, too thin to indict a company on, and we treat it that way below. Two caveats bind every number here: this is one new, low-traffic site over 17 days, not the whole web; and a published address list is only as current as its date — Perplexity’s is 17 months old, which we return to.

The Declared Crawlers Are Mostly Real
#

Start with the good news, because it is real and it matters: when a big lab’s crawler announces itself, it is almost always telling the truth. GPTBot verified at 97%, ClaudeBot at 99%, and GoogleOther at 100% against each company’s published address ranges. The overwhelming majority of “GPTBot” and “ClaudeBot” traffic genuinely originated from OpenAI and Anthropic infrastructure. One caution for anyone here to opt out of AI training specifically: GoogleOther is a general-purpose Google crawler, a different token from Google-Extended, the one that actually governs Gemini training — and every Google-Extended hit we logged came from the spoof cluster below, not from Google.

This is the part the cynical take gets wrong. If you add GPTBot to your robots.txt or block Anthropic’s ranges at your edge, you will stop the real GPTBot and the real ClaudeBot — they publish their addresses (OpenAI, Anthropic), they respect the file, and independent network-wide data agrees the large declared crawlers are the dominant players — even as their individual shares shift from year to year (Cloudflare, 2025). The honest crawler is a solved problem. If every AI bot behaved like GoogleOther — named, ranged, checkable — this article would be a footnote.

One declared crawler resists this clean sorting, and honesty requires naming it. Only 5 of our 24 PerplexityBot hits matched Perplexity’s published range — but 24 hits is far too thin to judge a company by, and Perplexity’s list is itself 17 months old, so a miss may mean nothing more than a stale file. There is a live dispute in the background: Cloudflare reported in August 2025 that Perplexity used stealth, undeclared crawlers to slip past no-crawl rules (Cloudflare, 2025), and Perplexity publicly rejected that framing (Perplexity, 2025), arguing a user-prompted “agent” fetching a page on demand is not the same thing as a pre-emptive “bot,” and that Cloudflare had misattributed to it the traffic of a third-party cloud-browser service. From an IP address alone we cannot tell an outside impostor from a company’s own undeclared fetcher — so on 24 hits we conclude nothing about Perplexity, and simply flag it as the declared crawler our checks verify least well.

The number that stayed with us is a different, sharper one: the tiny remainder among the crawlers that did verify. ClaudeBot’s 7 unverified hits and GPTBot’s 9 were not random noise. Every one of them traced back to the same place — a place that had no business claiming either name.

One Network Wore Fourteen Faces
#

Here is the finding that named the article. Four of those address blocks — four /24s — sat entirely outside every company’s published range, and in 17 days those four blocks alone produced 99 requests carrying 14 different AI companies’ user-agents. One /24 — 185.213.174.0/24 — impersonated all fourteen by itself: GPTBot, ClaudeBot, PerplexityBot, Amazonbot, Google-Extended, Bytespider, cohere-ai and seven more, all from one small network.

Now put that beside a legitimate range. Two adjacent Anthropic blocks — 216.73.216.0/24 (281 requests) and its neighbour 216.73.217.0/24 (265) — sent 546 requests between them, and every single one said ClaudeBot: one entity, one identity, whichever block you inspect. Look up who owns each network, and the contrast finishes the thought. Ownership comes from RDAP, the public registry that maps an IP to the organization it was assigned to:

Network (/24)	What it claimed	Registered to (RDAP)
`216.73.216.0/24`	ClaudeBot, 281× — nothing else	Anthropic, PBC (US)
`185.213.174.0/24`	14 different AI companies	NextGenWebs, a web host (NL)
`45.45.237.0/24`	part of the spoof cluster	Infraly, LLC (US)
`23.161.169.0/24`	part of the spoof cluster	Infraly, LLC (US) — same owner
`154.58.229.0/24`	part of the spoof cluster	Limestone Networks (US)

The legitimate blocks sit inside Anthropic’s own published range — and the one we resolved in RDAP comes back as Anthropic, PBC. The impersonating subnets are registered to commercial hosting companies — infrastructure anyone can rent by the hour — and two of the four trace to the same rented company, the signature of a single operator running one costume box. A real crawler carries one identity because it is one entity. A spoofer wears all the faces because the face is the cheap part. The user-agent is not an ID card; it is a costume, and robots.txt is a sign that only the costumed can choose to read.

Amazonbot: The Bot You Can’t Tell From a Rented Server
#

Amazonbot is where verification gets genuinely hard, and it is instructive precisely because Amazon is not hiding. The company publishes a crawler address list like the others — yet only 35% of our 344 “Amazonbot” hits (120 of them) matched it. The other 65% — 224 requests from 179 distinct addresses — did not appear on Amazon’s list at all.

The reason is structural. Amazon’s real crawler runs on the same cloud — AWS EC2 — that anyone can rent, so an impostor on EC2 looks, at the network layer, a lot like the real thing. Amazon’s own answer to this is a second check: a reverse-DNS test (FCrDNS — confirm the IP’s name resolves back to an official crawl.amazonbot.amazon host, in both directions). We ran it on a sample of 18 of the unmatched addresses. All 18 resolved to generic ec2-*.compute-1.amazonaws.com hosts — ordinary rented servers — and none to Amazon’s crawler domain (Amazon’s verification method). They were not new, unlisted Amazon IPs; they failed Amazon’s own test for being Amazon.

The lesson generalizes past one bot: a crawler that runs on rented cloud is the easiest to counterfeit, because the counterfeiter rents the identical cloud. Verification there cannot stop at an address list — it needs a cryptographic or DNS-anchored proof the operator controls. Amazon at least offers one. Some don’t offer anything.

The Crawlers You Cannot Check at All
#

The hardest group is not the liars — it is the crawlers you have no way to verify in either direction. meta-externalagent (Meta’s AI crawler) sent 179 requests and Bytespider (ByteDance’s) sent 112, and for neither company could we find a published IP range or an official reverse-DNS method to check a single one against. When we reverse-looked-up a sample of the Meta addresses (9 of them), they returned NXDOMAIN — no registered name at all. There is nothing to match, by design or neglect; you are asked to trust the header and given no way to.

This is the quiet core of the whole problem, and it is a privacy problem, not a webmaster’s inconvenience. The opt-out you were sold — robots.txt, “block the bot,” even the new llms.txt — is only as strong as your ability to tell whether it worked. It divides the world of AI crawlers into three, and your tools reach only the first:

Group	Who (in our logs)	Can you verify it?	Does opt-out work?
Published & honest	GPTBot, ClaudeBot, GoogleOther	Yes — address list + reverse DNS	Yes — the block lands
Named but uncheckable	meta-externalagent, Bytespider	No — no method published	Unknowable — you trust a header
Impostors	the spoof cluster (14 names, rented hosts)	No — and they claim to be everyone	No — they ignore the file entirely

And the newer, AI-specific fix fares no better on our own logs. We publish an llms.txt; across the 17 days, AI crawlers fetched our pages hundreds of times — GPTBot alone 310 times — and fetched the llms.txt file exactly zero times. A 300,000-domain study reached the same verdict at scale: llms.txt files show no measurable correlation with AI crawler behavior (SE Ranking, 2025). The standard the bots are asked to read, they are not reading.

Bottom Line — What Actually Protects You
#

If the goal is to keep your public writing, photos and posts out of AI systems, this 17-day slice says something plain and slightly bleak: the controls work best on the crawlers that would have behaved anyway, and not at all on the ones you most fear. That is not a reason to remove robots.txt — stopping the honest majority still matters, and it is the difference between your words entering the big models or not. It is a reason to stop mistaking the sign on the door for a lock.

Three honest conclusions follow. First, use the levers, but rank them by who obeys: robots.txt and edge-blocking the published ranges genuinely stop GPTBot, ClaudeBot and Google — that is most of the declared volume. Second, verify, don’t trust the label: if you act on your logs, check source IPs against operators’ published lists and reverse DNS, exactly as we did, rather than the user-agent string. Third — the load-bearing one — treat anything you publish in the clear as already readable by systems you cannot audit. The impostor cluster and the no-method crawlers are not going to honor a text file; the only durable privacy control is the choice of what enters the public record in the first place, the same permanence logic we mapped for posts you can’t unpublish and for what machines infer from fragments.

An emerging standard called Web Bot Auth aims to fix the costume problem at its root — cryptographic signatures a crawler cannot fake, so identity is proven instead of typed (Cloudflare, 2025). It is early and not widely adopted, and it will help only with crawlers that want to be identified. The ones wearing fourteen faces were never the target of a trust standard.

Key Takeaways

Declared big-lab crawlers are mostly genuine: over 17 days, GPTBot verified at 97%, ClaudeBot at 99% and GoogleOther at 100% against each company’s published IP ranges — so blocking them in robots.txt actually works.
The user-agent is a costume: four rented-hosting networks outside every published range wore 14 different AI companies’ names in 17 days; one /24 impersonated all fourteen, while two adjacent Anthropic blocks sent 546 requests between them under one name only.
Cloud-run crawlers are the easiest to fake: only 35% of “Amazonbot” hits matched Amazon’s list; the rest came from generic rented EC2 servers that failed Amazon’s own reverse-DNS check (18 of 18 sampled).
Some crawlers can’t be verified at all: Meta’s and ByteDance’s bots publish no IP list or reverse-DNS method — Meta’s addresses returned no registered name — so “opting out” of them is an act of faith.
The AI-specific fix isn’t being read: AI crawlers fetched our pages hundreds of times and our llms.txt zero times, matching a 300,000-domain study that found no measurable effect.

Frequently Asked Questions
#

Can you block AI crawlers with robots.txt?
#

Partly, and it depends entirely on the crawler’s honesty. In our 17-day logs, the big declared crawlers — GPTBot, ClaudeBot, GoogleOther — verified as genuine 97–100% of the time and do respect robots.txt, so listing them there stops them. But robots.txt is a voluntary request, not an enforced rule: a crawler that ignores it, or one wearing a fake user-agent, sails straight through. The file stops the polite and informs the honest; it means nothing to an impostor.

How do you verify an AI crawler is really GPTBot or ClaudeBot?
#

Don’t trust the user-agent string — check the source IP. OpenAI, Anthropic, Google and Amazon each publish the address ranges their crawlers use, so a real GPTBot request comes from an IP inside OpenAI’s published list. For crawlers on shared cloud (like Amazonbot on AWS), add a reverse-DNS check: confirm the IP’s hostname resolves back to the operator’s official crawler domain in both directions (FCrDNS). If a “GPTBot” hit comes from an address OpenAI never published, it is not GPTBot.

Does llms.txt keep AI out of my content?
#

On our evidence, no. We publish an llms.txt file, and over 17 days AI crawlers fetched our actual pages hundreds of times while fetching the llms.txt zero times — GPTBot read 310 pages and the file not once. A separate study of 300,000 domains found no measurable correlation between having an llms.txt and any change in AI crawler behavior. It is a proposed standard that the crawlers it addresses are largely not reading yet.

What is a spoofed AI crawler?
#

It is a request that carries a real AI company’s user-agent name but does not come from that company. In our logs, four commercial hosting networks — the kind anyone can rent — sent traffic labeled as 14 different AI companies, including one network that impersonated all fourteen by itself. Because a user-agent is just a text string the sender chooses, impersonation is trivial; only checking the source IP against published ranges tells you whether the name is earned or worn.

If I can’t stop every crawler, what actually protects my privacy?
#

The only control that survives an uncheckable or dishonest crawler is deciding what you make public in the first place. Robots.txt and blocking published ranges will stop the honest majority, which is worth doing. But for the crawlers you cannot verify — and the impostors who ignore every rule — assume that anything posted in the clear is already readable by systems you cannot audit, and treat publication itself as the decision point.

Sources
#

#	Source	URL	Archived
1	OpenAI — GPTBot and crawler documentation (with published IP list)	https://developers.openai.com/api/docs/bots	https://web.archive.org/web/*/https://developers.openai.com/api/docs/bots
2	Anthropic — Does Anthropic crawl the web, and how to block ClaudeBot	https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler	https://web.archive.org/web/*/https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler
3	Google — Verifying Googlebot and other Google crawlers	https://developers.google.com/search/docs/crawling-indexing/verifying-googlebot	https://web.archive.org/web/*/https://developers.google.com/search/docs/crawling-indexing/verifying-googlebot
4	Amazon — Amazonbot published IP address list	https://developer.amazon.com/amazonbot/ip-addresses/	https://web.archive.org/web/*/https://developer.amazon.com/amazonbot/ip-addresses/
5	Amazon (AWS re:Post) — How to identify and verify Amazonbot (FCrDNS)	https://repost.aws/questions/QUKdLk-sznTDOe-cyN-AyXGQ/how-to-identify-amazonbot	https://web.archive.org/web/*/https://repost.aws/questions/QUKdLk-sznTDOe-cyN-AyXGQ/how-to-identify-amazonbot
6	Cloudflare — From Googlebot to GPTBot: who’s crawling in 2025	https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/	https://web.archive.org/web/*/https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/
7	Cloudflare — Perplexity is using stealth, undeclared crawlers	https://blog.cloudflare.com/perplexity-is-using-stealth-undeclared-crawlers-to-evade-website-no-crawl-directives/	https://web.archive.org/web/*/https://blog.cloudflare.com/perplexity-is-using-stealth-undeclared-crawlers-to-evade-website-no-crawl-directives/
8	Perplexity — Agents or Bots? Making Sense of AI on the Open Web (response)	https://www.perplexity.ai/hub/blog/agents-or-bots-making-sense-of-ai-on-the-open-web	https://web.archive.org/web/*/https://www.perplexity.ai/hub/blog/agents-or-bots-making-sense-of-ai-on-the-open-web
9	Cloudflare — Web Bot Auth (cryptographic crawler identity)	https://blog.cloudflare.com/web-bot-auth/	https://web.archive.org/web/*/https://blog.cloudflare.com/web-bot-auth/
10	SE Ranking — llms.txt effectiveness study (300,000 domains)	https://seranking.com/blog/llms-txt/	https://web.archive.org/web/*/https://seranking.com/blog/llms-txt/

Our test artifact: the verification summary — aggregate per-user-agent request counts, verified counts, and network ownership at the /24 level, from the June 19–July 5, 2026 log window. No visitor data is included; crawler IPs are public infrastructure, disclosed no finer than /24.

A note on what this is and isn’t. This is one new, low-traffic site over 17 days — a case study, not a census. The percentages describe our logs, not the web. What generalizes is not the numbers but the method and its verdict: verify against published identity, and the world of crawlers splits into checkable and not. We will re-run the same measurement at the 90-day mark and publish the delta — whether the impostor cluster grows, whether the no-method crawlers ever become verifiable, and whether the honest ones stay honest.

This is the crawler-side companion to our argument that the open web is being enclosed — read more by machines than people — and the empirical follow-through on the AI-age threat model that opened this series. If you want to see what one of those machines could assemble about you from what is already public, our self-audit tool runs the same verify-don’t-trust discipline on your own footprint.

Bitcoin On-Chain Privacy in 2026: How Tracing Works

Mon, 22 Jun 2026 00:00:00 +0000

There is a comfortable myth that Bitcoin is anonymous money. It was never true, and in 2026 it is less true than ever. Every payment you have ever made sits in a public ledger that anyone can download, and a multi-billion-dollar industry exists to read it. The question that matters is not whether the chain can be analyzed — it always can — but where the link between a string of characters and your name actually gets made, and what you can do at each point.

I write under a pseudonym, so I treat my own coins as if a well-funded analyst is watching, because the assumption costs nothing and the alternative is irreversible. Here is the uncomfortable measure of the threat: blockchain analytics is a mature commercial field — firms like Chainalysis sell tracing tools to governments and exchanges, and the foundational academic work (Meiklejohn et al., 2013) collapsed roughly 12 million Bitcoin public keys into about 3.3 million ownership clusters using just two heuristics — over a decade ago, before the tooling matured. The ledger does not forget, and analysis only gets cheaper.

So is privacy hopeless? No — but it is conditional, and most guidance gets the conditions wrong. The honest answer is that on-chain privacy is a set of techniques that each protect one specific thing and ignore others, layered against a specific threat model. Below: how tracing actually works (with its real confidence limits), what the 2024 mixer prosecutions changed, and a clear-eyed table of what each 2026 tool does — and does not — protect.

The assumption	The reality	Where the link gets made
“My address is just random characters”	Addresses are permanent and publicly linkable	Clustering joins your addresses into one wallet
“I never posted my name”	Coins meet identity at the regulated edge	The KYC exchange where you bought or sold
“I used a privacy wallet, so I’m anonymous”	Each tool protects one layer, not all	Off-chain leaks the on-chain tools never touch
“Tracing is certain proof”	Heuristics carry confidence, not certainty	CoinJoin and PayJoin break the core assumptions

How On-Chain Tracing Actually Works
#

Chain analysis is the practice of de-anonymizing Bitcoin by applying statistical heuristics to the public ledger — not by breaking cryptography, but by exploiting patterns in how wallets spend. The single most important technique is the common-input-ownership heuristic: when several addresses are used together as inputs to one transaction, an analyst assumes they share one owner. That one assumption, applied across the whole chain, is what turns millions of disconnected addresses into a map of clustered wallets.

A few heuristics do most of the work, and the honest framing is that each carries a confidence level, not certainty:

Heuristic	Confidence	What it reveals	What breaks it
Common-input-ownership	High, on ordinary spends	Inputs spent together belong to one wallet	CoinJoin and PayJoin, where multiple owners share one transaction
Change detection	Moderate	Which output is your change — money your wallet returns to itself, not to the person you paid	Mixed script types (Legacy/SegWit/Taproot), identical output amounts
Address reuse	High, when present	Every transaction on a reused address, joined together	Modern wallets (Sparrow, Cake) generate a fresh address each time
Peeling chain	Moderate	A wallet moving funds in a repeating “pay a little, forward the rest” sequence	Raw data alone can’t reliably tell payment from change

Common-input-ownership is the backbone of clustering — and the very assumption that collaborative transactions are built to break. Change detection turns on a wallet detail worth understanding: when you spend part of a coin, the leftover change returns to a brand-new address your own wallet controls, not to the recipient — which is why one payment can create two addresses an analyst will then try to join into your cluster.

The honest framing — the one most guides skip — is that these are probabilistic attributions, not proof. A 2023 peer-reviewed analysis of peeling-chain patterns underscores how much depends on heuristics that degrade when spending patterns are unusual. That matters legally and practically: clustering narrows a suspect pool; it does not, by itself, name you.

Where Addresses Meet Identity
#

An address only becomes you when it touches a record that carries your name — and in 2026 that point is almost always a KYC exchange. Cryptographically, the chain is pseudonymous; the deanonymization happens at the regulated edge, where you proved your identity to buy or sell, and where that exchange retains a permanent mapping between your verified identity and the addresses you withdrew to. This is why “I never posted my real name” is a false comfort: you posted it to an exchange, under photo ID, the day you onboarded.

From that anchor point, tracing flows outward. The exchange knows the withdrawal address; clustering links that address to the rest of your wallet; and any later interaction with another regulated service re-confirms the identity. Data breaches make it worse — leaked KYC databases hand analysts the identity layer for free, which is the same off-chain-leak dynamic covered in how government and corporate data breaches expose you. And there is a second, entirely off-chain attack that on-chain tools do nothing about: a model can infer who you are from your writing — the forum posts where you describe your node, your timezone, your opinions. That inference chain is the subject of AI deanonymization, and it runs in parallel to chain analysis. The correct mental model is additive: on-chain privacy is necessary, and not sufficient.

What the 2024 Takedowns Actually Changed
#

In 2024 the legal ground shifted: U.S. prosecutors went after the coordinators of Bitcoin mixing services, and the privacy landscape reorganized around that pressure rather than disappearing. The lesson is not “privacy is dead” but “the architecture of privacy moved” — away from centrally coordinated mixing and toward designs with no coordinator to arrest. Two events define the shift.

In April 2024, the U.S. Attorney for the Southern District of New York arrested the founders of Samourai Wallet and charged them with money-laundering conspiracy and unlicensed money transmission; the service’s Whirlpool CoinJoin coordinator shut down (DOJ, 2024). Both founders later pleaded guilty and, in November 2025, were sentenced to five and four years in prison. Weeks after the original arrests, on June 1, 2024, zkSNACKs — the company coordinating Wasabi Wallet’s CoinJoin — suspended that service, citing regulatory uncertainty (zkSNACKs, 2024); Wasabi itself kept working. For a moment it looked like coordinated CoinJoin was finished.

It was not. Within days, independent community coordinators picked up the WabiSabi protocol that zkSNACKs had dropped, and coordinated Wasabi CoinJoins kept running (monitors like LiquiSabi track them in real time). The official coordinator left, the coordination decentralized. Popular summaries get two more things wrong, and the details change your choices:

“Silent Payments replaced CoinJoin and went mainstream.” Not quite. Silent Payments (covered below) solves a different problem — receiving privacy — and is best described in 2026 as emerging, not dominant. It does not mix amounts the way CoinJoin does, and it carries a real scanning cost for the receiver. It is a complement, not a drop-in replacement.
“JoinMarket is dying.” The opposite is closer to true. Because JoinMarket is coordinator-less — a peer-to-peer market of makers and takers with no central party to indict — its network kept running while the coordinated services were the ones taken down. (Its original repository was archived in April 2026, but a wire-compatible successor, joinmarket-ng, continues active development under OpenSats and HRF grants.) Its weakness is usability and liquidity, not legal fragility.

The durable takeaway: the 2024 prosecutions targeted coordinators and money transmission, not the act of holding private coins. Architectures that remove the coordinator (JoinMarket) or move the privacy to the protocol layer (Silent Payments) are the ones that survived the pressure.

The 2026 Privacy Toolkit: What Each Technique Does and Doesn’t Protect
#

There is no single “make Bitcoin private” switch. Each technique defends one layer — the receiving link, the transaction graph, the amount, the network path — and is silent on the others. Choosing well means matching tools to the specific link in the chain you most need to break, not collecting all of them. The table below is the honest version of the comparison most guides flatten into “use a privacy wallet.”

Technique	What it protects	What it does not touch	2026 status
Silent Payments (BIP-352)	Receiving privacy — a static address you can publish, with no on-chain link between payments to it	Amounts; the sender’s own privacy; off-chain identity	Emerging; receiver scanning cost; in Sparrow, Cake, others
PayJoin (BIP-78)	Breaks common-input-ownership — both parties contribute inputs, so clustering misreads it	Amount privacy; needs both parties online (a hosting hurdle)	Stable spec; async variant (BIP-77) easing the online requirement
CoinJoin (JoinMarket)	The transaction graph and amount correlation, via collaborative mixing	Off-chain leaks; the KYC anchor; UX is demanding	Network intact, coordinator-less; maintenance moved to joinmarket-ng (2026)
Lightning Network	Keeps payment amounts off the public chain entirely	`payment_hash` is shared along the route; node collusion can deanonymize	Mainstream; blinded paths (BOLT 12) improving routing privacy
Coin control / UTXO hygiene	Lets you avoid merging coins of different origins (defeats clustering you cause yourself)	Everything off-chain; nothing automatic	Built into Sparrow, Cake; the cheapest, most-skipped habit

A few honest caveats the table compresses. Silent Payments (BIP-352, Bitcoin Optech) is the most promising change to receiving privacy in years — you publish one reusable address and every sender derives a unique on-chain address for you, so observers see no common destination — but the receiver must scan the chain to find payments, which light-client implementations are still solving. For how to actually send and receive to one — the 2026 wallet landscape, the scanning cost, and a from-scratch verification of the protocol — see the Silent Payments hands-on guide. Lightning is genuinely better than on-chain for amount privacy, but it is not private by default (as a 2022 technical analysis detailed): every node on a payment’s route learns the same payment hash, and a colluding set of routing nodes — or a single node combining its position with channel probing — can identify sender or receiver with meaningful probability. And the cheapest technique — coin control, the wallet feature that lets you pick which coins (UTXOs, the discrete coin-units your wallet holds) go into a payment — is the one almost no one uses: simply not spending coins from a KYC source together with private coins prevents the clustering you would otherwise hand the analyst for free. Like your social media footprint, an on-chain mistake is permanent: there is no delete button for a transaction.

A Hands-On Baseline: Read the Chain the Way an Analyst Does
#

The fastest way to understand chain analysis is to do a little of it yourself, on a public block explorer, before anyone does it to you. You do not need paid tools — the same heuristics that power commercial tracing are visible to anyone reading a transaction’s inputs and outputs. I treat every coin I hold as already observed, and the habit started with an afternoon of reading my own transactions the way an adversary would.

Here is the reproducible method, using any public explorer (mempool.space, for instance — no account, no wallet connection):

Open a transaction and count inputs. Two or more inputs spent together is the common-input-ownership signal: an analyst will treat those addresses as one wallet. Ask whether that assumption is true for you — and whether you created it by merging coins.
Find the change. Two outputs, one of which is an odd, non-round amount returning to a fresh address of the same script type? That is almost certainly your change. Now the analyst has another address in your cluster.
Trace one hop back. Click an input’s previous transaction. If it came directly from a known exchange’s withdrawal pattern, the identity anchor is one hop away — that is the link that matters.
Spot a CoinJoin. A transaction with many inputs and many equal-value outputs is collaborative: the common-input-ownership heuristic misfires here by design, which is exactly why it raises an analyst’s uncertainty rather than confirming ownership.

When I first read my own transactions this way, what struck me was not what the chain revealed but how little it cost to see it — a free explorer, no special tools. Do this for ten transactions and the abstract threat becomes concrete: you can see which of your habits create clusters and which break them. That is the point of the exercise — not paranoia, but a calibrated sense of what your own ledger reveals. Everything in the toolkit table above is just a structured way to remove the signals you find in step 1 through 3.

Bottom Line: Which Privacy Approach Fits Your Threat Model
#

The right Bitcoin privacy setup depends entirely on who you are defending against, and the most common mistake is buying tools before defining the threat. Privacy is layered: fix the cheapest, highest-impact link first — almost always the KYC anchor and coin hygiene — before reaching for advanced collaborative transactions. Match your effort to your actual adversary, not to the most sophisticated attack imaginable.

If you want everyday financial privacy from passive data brokers and chain-watchers: prioritize no-KYC acquisition where lawful, disciplined coin control, and a wallet that never reuses addresses. This removes the easy clusters and the identity anchor — most of the real-world exposure — at near-zero cost.
If you maintain a public pseudonym (a creator, writer, or activist): do all of the above, then add Silent Payments for receiving and treat your writing as the bigger risk. The cheapest attack on a named pseudonym is off-chain text inference, not chain analysis — pair this guide with AI deanonymization.
If you face a targeted, well-resourced adversary: assume heuristics will be combined with subpoenaed exchange records and leaked databases. No single tool is sufficient; layer collaborative transactions, amount privacy via Lightning, network-layer protection, and rigorous off-chain compartmentation — and accept that “better privacy,” not “anonymity,” is the honest goal.

Whatever your tier, the sequence is the same: define the adversary, fix the KYC anchor and coin hygiene first, then add protocol-layer tools where they address a link you actually need to break.

Key Takeaways

Pseudonymous, not anonymous: Bitcoin’s ledger is public; the foundational clustering heuristics (Meiklejohn et al., 2013) collapse “separate” addresses into one wallet without breaking any cryptography.
The identity anchor is the KYC exchange: coins meet your real name at the regulated edge, where ID is retained — fix this link before any advanced tool.
The 2024 takedowns moved the architecture, not the goal: Samourai’s founders were charged in April 2024 (and sentenced in 2025) and Wasabi’s official coordinator stepped back in June 2024 (decentralized coordinators continued the CoinJoins), while coordinator-less JoinMarket kept running and protocol-layer Silent Payments emerged.
Each tool protects one layer: Silent Payments = receiving; PayJoin/CoinJoin = the transaction graph; Lightning = amounts; coin control = clusters you cause yourself. None covers off-chain text.
Coin control is the cheapest, most-skipped defense: not co-spending KYC coins with private coins prevents the clustering you would otherwise hand an analyst for free.

Frequently Asked Questions
#

Can Bitcoin transactions be traced?
#

Yes. Bitcoin is pseudonymous, not anonymous: every transaction is permanently public, and chain-analysis firms trace activity using clustering heuristics — chiefly the common-input-ownership assumption — combined with the identity records held by KYC exchanges. Tracing exploits patterns, not broken cryptography.

Does using a new address every time make me anonymous?
#

It helps, but it is not sufficient. Fresh addresses defeat the address-reuse heuristic, yet co-spending coins in one transaction still links them through common-input-ownership, and the KYC exchange you withdrew from still holds the identity anchor. Address hygiene is necessary but partial.

Did Silent Payments replace CoinJoin in 2026?
#

No — this is a common misreading. Silent Payments (BIP-352) solve receiving privacy with a reusable static address; they do not mix amounts the way CoinJoin does, and they impose a scanning cost on the receiver. After the 2024 coordinator takedowns they emerged as an important complement, not a drop-in replacement, and remain emerging rather than dominant.

What is the single most important Bitcoin privacy step?
#

Address the identity anchor and coin hygiene before anything else. Acquiring bitcoin without KYC where lawful, and never co-spending KYC-tagged coins with private coins, removes the easiest clusters and the strongest identity link at near-zero cost — more impact than any advanced tool added on top of a leaky base.

Are Bitcoin privacy tools legal?
#

This is not legal advice, and the answer depends on your jurisdiction and conduct. The 2024–2025 U.S. cases prosecuted the operators of mixing services for money transmission and laundering offenses tied to handling criminal proceeds — not individuals for seeking transactional privacy. Using privacy-preserving software is widely lawful, but obligations like tax reporting still apply; consult a qualified professional for your situation.

#	Source	URL	Archived
1	Meiklejohn et al. — “A Fistful of Bitcoins: Characterizing Payments Among Men with No Names” (IMC 2013)	https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf	https://web.archive.org/web/*/https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf
2	BIP-352 — Silent Payments (specification)	https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki	https://web.archive.org/web/*/https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki
3	U.S. DOJ (SDNY) — Samourai Wallet founders arrested and charged (April 2024)	https://www.justice.gov/usao-sdny/pr/founders-and-ceo-cryptocurrency-mixing-service-arrested-and-charged-money-laundering	https://web.archive.org/web/*/https://www.justice.gov/usao-sdny/pr/founders-and-ceo-cryptocurrency-mixing-service-arrested-and-charged-money-laundering
4	zkSNACKs — Suspending the Wasabi CoinJoin coordination service (June 1, 2024)	https://blog.wasabiwallet.io/zksnacks-is-discontinuing-its-coinjoin-coordination-service-1st-of-june/	https://web.archive.org/web/*/https://blog.wasabiwallet.io/zksnacks-is-discontinuing-its-coinjoin-coordination-service-1st-of-june/
5	Bitcoin Optech — Silent Payments topic	https://bitcoinops.org/en/topics/silent-payments/	https://web.archive.org/web/*/https://bitcoinops.org/en/topics/silent-payments/
6	Bitcoin Magazine — “The State of Bitcoin’s Lightning Network Privacy” (2022)	https://bitcoinmagazine.com/technical/state-of-bitcoin-lightning-network-privacy	https://web.archive.org/web/*/https://bitcoinmagazine.com/technical/state-of-bitcoin-lightning-network-privacy
7	U.S. DOJ (SDNY) — Samourai Wallet founders sentenced to five and four years (November 2025)	https://www.justice.gov/usao-sdny/pr/founders-samourai-wallet-cryptocurrency-mixing-service-sentenced-five-and-four-years	https://web.archive.org/web/*/https://www.justice.gov/usao-sdny/pr/founders-samourai-wallet-cryptocurrency-mixing-service-sentenced-five-and-four-years
8	Peer-reviewed analysis of Bitcoin peeling-chain patterns (ScienceDirect, 2023)	https://www.sciencedirect.com/science/article/pii/S2666281723001269	https://web.archive.org/web/*/https://www.sciencedirect.com/science/article/pii/S2666281723001269

Three threads from elsewhere on this site connect here directly. On-chain privacy is only half the picture: the cheapest attack on a named pseudonym is off-chain text inference, mapped in AI Deanonymization: How Inference Undoes Your Anonymity — this article is its on-chain counterpart, and the two are additive. Because the identity anchor is so often a leaked institutional record, the related playbook is When the Government Leaks Your Data. And because an on-chain mistake is as permanent as anything you have ever published, the audit of what survives deletion lives in How Permanent Is Your Social Media Footprint?.

Audit Your Own Post History the Way an AI Would (2026)

Thu, 25 Jun 2026 00:00:00 +0000

I write under a pseudonym, and the companion to this piece — AI Deanonymization: How Inference Undoes Your Anonymity — lays out how a model turns scattered posts into a name, and how to compartment going forward. This article is about the half that prevention can’t reach: the years of posts you have already published. That archive is sitting in public right now, and it is the exact corpus the attack reads. The honest question is not “what will I post carefully from now on” but “what does everything I’ve already said add up to” — and the only way to know is to look at it the way the machine does.

The good news is that you can. Your own export is something only you can pull, and reading it adversarially is a skill, not a secret. The bad news is the most natural way to do that reading — paste it into an AI and ask “what does this reveal about me?” — is also the single move most likely to make things worse. We’ll get to why. First, the thing you can’t feel from inside your own timeline.

The Mosaic Is the Part You Can’t Feel
#

The danger is not one careless post; it is the aggregate. Re-identification works by stacking many individually-innocuous signals — a commute, a slang word, a timestamp — until they intersect at one person. This is the “mosaic effect,” and you cannot sense it from inside your own feed, because each tile looks harmless on its own. The mosaic is old. In 2000, Latanya Sweeney showed that roughly 87% of Americans could be uniquely identified by just three public facts — ZIP code, gender, and date of birth (from 1990 census data; a 2006 reanalysis put it nearer 63%, and the pattern holds either way). In 2006, a New York Times reporter named an “anonymous” AOL searcher from her query logs alone; in 2008, researchers re-identified Netflix users by cross-referencing the service’s “anonymized” ratings against public IMDb reviews. None of those used AI. They used aggregation.

What AI changed is the price. In a peer-reviewed study at ICLR 2024, Beyond Memorization, ETH Zurich researchers showed that off-the-shelf models infer attributes — location, occupation, sex, income — from ordinary Reddit text at roughly 85% top-1 accuracy averaged across eight attributes (with wide variation between them), at roughly 100× lower cost and 240× faster than human investigators. Newer work industrializes it: AutoProfiler (Du et al., ACL 2026) runs a four-agent pipeline that pulls a pseudonymous post history (via platform APIs) and assembles a profile automatically, “at web scale.” The point is not that any single post doxxes you. It is that a machine can now afford to read all of them, together, and notice the intersection you never could.

On X, the Leak Usually Isn’t the Words
#

On Reddit the mosaic is mostly text. On X it is mostly metadata — and a text-only mental model is dangerous reassurance. Your self-set location field, your posting times, your image EXIF, your outbound links, and who you reply to often say more than anything you actually wrote. A pseudonymous account can be careful about its sentences and still leak through the scaffolding around them. Posting-time concentration is the clearest example: if your “anonymous” account keeps office hours, the histogram of when you post quietly hands over your time zone and your waking life.

Images are worse than people think, in two layers. Most platforms strip EXIF GPS from public uploads — but not from every path (direct messages, some API and scheduling tools, and chat “file” modes can retain it), so older media is worth checking. And even when the GPS tag is gone, the picture itself geolocates: a 2024 study, Image-Based Geolocation Using Large Vision-Language Models, found that vision-language models place photos from visual content alone — winning 85.37% of GeoGuessr-style matchups over 50,000 images, sometimes to within 0.3 km. Stripping metadata is necessary; it is not the whole job.

Metadata layer (mostly X)	What it quietly reveals	Where to look in your export
Self-set “location” field	A real region, in your own words	`profile.js` / your bio
Posting timestamps	Time zone and daily routine	`tweets.js` `created_at`
Image EXIF + photo content	Exact place; device; even EXIF-free geolocation	`tweets_media/` images
Outbound links	Your other sites and identities	URL entities in posts
Replies and mentions	The social graph that already knows you	mention entities

Read Your Own History Like an Adversary
#

The audit is a deliberate inversion: stop reading your timeline as a person reminiscing and start reading it as a stranger hunting. Pull your full export, then go category by category asking not “is this embarrassing” but “does this narrow who I am.” You can request your data from Reddit (Settings → Privacy → request a copy) and from X (Settings → Your account → download an archive). Both arrive as a structured file you can read offline. Then work the categories below — and weigh weak signals, not just obvious ones, because the mosaic is built from the weak ones.

A useful discipline: judge each finding by risk contribution, not by how revealing it feels in isolation. Twenty-eight posts that each mention a neighborhood landmark are a bigger problem than one post that names your employer once, because the twenty-eight intersect. Look for clusters and consistency — the same handle, the same turns of phrase, the same 7 a.m. posting slot — because consistency is exactly what a later search-and-match stage uses to find a join.

Category	What to search your own history for	How to soften it
Location	Commutes, local events, “near the…”, neighborhood landmarks, geotagged photos	Generalize to region; strip/skip image EXIF; coarsen the bio field
Employer / income	Role + team size + tech stack, “we’re hiring,” salary or holdings hints	Drop the distinctive combination; avoid recruiting-from-your-account posts
Family	Kids’ ages and schools, partners, routines	Remove specifics; remember relatives didn’t consent to be findable
Schedule	Fixed daily times, “every weekday,” posting-time concentration	Vary timing; never run an alias on your real clock
Identity links	Reused handle, links to a personal site, device model in EXIF	Don’t reuse handles; remove outbound personal links; strip device tags

The Privacy Audit That Deanonymizes You
#

Here is the trap, and almost no one names it. The obvious way to audit your history is to paste it into a capable AI and ask what it reveals. If the account you’re checking is a pseudonym you keep apart from your legal name — and the AI you ask is logged into your real identity — you have just handed one company both halves of the link you were protecting. The audit becomes the breach. Think it through. A cloud provider now holds, under your real-name account, the full post history of your “anonymous” persona, with a prompt that explicitly asks how the two connect. That association can surface later through a subpoena, a breach, or an insider — the precise failure you were auditing to prevent, except you created it yourself.

This does not mean cloud AI is forbidden. The risk is conditional. If you are auditing your real-name, public account, there is no anonymous identity to expose, so the deanonymization risk does not apply — though sending a full export to any cloud service still means a third party processes its contents under their terms, so check what yours holds first. The acute danger is specifically the pairing of an anonymous account with a real-name AI account. For that case, keep the analysis where no one else can see it.

If you are auditing…	Cloud AI (real-name account)	Local model (offline)
Your real-name / public account	No deanonymization risk — still review export contents first	Fine, just slower
A strict pseudonym you keep separate	Avoid — creates the real↔alias link	Recommended — nothing leaves your machine

The clean version of this audit runs locally: an open-source, local-first tool that parses your export and reports, by category, what it leaks — without ever sending your posts anywhere, and without writing a profile of you to disk. (I built one for exactly this; the link will live here on release.) If you must use a cloud model on a sensitive account, prefer a service built for crypto payment and minimal-identity sign-up — within its own terms — over a mainstream account tied to your real name and card. As of June 2026, for instance, OpenRouter offers an OpenAI-compatible API that accepts USDC and needs only an email or a wallet, and Venice is privacy-first with a no-account, pay-per-request crypto path and an OpenAI-compatible API — both plug straight into this tool’s cloud option. None of this is true anonymity: a wallet, an email, or network metadata can still remain, your prompts still reach a third party (with a router like OpenRouter, the model provider behind it too), and these privacy claims are largely vendor-stated rather than independently audited — so check each provider’s current terms, and remember that running locally is the only path that sends nothing at all.

What to Do With What You Find
#

Resist the urge to mass-delete. Removing one post rarely removes the pattern that exposed you, and deletion is not erasure: archives, search caches, screenshots, and other people’s copies persist long after you hit the button. The higher-leverage move is to generalize and edit the highest-contribution items — turn “the 8:07 ferry from my neighborhood” into “my commute” — and then to change what you publish going forward. For the full picture of what actually survives a deletion, see How Permanent Is Your Social Media Footprint?; for the prevention side — compartmenting identities so the mosaic has nothing to join — the playbook is in AI Deanonymization, and the broader rebuild of assumptions is mapped in OPSEC in the AI Age.

It is worth being honest about the limits. An audit of your own export is a closed-set exercise: it sees what you provided, not the open world an adversary draws on — data brokers, breaches, the reply graph, your writing style across services. A 2025 study of 240 people (Wang et al.) found users judged which of their own snippets were risky only slightly better than chance, and their rewrites successfully reduced inference in just 28% of cases. So treat the audit as risk reduction, not a clean bill of health — and re-check after you edit, because lowering the score is the only proof an edit worked.

Who This Matters For Most
#

Inference resistance is data hygiene for most people and physical safety for some. The retroactive audit matters most for those an adversary is already motivated to find. Harassment-driven doxxing, impersonation, and fabricated imagery fall disproportionately on women, and the same retroactive exposure threatens abuse survivors, LGBTQ people in hostile environments, dissidents, and journalists’ sources — anyone for whom an old, forgotten post is a present-tense risk. The case studies in How Streamers Get Doxxed show the pattern in the open; if that is your threat model, the audit is not optional housekeeping but maintenance you schedule.

Key Takeaways

Audit the archive, not just future posts. Your existing history is the corpus the attack reads; pull your Reddit and X export and read it adversarially, by category.
The mosaic is the threat. Re-identification stacks weak signals (Sweeney 2000: ~87% of Americans identifiable by ZIP + gender + DOB); AI just made reading all of them cheap (Staab et al., ICLR 2024: up to 85% top-1).
On X, metadata leaks more than words — location field, posting times, EXIF, links, replies. And stripping EXIF isn’t enough: models geolocate the image itself (Liu et al., 2024).
Don’t audit a pseudonym through a real-name cloud AI — you’d hand one provider the real↔alias link. Use a local, offline model for sensitive accounts.
Generalize, don’t mass-delete. Deletion ≠ erasure; edit the highest-risk items and change what you publish next. The audit is risk reduction, not anonymity.

Frequently Asked Questions
#

How do I get my Reddit and X post history to audit?
#

Request an export from each platform. On Reddit: Settings → Privacy & Security → “Request a copy of your data,” which returns CSV files of your comments and posts. On X: Settings → Your account → “Download an archive of your data,” which returns a folder of tweets.js, account.js, profile.js, and a tweets_media image folder. Both let you read your full history offline, which is the safe way to analyze it — you never hand it to a third party just to look at it.

Is it safe to ask ChatGPT or another cloud AI to check my posts?
#

It depends entirely on the account. If you are auditing your real-name or public profile, there is no anonymous identity to expose and a cloud model is fine. If you are auditing a pseudonym you keep separate from your legal name, sending its history to an AI logged in under your real identity links the two on that provider’s servers — the exact deanonymization you were trying to prevent. For that case, use a local, offline model, or a cloud account opened and paid for anonymously.

Should I just delete my old posts?
#

Usually not wholesale. Deleting one post rarely removes the pattern that exposed you, and deletion is not erasure — archives, caches, and screenshots persist, and platforms keep deleted content on their own servers for a window (Reddit, for instance, around 90 days) that legal process can still reach. The higher-leverage move is to generalize or edit the highest-risk items (a specific time and place becomes a vague one) and to change what you publish going forward. Re-audit afterward to confirm the change actually lowered your exposure.

Can’t I just strip EXIF from my photos and be done?
#

Strip EXIF — it’s necessary — but it is not sufficient. Vision-language models can geolocate a photo from its visual content alone, with no metadata at all (Liu et al., 2024, found accuracy to within 0.3 km in some cases). A storefront, a skyline, a transit sign, or a window view can place an image even after every tag is removed. Treat backgrounds, not just metadata, as part of what a picture discloses.

How accurate is AI at this, really?
#

Accurate enough to take seriously, and cheap enough to be run against everyone. Peer-reviewed work (Staab et al., ICLR 2024) put GPT-4 at roughly 85% top-1 accuracy averaged across eight attribute categories (with wide variation between them) from plain Reddit text; a 2026 preprint (not yet peer-reviewed) linked roughly two-thirds of a sample of Hacker News users to their real LinkedIn profiles at 90% precision for about one to four dollars each. The numbers vary by task and are not perfect — but the friction that used to protect you, a human spending hours, is gone.

#	Source	URL	Archived
1	Staab et al. — “Beyond Memorization: Violating Privacy via Inference with LLMs” (ICLR 2024)	https://arxiv.org/abs/2310.07298	https://web.archive.org/web/*/https://arxiv.org/abs/2310.07298
2	Du et al. — “Automated Profile Inference with Language Model Agents” / AutoProfiler (ACL 2026 Findings)	https://arxiv.org/abs/2505.12402	https://web.archive.org/web/*/https://arxiv.org/abs/2505.12402
3	Lermen et al. — “Large-scale online deanonymization with LLMs” (arXiv preprint, 2026)	https://arxiv.org/abs/2602.16800	https://web.archive.org/web/*/https://arxiv.org/abs/2602.16800
4	Liu et al. — “Image-Based Geolocation Using Large Vision-Language Models” (2024)	https://arxiv.org/abs/2408.09474	https://web.archive.org/web/*/https://arxiv.org/abs/2408.09474
5	Wang et al. — “Beyond PII: How Users Attempt to Estimate and Mitigate Implicit LLM Inference” (2025)	https://arxiv.org/abs/2509.12152	https://web.archive.org/web/*/https://arxiv.org/abs/2509.12152
6	Electronic Frontier Foundation — Surveillance Self-Defense	https://ssd.eff.org/	https://web.archive.org/web/*/https://ssd.eff.org/

How a Photo's Hidden Data Reveals Your Home Address (2026)

Mon, 06 Jul 2026 00:00:00 +0000

A photograph is two things. There is the image you see — and there is the file you send, which quietly carries a second cargo: the time the shutter fired, the device that fired it, that device’s serial number, and, if location services were on, the latitude and longitude of the ground you were standing on. That cargo is called EXIF — the metadata block (data about the data) that nearly every camera and phone writes into a photo by default.

This is not a theoretical leak. In 2012, a wanted hacker was traced to his girlfriend’s home because one uploaded photo still carried its GPS fix (Gizmodo, 2012) — he was sentenced to 27 months in federal prison (FBI, 2012). The same year, a magazine’s photo of John McAfee, then hiding from Belizean authorities, embedded coordinates that placed him in Guatemala near the Belize border (NPR, 2012) — a specific riverside location, per the reporters who took it (The Next Web, 2012). Academic researchers, meanwhile, showed they could walk from ordinary classified-ad photos to sellers’ home addresses (Friedland & Sommer, USENIX HotSec 2010).

So the question is not whether photo metadata can reveal your home — the case files settle that. The question is why people who believe they handled it keep getting found, and the answer is uncomfortable: most advice stops at “the platforms strip it for you,” and that is true only with exceptions sharp enough to cut. On July 6, 2026, we wrote a known GPS coordinate, two serial numbers and a thumbnail into a test photo, stripped it, and verified the result byte by byte — the walkthrough below is that experiment, and it is the missing step in nearly every guide: not removing the data, but proving it is gone. This is the metadata half of a two-layer problem; the other half — what the visible scene itself gives away — is mapped in What AI Geolocation Can Find in One Photo.

The Case Files: Three People, One File Betrayed
#

Each of these cases is closed, documented, and instructive in a different way: one shows the mechanism at full adversarial strength, one shows it defeating a person whose life depended on staying hidden, and one shows it working on someone with no adversary at all.

The hacker: Higinio Ochoa, 2012
#

Higinio O. Ochoa III, posting as w0rmer of the Anonymous-affiliated CabinCr3w, breached U.S. law-enforcement sites in February 2012. The taunting proof he posted included a photo taken on his girlfriend’s iPhone — and the file still carried its GPS block, pointing to a house in Wantirna South, a suburb of Melbourne, Australia (Gizmodo, 2012; CSO Online, 2012). From there, investigators connected the location to his girlfriend, and through her, to Ochoa. He was arrested that March, pleaded guilty, and was sentenced to 27 months in federal prison (FBI, 2012). A person actively evading the FBI, fluent in intrusion, was located by a default setting on a phone camera.

The fugitive: John McAfee, 2012
#

In December 2012, while McAfee was hiding from authorities in Belize, Vice published a photo of him titled “We Are with John McAfee Right Now, Suckers.” The iPhone 4S that took it embedded coordinates — 15°39'29.4"N, 88°59'31.8"W, the Rio Dulce area of Guatemala — into the published file (The Next Web, 2012). McAfee first claimed he had manipulated the data; a day later he conceded the coordinates were real (NPR, 2012), and he was detained in Guatemala shortly after. The failure here was not his: someone else’s camera published his location. Your metadata exposure includes every device pointed at you.

The broadcaster: Adam Savage, 2010
#

Adam Savage of MythBusters posted a photo of his truck with the caption “Now it’s off to work” — and the geotag placed the truck in front of his home, while the caption announced the house would be empty (The New York Times, 2010). No adversary, no manhunt — just a default setting converting a casual post into an address plus a schedule. Most readers are not fugitives or hackers; this is the case that describes you.

What Is Actually Inside a Photo File
#

EXIF (Exchangeable Image File Format) is the metadata standard that cameras write into JPEG and most raw files, defined by the camera-industry body CIPA (DC-008). The image is what you see; EXIF is what the file remembers — and it remembers more than location.

A photo file carries the image you see plus an invisible EXIF block: GPS coordinates, timestamps, camera serial numbers, and an embedded thumbnail.

EXIF field	What it reveals	Who has used it
GPS latitude / longitude / altitude	Where the shutter fired, to a few meters	FBI (Ochoa); anyone with a viewer
Date/time original	When — combine with GPS for a routine	The Savage case: address plus “not home”
Body & lens serial numbers	Which physical camera — searchable across the public web	Serial-search services index photos by camera
Make / model / software	Device and editing fingerprint	Narrows identity; flags edited files
Embedded thumbnail	A miniature of the image — sometimes the pre-edit original	The 2003 thumbnail incidents (below)

Two of these rows deserve emphasis, because almost no general guide mentions them.

Serial numbers link photos to each other. Many cameras — and some phones — write a body or lens serial into every file they produce (plenty of phones omit it, and some platforms strip it, so this is a risk to check rather than a certainty). Where it is present, services such as Stolen Camera Finder exist to search the web for photos carrying a given serial — built for theft recovery, and equally functional as a way to connect every unstripped photo one camera has ever published. If you maintain separated identities — a work name and a pseudonymous account, say — one camera posting unstripped files to both has already linked them at the metadata layer. That linkage is the quiet cousin of the doxxing chains we documented in How Streamers Get Doxxed.

The thumbnail can betray the edit. EXIF carries a small preview image generated when the photo is taken. In 2003, TechTV host Cat Schwartz posted photos that had been cropped — but the editing tool of the era did not regenerate the embedded thumbnail, so the uncropped originals rode along inside the published files, and readers extracted them (MetaFilter, 2003). Modern OS-level editors generally rebuild the thumbnail; third-party pipelines are not guaranteed to. The lesson is not “never crop” — it is that an edit you can see proves nothing about data you cannot, which is why verification (below) is the load-bearing step.

Where the Defaults Betray You
#

The reassurance you will hear most often — “platforms strip EXIF anyway” — is roughly true for public display and dangerously incomplete as a defense. It fails at the edges, and the edges are exactly where the case files live.

The table below is where stripping fails and how you would catch it — the verification habit this article is built around. Behavior is as tested in 2026 and varies by app version, device, and upload mode; treat it as “where to look,” not a permanent guarantee.

Where you send it	What survives	How you’d catch it
Public post — Instagram / Facebook / X	The public copy is re-encoded, but the original is kept server-side (Meta policy)	You can’t inspect the server’s copy — assume the platform holds the unstripped file, so strip before upload
TikTok upload	Re-encoded on the public copy	Location is still collected by other means; a clean file is not an untracked one
Messenger photo mode — WhatsApp / Signal / Telegram	Compression usually drops the EXIF	Send one test photo to yourself and read the metadata of what actually arrives
Messenger document / file mode	Metadata rides through intact — the path people pick for quality (documented below)	Treat any “send as file” as unstripped until a reader proves otherwise
Email, cloud links, marketplace listings	Often nothing is removed at all	You are the only stripping layer — verify every file yourself

Three patterns turn that table into incidents. First, the document trap: messaging apps strip metadata when you send a “photo,” because the image is recompressed — but the send-as-file option, the one people choose deliberately to preserve quality, preserves everything. Signal’s own community documentation confirms its stripping covers the standard photo pipeline, not files sent as generic attachments (Signal Community); WhatsApp and Telegram behave the same way in community testing — and none of the three warns you. Second, the first-hop problem: the platform strips what it shows the public, but the platform itself received the full file; stripping locally is what keeps the coordinate out of their retention too. Third, the no-platform problem: classified ads, marketplace listings, forum attachments and email pass files through with far weaker guarantees. This is the systematic risk Friedland and Sommer named “cybercasing” in 2010 — using online geo-tagged data to case real-world targets. Working from ordinary Craigslist listings, they cross-referenced photo coordinates with street mapping and walked straight to sellers’ homes (ICSI, 2010). A seller photographing valuables inside their own house is composing the exact file an intruder wants: what’s worth taking, and where it lives.

And one myth needs retiring in both directions: a screenshot of a photo does produce a new file without the original EXIF — a real metadata fix — but it changes nothing about what the image shows. As we put it in the companion piece: a screenshot changes the file, not the frame.

The Verify-Don’t-Trust Protocol (Our Walkthrough)
#

Every guide tells you to strip metadata. Almost none tells you to check. So on July 6, 2026, we ran the full loop on a test file — write a known coordinate in, strip, verify — using ExifTool 12.57 (our Linux distribution’s packaged build; upstream is now 13.59), the free command-line standard for reading and writing image metadata. What follows is the actual sequence, with the tool’s output trimmed to the fields that matter; every step is reproducible, and the full unedited log — every line — ships with this article (experiment log).

Step 1 — see what the file carries. We gave our test photo a realistic payload: a GPS fix (48.8584 N, 2.2945 E — the Eiffel Tower, a deliberately neutral landmark), body and lens serial numbers, timestamps, and an embedded thumbnail. Then we asked the file what it would tell a stranger:

$ exiftool -a -gps:all -SerialNumber -LensSerialNumber -Model photo.jpg
GPS Latitude : 48 deg 51' 30.24" N
GPS Longitude : 2 deg 17' 40.20" E
GPS Altitude : 35 m
Serial Number : SN-TEST-123456
Lens Serial Number : LENS-TEST-789
Camera Model Name : TC-1

One flag (-n) converts that to decimal — 48.8584, 2.2945 — which pastes directly into any map. The embedded thumbnail was there too: a complete 948-byte miniature of the image, extractable with one command. In total, 1,510 bytes of metadata — invisible in every image viewer — carried the location, the hardware identity and the preview.

Step 2 — strip it. The canonical local strip is one command:

$ exiftool -all= photo.jpg

Desktop alternatives that wrap the same operation: ExifCleaner (open-source, drag-and-drop, no telemetry; v4.0 as of 2026), or the built-in share options below.

Step 3 — verify. This is the step that separates belief from knowledge. Run the same query as Step 1 against the stripped file:

$ exiftool -a -gps:all -SerialNumber -LensSerialNumber -ThumbnailImage photo.jpg
(no output)

Empty output is the pass condition: no GPS, no serials, no thumbnail survived. What remains after -all= is file structure only — dimensions, encoding, size — nothing that identifies a place, a device, or an earlier version of the image.

Step 4 — make the defaults work for you. On iPhone, the share sheet’s Options → Location toggle removes the coordinate from what you send, and Settings → Privacy & Security → Location Services → Camera → Never stops it being written at all (Apple). On Android, the camera’s own location permission controls whether a coordinate is recorded in the first place — but note a sharp limit worth knowing: Google Photos can only edit or remove its own estimated or manually added locations. Per Google’s own help page, a coordinate the camera itself wrote into the file cannot be removed inside Google Photos at all — it survives, untouched, beneath whatever the app shows you (Google). That gap is the whole argument for Step 3: whether an exported file is actually clean depends on the app and the path it took, so trust the empty output of a metadata reader, not a toggle or a display.

Habits by Threat Tier
#

The strip-and-verify loop above is mechanical; what changes by tier is how often you run it and how far you carry it. Match the row to who might care where you are — this is the metadata-layer counterpart to the composition-and-timing rules in our AI-geolocation guide, not a repeat of them.

Tier	Who	The habit
Baseline	Casual sharer	Camera location off; let platforms strip public posts, but never rely on it for files you send — no “document mode” photos without a strip
Seller	Marketplace / classifieds user	Strip every listing photo and verify the first one from each device; never photograph valuables against identifying backgrounds — cybercasing starts here
Separated identities	Pseudonymous account, creator, activist, survivor	Strip and verify everything; treat serial numbers as linking identifiers across identities; assume any photo of you taken by someone else ships with coordinates (the McAfee lesson) — for a survivor of stalking or intimate-partner violence, a single unstripped photo can hand an abuser a current address, which is why this tier treats every file as sensitive

The pattern across every tier: the cost of the habit is seconds, and the failure it prevents is the one that cannot be undone. A coordinate, once published, joins the permanent record — the same permanence economics we mapped for posts in How Permanent Is Your Social Media Footprint?.

Bottom Line — The File Is the Territory
#

The image is what you meant to share; the file is what you actually shared. Every case in this article — the hacker, the fugitive, the broadcaster, the cropped thumbnails, the cybercased sellers — reduces to that one gap, and the gap has a mechanical fix: strip locally, then verify with a tool that reads the file itself. Two decades of documented incidents, from the 2003 thumbnails to today, say the people who get burned are not the ones who never heard the advice. They are the ones who assumed it had been handled.

Key Takeaways

The mechanism is proven, not theoretical: a photo’s GPS block led investigators to hacker Higinio Ochoa (27-month sentence, 2012), and a coordinate embedded by someone else’s camera exposed John McAfee’s Guatemala hideout (2012).
EXIF carries more than location: camera serial numbers link photos — and pseudonymous accounts — across the web, and embedded thumbnails have shipped the pre-edit image (2003).
Platform stripping is display-deep: public posts are re-encoded, but “send as document/file” preserves full EXIF, platforms may retain the original server-side, and marketplaces/email often strip nothing.
Verification is the missing step: in our July 2026 test, exiftool -all= removed all 1,510 bytes of identifying metadata — and the same query that found the GPS is what proves it is gone.
Someone else’s camera counts: McAfee was located by a journalist’s phone; your exposure includes every unstripped photo of you.

Frequently Asked Questions
#

How do I check what metadata a photo contains?
#

Ask the file directly. Install ExifTool and run exiftool photo.jpg for everything, or exiftool -a -gps:all -SerialNumber photo.jpg for the fields that matter most. On iPhone, swipe up on a photo to see location; on Android, open photo details in Google Photos. The built-in views show a subset — the command line shows what an adversary sees.

Don’t social media platforms remove EXIF automatically?
#

For publicly displayed images, generally yes — X, Facebook, Instagram and TikTok re-encode uploads, which drops the metadata shown to other users. But the platform received your original and may retain that data server-side; and messager “send as document/file” options (WhatsApp, Signal, Telegram) skip the re-encoding and deliver full EXIF. Marketplace listings and email often strip nothing at all. Strip locally first and the question becomes moot.

Does cropping or blurring a photo remove its metadata?
#

No — editing pixels and editing metadata are separate operations. A cropped or blurred photo can keep its full EXIF block, and in the classic 2003 case, the embedded thumbnail inside the metadata still contained the uncropped original. Some modern editors rebuild the thumbnail and some strip metadata on export; the only way to know is to verify the output file with a metadata reader.

Can photo metadata link my anonymous account to my real one?
#

Yes, through hardware identifiers. Camera bodies and lenses write their serial numbers into EXIF, and serial-indexed search exists (built for stolen-camera recovery). One camera posting unstripped photos to two identities has connected them — no facial recognition, no writing-style analysis, just the file. If you run separated identities, stripping metadata is not optional hygiene; it is identity architecture.

How do I remove metadata from a photo on my phone, without a computer?
#

On iPhone, open the share sheet, tap Options at the top, and turn Location off before you send or save — that drops the coordinate from the exported copy. On Android it varies by gallery app, and there is a sharp catch: Google Photos cannot remove a coordinate the camera itself wrote — only estimated or manually added ones — so that value can survive whatever the app shows you (Google). When the built-in path is uncertain, use a dedicated stripper like ExifCleaner and then confirm the result with a metadata reader. The file, not the toggle, is the proof.

Sources
#

Our test artifacts: the unedited experiment log from the July 6, 2026 strip-and-verify run (ExifTool 12.57; test coordinates are the Eiffel Tower, chosen as a neutral landmark).

This article is the metadata half of this site’s photo-privacy thread. What the visible scene gives away — and why that half cannot be stripped — is mapped in What AI Geolocation Can Find in One Photo. How doxxing chains actually assemble around a person is documented in How Streamers Get Doxxed, and what survives your delete button in How Permanent Is Your Social Media Footprint?.

What Does ChatGPT Know About You? AI Privacy Audit 2026

Sat, 20 Jun 2026 00:00:00 +0000

I type into a chat box the way I’d speak near a microphone whose cable I can’t see: I assume it is recording, because the cheapest safe assumption is the one that turns out to be true. Most people do the opposite. An assistant answers in a calm, conversational voice, the window feels private, and so we tell it the things we would tell a doctor or a lawyer — the medical worry, the draft resignation letter, the half-formed plan, the password we shouldn’t be pasting. The interface is built to feel like a conversation. The back end is built to keep a record.

Those are different things, and the gap between them is where the privacy problem lives. Pew Research found in March 2026 that 50% of U.S. adults are more concerned than excited about the spread of AI — up from 37% in 2021 — and an earlier survey found a large majority expecting their personal information to be used in ways they would find uncomfortable. And yet the same tools collect, by design, a more intimate stream of disclosure than search ever did. A search query is a few keywords; a chat is a confession with follow-up questions. What happens to that record afterward is governed not by the friendly tone of the reply but by each provider’s data policy, its retention schedule, its human-review pipeline, and — increasingly — by court orders the provider does not control.

So the question worth answering is not “is my AI assistant private?” — that framing invites a yes-or-no marketing answer. The useful question is: what, specifically, does each assistant keep; what does turning off “training” actually stop; and what survives every setting you can reach? Below is that audit, provider by provider, as of mid-2026 — with the honest caveat that these policies change often, so the dated claims here are a starting point to verify against each company’s current page, not a substitute for it.

What the interface suggests	What the system actually does
A private, in-the-moment conversation	A logged record tied to your account
“Delete” makes it gone	“Delete” hides it from you; copies may persist
Turning off training protects you	Training is one use; retention, review, and disclosure are others
The reply is just for me	Samples may be read by humans to “improve the model”

Why a Chat Is a Record, Not a Conversation
#

An AI chat is a data record subject to at least five separate uses — model training, human review, retention, security disclosure, and biometric processing of voice or images — and a privacy setting usually governs only the first of them. Treating “opt out of training” as “make it private” is the central mistake, because the other four uses run on their own rules, and the most damaging ones are the ones no toggle touches. Naming the five uses separately is what turns a vague unease into a checklist you can actually audit.

The first use is training: your conversations become material that shapes future versions of the model. The second is human review: to measure quality and catch abuse, providers let trained staff or contractors read a sample of real conversations — a practice every major lab discloses somewhere in its policy. The third is retention: even after you delete a chat, copies commonly persist in abuse-monitoring systems, backups, and legal holds for a defined window, or longer if a conversation is flagged. The fourth is disclosure: a record that exists can be subpoenaed, produced in litigation, or handed over under a preservation order — none of which you control. The fifth, growing fastest, is biometric processing: voice input and uploaded images carry data — a voiceprint, a face — that is durable in a way text is not.

Hold those five apart and the rest of this article is just filling in a grid: for each assistant, which uses are on by default, which you can switch off, and which you cannot. The regulatory backdrop is shifting too — the EU’s AI Act began applying transparency duties to general-purpose models in August 2025, with its broader provisions reaching full application on 2 August 2026 — but regulation moves slowly and unevenly, so the practical defense is still to know the grid and act on it yourself.

What Each Assistant Actually Keeps
#

As of mid-2026 the major consumer assistants share a default most users miss — they train on your chats unless you opt out, with regional exceptions such as the EU and UK — and all of them retain some data after deletion and reserve a path for human review. The table below is the cross-platform summary; the paragraphs after it carry the nuance, because a one-word cell (“Yes”) hides conditions that matter. Read the cell, then read the caveat.

Assistant	Trains on chats by default (consumer)	Opt-out path	Notably kept after you delete
ChatGPT (OpenAI)	Yes	Settings → Data Controls	Abuse-monitoring copies; data under legal hold
Claude (Anthropic)	Yes, unless you opt out (since Sep 2025)	Privacy / data settings	Safety-flagged content; data under legal hold
Gemini (Google)	Yes (via “Gemini Apps Activity”)	Turn Activity off	Human-reviewed samples, kept up to 3 years
Copilot (Microsoft)	Yes, unless opted out (EU/UK: off by default)	Settings toggle	~18-month rolling window
Meta AI	Yes (your AI chats)	Limited; none outside EU/UK	Content used for ads/personalization

ChatGPT (OpenAI). For free, Plus, and Pro accounts, conversations are used to improve the models by default; you turn this off under Settings → Data Controls. OpenAI’s own help pages describe abuse-monitoring retention that persists for a window after deletion, and the company has stated that Team, Enterprise, and API customers are not trained on by default. The larger lesson of 2025 sits outside the settings page entirely: in the New York Times litigation, OpenAI was placed under a court order to preserve output data — including content users believed they had deleted. A toggle you control is no match for a hold you don’t.

Claude (Anthropic). Since a consumer-terms change that took effect in late September 2025, Anthropic trains on Free, Pro, and Max chats unless you opt out through your data settings — the same opt-out posture as ChatGPT, not the opt-in many users still assume. Two caveats compound it: conversations flagged for safety or policy review can be used and retained even after you opt out, and Anthropic does not publish what triggers a flag. I write this as an author whose own words are produced with Claude, which is exactly why I will not soften it: read the current privacy page rather than trust any summary, including this one.

Gemini (Google). Google ties training to your Gemini Apps Activity setting; with it on, conversations can be used to improve services, and turning it off stops that — at the cost of your chat history. The detail most people miss is review retention: a sample of conversations selected for human review is disconnected from your account but, per Google’s help pages, can be kept for an extended period — up to three years — regardless of your normal auto-delete window. Workspace (work/school) accounts are governed by different, generally stricter terms.

Copilot (Microsoft). Microsoft’s privacy FAQ states that, except for certain user categories or those who have opted out, it uses interactions across Bing, MSN, and Copilot for AI training — so the consumer default is not hands-off, though users in the EU, UK, and Switzerland are excluded by default. Consumer history runs on a default 18-month window you can clear. Microsoft 365 Copilot inside a work or school account is a different product: prompts and responses are treated as organizational data under enterprise terms and are not used to train the foundation models. The free consumer tier and the work tier are not the same privacy regime, even when the icon looks identical.

Meta AI. Meta uses interactions with its AI — your chats with the assistant, plus public posts — to train and, per its late-2025 update, to personalize ads and feeds. Meta has stated it does not use the content of private messages with friends and family for this — but your conversations with the Meta AI assistant are in scope, and outside the EU and UK there is effectively no opt-out from the ad use, only an exclusion for sensitive-topic categories like health and politics. Of the five, this is the one where the line between “assistant” and “ad platform” is thinnest.

The Opt-Out Playbook — and Its Limits
#

The single highest-value action is to find each assistant’s training control and set it the way you want before your next sensitive chat — but treat opt-out as reducing one stream of exposure, not as making the conversation private. Do it anyway: shrinking the training surface is real and worth the two minutes. Just don’t mistake a quieter pipe for a closed one. Here is the path on each, as of mid-2026, with the standing reminder to verify against the live settings page.

ChatGPT — Settings → Data Controls, and turn off the option to improve the model. For one-off sensitive questions, use a Temporary Chat, which is excluded from training and auto-deletes — while noting that abuse-monitoring retention can still apply for a window.
Claude — open your privacy/data settings and turn the training control off; since late September 2025 the consumer default is opt-out, not opt-in, so the choice is yours to make rather than assume.
Gemini — turn off Gemini Apps Activity to stop training use; understand this also clears ongoing history, and that previously selected human-review samples remain on their own retention clock.
Copilot — turn off the model-improvement and personalization toggles in settings (outside the EU/UK the consumer default includes your interactions in training); for genuinely sensitive work, a managed Microsoft 365 (work) account is treated more protectively than the free consumer app.
Meta AI — apply whatever regional opt-out and ad-settings controls exist to you, and operate from the assumption that this assistant is the most ad-integrated of the set.

Two cross-cutting habits beat any single toggle. First, don’t paste what you can’t afford to have kept — secrets, full identity documents, another person’s private data — because the durable defense is upstream of the model, at the point of input. Second, separate accounts by purpose, so a work question and a medical worry don’t accumulate against one profile. For the broader discipline this sits inside, the EFF’s Surveillance Self-Defense is a level-headed reference.

What Opt-Out Cannot Reach
#

Opting out of training stops future model improvement from using your data; it does not delete the past, undo retention, prevent a breach, or block a subpoena — and those are the exposures with the highest consequences. This is the section the marketing pages skip, and it is the one that should shape what you type. Four things sit beyond the reach of every toggle on every platform, and naming them is the point of the whole audit.

The first is the past. Anything already used to train a deployed model cannot be pulled back out of it; opt-out is prospective, never retroactive. The second is retention after deletion — abuse-monitoring stores, backups, and legal holds keep copies on schedules you don’t set, and a conversation flagged for safety can persist far longer than your normal history. The third is disclosure: a record that exists is discoverable, and as the 2025 preservation order against OpenAI showed, “I deleted it” is not a status a court is obliged to honor. The fourth is a breach — the strongest internal policy in the world is only as good as the security around the database, and a stored confession is a stored liability for whoever holds it.

This is where regulation enters, and where to keep expectations sober. The EU AI Act’s transparency obligations for general-purpose AI — documentation, a summary of training data, copyright duties — began in August 2025 and sit within its full application on 2 August 2026, which is real progress on disclosure about systems. It is not, however, a delete button for your data, and open-source models carry lighter obligations. Rules raise the floor over time; they do not retroactively unsay what you already typed. The working conclusion is unglamorous and durable: the only data that can’t leak, be subpoenaed, or be retained past its welcome is the data you never put into the box.

The Uneven Risk: Voice, Likeness, and Who Pays Most
#

Voice and image inputs raise the stakes because they carry biometric data — a voiceprint, facial geometry — that is durable and uniquely yours, and the harms from its capture fall hardest on women and other already-targeted people. Text can be rewritten; a leaked voiceprint cannot be reissued like a password. As assistants add voice modes and image understanding, the audit has to extend past words to the biometric layer, because that is where the worst-case outcomes now concentrate.

The mechanism is simple and well-documented. As little as 10 to 15 seconds of someone’s voice — OpenAI said its own Voice Engine needed just 15 — is now enough to drive convincing synthetic speech, which is why the FCC ruled in February 2024 that AI-generated voices in robocalls are “artificial” under the Telephone Consumer Protection Act and require prior consent. Feed an assistant your voice routinely and you are normalizing the capture of the exact material that impersonation needs. Uploaded photos extend the same logic to faces. None of this requires the provider to act in bad faith; it only requires the data to exist and, someday, to leak or be misused.

And the burden is not evenly shared. Impersonation, fabricated intimate imagery, and the harassment-to-doxxing pipeline land disproportionately on women, on public-facing professionals, and on activists — the same asymmetry I traced in the case for treating likeness as a credential and in defending against coordinated doxxing. For anyone carrying that risk, the practical rule is stricter than for the general user: keep voice and face out of consumer assistants you don’t have to use, prefer text, and treat any biometric input as effectively permanent once it leaves your device.

Bottom Line — How Much Should You Lock Down?
#

The right defense scales with your threat model, not with one master setting: casual users need three habits, professionals need separated accounts and stricter tiers, and anyone carrying asymmetric risk should treat voice and biometric input as permanently off-limits on consumer assistants. The right level depends on who you are protecting yourself from — there is no universal answer, only a threat model and a few habits that pay off at every level.

If you have no specific adversary: turn off training on the assistants you use, prefer a temporary/incognito chat mode for sensitive one-offs, and keep secrets and identity documents out of the box entirely. That covers most of the realistic risk for most people.
If you handle others’ data or sensitive work: use a managed work account where the terms are stricter, separate accounts by purpose, and assume anything you type could later be retained, reviewed, or disclosed regardless of your settings.
If you carry asymmetric risk — women facing harassment, activists, public-facing professionals: keep voice and face out of consumer assistants, minimize what you disclose to any of them, and treat biometric input as permanent.

Underneath all three is one principle that no policy change will overturn: an opt-out shapes how your data is used, but only restraint at the keyboard governs whether the data exists. Audit the settings, by all means — then write as if the record outlives the setting, because it does.

Key Takeaways

Records, not chats: AI conversations are data records subject to five separate uses — training, human review, retention, legal disclosure, and biometric processing — and a privacy toggle usually governs only the first.
Defaults converge: as of mid-2026 ChatGPT, Claude (since Sept 2025), Gemini, Copilot, and Meta AI all train on consumer chats unless you opt out — with regional exceptions like the EU and UK — and all retain some data after deletion.
Opt-out is prospective: turning off training never removes what already trained a model, and a 2025 court order required OpenAI to preserve outputs users believed they had deleted.
No setting reaches a subpoena or a breach: retention stores, legal holds, and security failures sit beyond every consumer toggle — the durable control is not typing the secret at all.
Voice and likeness are biometric: seconds of audio can drive convincing voice clones; this risk falls hardest on women, activists, and public figures, who should keep voice and face out of consumer assistants.

Frequently Asked Questions
#

Does ChatGPT use my conversations to train its models?
#

By default, yes, on free, Plus, and Pro accounts, as of mid-2026 — you can turn this off under Settings → Data Controls. Turning it off stops future training use but does not delete past data already used, and OpenAI’s own pages describe abuse-monitoring copies that persist for a window after deletion. Business tiers (Team, Enterprise, API) are not trained on by default. Because these policies change, confirm the current setting on OpenAI’s data controls page rather than relying on any summary.

If I delete an AI chat, is it really gone?
#

Usually not entirely. Deletion removes the conversation from your visible history, but copies commonly remain in abuse-monitoring systems, backups, and any legal hold, each on a retention schedule you do not control. A conversation flagged for safety review can persist longer still. The 2025 preservation order in the New York Times case against OpenAI is the clearest illustration that “deleted” is not always permanent when a court is involved.

Which AI assistant is the most private by default?
#

As of mid-2026 the honest answer is “none of them, by default” — ChatGPT, Claude (since its September 2025 consumer-terms change), Gemini, Copilot, and Meta AI all train on consumer chats unless you opt out, with regional carve-outs such as the EU and UK. The meaningful differences are in the details you have to act on: where the opt-out lives, how long human-reviewed samples are kept, and what a safety flag can override. Every provider also retains some data after deletion and reserves a path for human review and legal disclosure, so “private by default” is the wrong thing to shop for — opting out and disclosing less is the control you actually hold.

Is it safe to use voice mode or upload photos to an AI assistant?
#

Treat it as higher-risk than text. Voice and images carry biometric data — a voiceprint, facial geometry — that is durable and uniquely identifying, and seconds of audio can be enough to drive a convincing voice clone. The data existing is the risk, independent of provider intent. If you carry elevated risk of impersonation or harassment, prefer text, and keep voice and face out of consumer assistants you are not required to use.

Will the EU AI Act make AI assistants private?
#

No — it improves transparency, not personal data deletion. Its transparency obligations for general-purpose AI — technical documentation, a summary of training data — began in August 2025 and sit within the Act’s full application on 2 August 2026, which helps you understand the systems. It does not retroactively remove data you already submitted, and open-source models carry lighter duties. Regulation raises the floor over time; it is not a substitute for restraint about what you type.

#	Source	URL	Archived
1	OpenAI — Data Controls FAQ	https://help.openai.com/en/articles/7730893-data-controls-faq	https://web.archive.org/web/*/https://help.openai.com/en/articles/7730893-data-controls-faq
2	Anthropic — Privacy Policy	https://www.anthropic.com/legal/privacy	https://web.archive.org/web/*/https://www.anthropic.com/legal/privacy
3	Anthropic — Updates to Consumer Terms and Privacy Policy (2025)	https://www.anthropic.com/news/updates-to-our-consumer-terms	https://web.archive.org/web/*/https://www.anthropic.com/news/updates-to-our-consumer-terms
4	Google — Gemini Apps & your data	https://support.google.com/gemini/answer/13594961	https://web.archive.org/web/*/https://support.google.com/gemini/answer/13594961
5	Microsoft — Copilot privacy FAQ	https://support.microsoft.com/en-us/microsoft-copilot/privacy-faq-for-microsoft-copilot	https://web.archive.org/web/*/https://support.microsoft.com/en-us/microsoft-copilot/privacy-faq-for-microsoft-copilot
6	Meta — Privacy Policy	https://www.facebook.com/privacy/policy/	https://web.archive.org/web/*/https://www.facebook.com/privacy/policy/
7	European Commission — Regulatory framework on AI (AI Act)	https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai	https://web.archive.org/web/*/https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
8	Pew Research — Key findings about how Americans view AI (March 2026)	https://www.pewresearch.org/short-reads/2026/03/12/key-findings-about-how-americans-view-artificial-intelligence/	https://web.archive.org/web/*/https://www.pewresearch.org/short-reads/2026/03/12/key-findings-about-how-americans-view-artificial-intelligence/
9	NYT v. OpenAI — court preservation order (reporting)	https://decrypt.co/323950/openai-challenges-court-order-user-data-nyt-lawsuit	https://web.archive.org/web/*/https://decrypt.co/323950/openai-challenges-court-order-user-data-nyt-lawsuit
10	FCC — AI-Generated Voices in Robocalls Are Illegal (2024)	https://www.fcc.gov/document/fcc-makes-ai-generated-voices-robocalls-illegal	https://web.archive.org/web/*/https://www.fcc.gov/document/fcc-makes-ai-generated-voices-robocalls-illegal
11	Electronic Frontier Foundation — Surveillance Self-Defense	https://ssd.eff.org/	https://web.archive.org/web/*/https://ssd.eff.org/

This audit is one half of a larger map. The threat model that makes AI a first-class adversary — and the assumptions it breaks — is laid out in OPSEC in the AI Age: Rebuilding Your Threat Model, and the deep-dive on how models infer identity from what you publish is AI Deanonymization: How Inference Undoes Your Anonymity. When the record is taken from an institution rather than typed by you, the companion playbook is When the Government Leaks Your Data; and for the biometric stakes raised above, see Your Face and Voice Are Now Credentials.

AI Deanonymization: How Inference Undoes Your Anonymity (2026)

Wed, 17 Jun 2026 00:00:00 +0000

I write under a pseudonym, so the attack in this article is the one I think about most. The old assumption behind every alias is simple: if I keep my name off the page, the gap between “Cora Aegis” and the person typing stays expensive to close. For two decades of digital life that assumption mostly held, because closing the gap meant a human reading thousands of posts by hand. Anonymity by omission — just leave the name out — was good enough for most people most of the time.

It is no longer good enough, and the reason is measured, not hypothetical. In a peer-reviewed study presented at ICLR 2024, Beyond Memorization, researchers at ETH Zurich showed that off-the-shelf language models infer attributes like location, income, and sex directly from ordinary Reddit text — reaching up to 85% top-1 accuracy, and up to 95.8% within their top three guesses. A 2026 follow-up preprint went from attributes to identity: an agentic model linked 67% of a set of Hacker News users to their real LinkedIn profiles at 90% precision — nine in ten of its positive matches were correct — for roughly one to four dollars per person. The friction that used to protect you — that linking accounts took a person hours — is the thing AI removed.

So what actually protects a pseudonym now? Not a delete button; the inference survives any single post you take down. You protect it the way you’d defend any system whose front door no longer locks: you stop treating “I didn’t say it” as a defense, and you start breaking the chain that turns scattered, harmless-looking signals into a name. Below is that chain, stage by stage, why on-chain Bitcoin privacy does not cover it, and the compartmentation that does.

What looks harmless	What it actually leaks	How a model uses it
A reused username or writing tic	A link between two “separate” identities	Joins your accounts into one profile
“Good morning” timestamps, local slang	Your time zone and city	Narrows location without a stated address
A hobby, a commute, an employer hint	Income band, schedule, workplace	Cross-references against candidate profiles
A photo’s background or metadata	Exact place and time	Confirms a guess the text already suggested

The machine deanonymization chain: scattered public posts are turned into a name through extract, search, and verify stages — break any one link to fall below the attacker's cost budget.

Anonymity Was Expensive to Break — Then AI Made It Cheap
#

Deanonymization is the work of linking a pseudonym or anonymous account back to a real identity — through correlation and inference across many small signals, not a single slip. The first thing to understand is that it did not get smarter so much as cheaper. The techniques — correlate accounts, infer unstated facts, match a writing style — are old; what changed is that a machine now does them at a per-person cost of a few dollars instead of a human’s billable hours. That price collapse is the whole story, because most anonymity was never cryptographically strong. It was protected by the fact that nobody could be bothered.

The numbers make the shift concrete. The ETH Zurich team’s Beyond Memorization (ICLR 2024) tested models against real Reddit profiles and found that simply writing naturally leaks enough for a model to guess where you live and what you earn — and that the usual mitigations, text anonymization tools and model “alignment,” did not reliably stop it. The 2026 preprint Large-scale online deanonymization with LLMs (which lists a researcher then at Anthropic among its authors, and is not yet peer-reviewed) pushed further: built as an autonomous agent, the system pulled clues from Hacker News comments, searched for matching people, and verified candidates against LinkedIn — landing 67% of users at 90% precision, with total experiment costs under two thousand dollars.

Read those two results together and the conclusion is uncomfortable but clear: the protection was the price, and the price is gone. A motivated adversary no longer needs to care about you specifically. They can run the attack against everyone in a forum and see who falls out.

The Deanonymization Chain: How a Machine Goes From Posts to a Name
#

Machine deanonymization runs as a three-stage chain — extract, search, verify — and you do not have to defeat all of it to be safe; you have to break any one link well enough to push your profile below the adversary’s effort budget. Seeing the chain as discrete stages is what turns a vague dread (“AI can find me”) into a defensible map, because each stage has a different weak point.

Stage one, extract and embed. The model reads your public writing and pulls out structured signal: a probable region from idioms and timestamps, an occupation from vocabulary, an income band from the things you mention buying, and — most durably — a linguistic fingerprint, the statistical shape of how you write. None of this requires you to have stated any of it. The ETH Zurich work is the evidence that this stage alone already exposes location, income, and sex from plain text.

Stage two, search and rank. Those signals become a query against a pool of candidate identities — other platforms, public profiles, leaked datasets — and the system ranks who you are most likely to be. This is the step that scales: an embedding search over tens of thousands of candidates is cheap, and it degrades gracefully, narrowing rather than failing when the data is thin.

Stage three, verify and link. A reasoning model takes the strongest candidates and cross-checks them — does this LinkedIn job history fit the hobbies in those Reddit posts? does the timeline line up? — until one survives. In the 2026 preprint this is the agentic step that produced the Hacker News-to-LinkedIn match. It is also where a safety assumption gets tested: refusal training catches the blunt request — “deanonymize this person” — far more reliably than the same goal pursued through a chain of innocuous-looking subtasks.

The practical lesson is that the chain is strongest where you are most consistent. The same handle, the same turns of phrase, the same posting rhythm across contexts are what let stage two find a join. Inconsistency — deliberately introduced — is what breaks it.

Why a Perfect Bitcoin Alias Still Isn’t Anonymous
#

On-chain privacy and text-inference privacy are two different threat models, and tools that solve one do nothing for the other. CoinJoin, Silent Payments, and Monero protect the transaction graph; they do not touch the forum posts, support requests, and social replies that link your alias to you. This is the gap I see Bitcoin-privacy guidance miss most often: it treats anonymity as an on-chain property when, for a named pseudonym, the cheapest attack is entirely off-chain.

Consider the shape of it. You can break the link between your coins and your identity perfectly — coinjoined UTXOs, a fresh address per payment, no KYC anywhere. None of that matters if you also run a pseudonymous account where you describe your node setup, your time zone, and your opinions in a voice a model can match to your other writing. The chain in the previous section does not read the blockchain at all; it reads you. Chain analysis and text inference can even be run side by side — one clusters your transactions, the other attaches a person to the cluster — but you do not need the on-chain half for the off-chain half to work.

So the correct mental model is additive, not either/or. On-chain privacy is necessary and worth doing; it is simply not sufficient for someone whose threat model includes being named. If you maintain a Bitcoin pseudonym, the text-OPSEC in the next section is the half of the work that the privacy-coin conversation usually leaves out.

Privacy technique	What it protects	What it does not touch
CoinJoin / Silent Payments	The on-chain transaction graph	Forum posts, writing style, timestamps
Monero / privacy coins	Amounts, sender, receiver on-chain	Off-chain text that names the spender
VPN / Tor	Network-layer IP correlation	What you actually write, anywhere
Account separation alone	The obvious name link	The inferable link from patterns

Breaking the Chain: A Compartmentation Playbook for the AI Era
#

The defense that works is compartmentation aimed at the inference chain, not at any single post — making your contexts share as few linkable features as possible so stage two has nothing to join. Deletion is not on this list, because removing one post rarely removes the pattern that exposed you; prevention at the point of publication is the only control that fully holds.

Separate identities, all the way down. A pseudonym is only as strong as its least-separated layer: different username, different email, different device or browser profile, different network. Shared infrastructure is the easiest join of all.
Diversify the linguistic fingerprint. This is the defense most people skip. Vary register between identities — formal in one, casual in another — and avoid the signature phrases, emoji habits, and punctuation tics that a model uses to cluster your writing. Reusing a memorable turn of phrase across two accounts can undo every other precaution.
Randomize timing. Posting on a fixed daily schedule in your real time zone is a location and routine signal. Spread activity, add jitter, and do not let your “anonymous” account keep office hours in your own city.
Strip metadata before anything leaves your hands. EXIF location in photos, document properties, and consistent ISP correlation are confirmations a model is glad to use. Remove them at the source.
Retire pseudonyms on a schedule. An identity accumulates inferable history the longer it lives. For higher-risk personas, periodically retiring and re-establishing a handle resets the baseline an adversary has built.

None of these is exotic; together they are the difference between being the cheapest profile in a forum to resolve and being one the attack skips. For the tooling layer — a no-logs VPN, a separate mailbox, identity-separation utilities — the EFF’s Surveillance Self-Defense is a level-headed reference, and the principle is the same one this site applies to itself: use the smallest set of tools that actually break a link, and disclose them honestly rather than chase a checklist.

Before AI, This Took a Human and a Lot of Time
#

It helps to be precise about what changed, because the headline cases everyone remembers were not AI at all — they were slow, manual, human work. The shift AI introduces is not a new capability so much as the removal of the cost and patience those cases used to require. Framing the older incidents honestly is the point: they show how much friction used to protect you, and therefore how much you lose when it disappears.

The streamer known as Dream was located in 2021 after fans matched a kitchen photo to a real-estate listing on Zillow — human eyes, a public database, no inference model in sight. The harassment campaign against the activist Keffals in 2022 ran on hand-collected OSINT and a forum’s collective effort, not a machine. The 2023 doxxing of students over a campus statement ran on manual archive research and paid targeted advertising. Every one of these took motivated people and real time. That was the tax that kept most pseudonyms safe: an adversary had to want it enough to spend hours.

The deanonymization chain removes the tax. What a forum mob once did to one target over days, an agent can now attempt against an entire community for a few dollars a head — and it does so without ever getting tired or bored. This also lands unevenly. Impersonation, fabricated intimate imagery, and the harassment-to-doxxing pipeline fall disproportionately on women and on anyone with a motivated antagonist, which makes inference resistance a matter of bodily and reputational safety, not only data hygiene. The protections in the previous section matter most for exactly the people the old, expensive version of this attack already targeted.

Bottom Line — How Much Compartmentation Do You Actually Need?
#

The right level of effort is the one that matches who you are protecting yourself from — there is no single setting, only a threat model.

If you have no specific adversary: the highest-leverage moves are linguistic and temporal. Don’t reuse a distinctive handle or writing style across accounts you want kept apart, and don’t post your “anonymous” identity on your own clock. Skip the heavier tooling until you have a reason.
If you maintain a real pseudonym — a creator, a writer, anyone whose name and alias must not connect: compartment ruthlessly across device, network, and language, and assume the on-chain half of your privacy does nothing for the off-chain half.
If you carry asymmetric risk — women facing harassment, activists, public-facing professionals: treat linguistic diversification and out-of-band verification as non-optional, and plan for identity retirement before you need it.

Across all three, the same truth holds that held before machines entered the picture: you cannot reliably delete your way to safety after the fact. You can only model the adversary you actually have, break the chain at the link you can afford to defend, and publish less of what a machine would be glad to keep.

Key Takeaways

Inference: language models infer location, income, and sex from ordinary text at up to 85% top-1 accuracy (Staab et al., ICLR 2024) — anonymity by omission no longer holds.
Scale: an agentic model matched 67% of Hacker News users to their LinkedIn profiles at 90% precision for roughly $1–4 each (Lermen et al., 2026 preprint) — the human friction is gone.
Independent vector: on-chain privacy (CoinJoin, Silent Payments, Monero) protects the transaction graph, not the forum posts and writing style that link an alias to a person.
Defense: break the chain — separate identities across device and network, diversify your writing register, randomize posting times, and strip metadata; deleting one post does not remove the inferable pattern.
Uneven harm: harassment-driven deanonymization and impersonation fall hardest on women and public pseudonyms, which makes out-of-band verification and linguistic separation non-optional.

Frequently Asked Questions
#

Can AI really deanonymize me from anonymous posts?
#

Often, yes. Anonymity by omission — leaving your name off a post — is weak against inference, because a model can derive location, employer, and other attributes from patterns in how and when you write, then match those signals against public profiles. In peer-reviewed testing (Staab et al., ICLR 2024) models inferred personal attributes from plain Reddit text at up to 85% top-1 accuracy. Strong unlinkability comes from compartmentation — separate usernames, devices, networks, and a varied writing style — not from withholding your name.

Does deleting my old posts stop inference?
#

Mostly no. Removing a single post rarely removes the pattern that exposed you, because the inference draws on consistent signals — your writing style, posting times, and recurring topics — spread across everything you have published. Deletion can reduce raw material at the margin, but the durable fix is preventing the linkable signal at the point of publication, not cleaning up afterward.

Do CoinJoin or a VPN protect me from this?
#

They protect a different layer. CoinJoin and privacy coins defend the on-chain transaction graph; a VPN or Tor defends network-level IP correlation. None of them touches the forum posts, support messages, and replies that a model reads to link a pseudonym to a person. They are worth using and simply not sufficient on their own — the text-OPSEC in this article is the complementary half.

What raises the cost of deanonymization the most?
#

Linguistic and contextual compartmentation. The deanonymization chain is strongest where you are most consistent, so the highest-leverage habit is to keep identities that must not connect from sharing a writing style, a posting schedule, and shared infrastructure. It is unglamorous and it is what actually raises an adversary’s cost above the few dollars the automated attack now requires.

#	Source	URL	Archived
1	Staab et al. — “Beyond Memorization: Violating Privacy via Inference with Large Language Models” (ICLR 2024)	https://arxiv.org/abs/2310.07298	https://web.archive.org/web/*/https://arxiv.org/abs/2310.07298
2	Lermen et al. — “Large-scale online deanonymization with LLMs” (arXiv preprint, 2026)	https://arxiv.org/abs/2602.16800	https://web.archive.org/web/*/https://arxiv.org/abs/2602.16800
3	Simon Lermen — “Large-Scale Online Deanonymization” (author explainer, 2026)	https://simonlermen.substack.com/p/large-scale-online-deanonymization	https://web.archive.org/web/*/https://simonlermen.substack.com/p/large-scale-online-deanonymization
4	Electronic Frontier Foundation — Surveillance Self-Defense (threat-modeling and compartmentalization guides)	https://ssd.eff.org/	https://web.archive.org/web/*/https://ssd.eff.org/

Two threads from elsewhere on this site connect here directly. The four assumptions AI breaks — with inference as one of them — are mapped in OPSEC in the AI Age: Rebuilding Your Threat Model, of which this article is the inference deep-dive. And because inference feeds on everything you have ever published, the audit of what actually survives deletion lives in How Permanent Is Your Social Media Footprint?. When the data being correlated was taken from an institution rather than posted by you, the related playbook is When the Government Leaks Your Data; for inference applied inside the workplace, see What Your Employer’s Slack Monitoring Actually Sees.

Job Applicant Doxxing: A Digital Footprint Audit (2026)

Thu, 30 Jul 2026 00:00:00 +0000

A note on funding: CypherpunkGuide carries no surveillance advertising - no ad networks, tracking pixels, or sponsored content. It is funded by transparent streams: reader donations now; subscription and editorially aligned affiliate links later. We answer to readers, not data brokers or screening vendors.

A resume is not just a career document. It is a compact set of identity anchors: your legal name, city, email, phone number, school, previous employers, and dates. A recruiter can use those anchors to find a professional profile. Doxxing - publishing identifying information to expose or target someone - can use them to attach an allegation. A background-report vendor can use them to match a public record, correctly or incorrectly. The same facts that document your qualifications also make separate pieces of the web easier to join.

That distinction matters because generic advice about making posts private solves only one part of the problem. A permanent social-media footprint can survive deletion, and an adversarial self-audit can reveal what your own archive leaks. The risk is concrete: in 2023, unsigned mailers reportedly named 26 students as allegedly connected to nine groups. This guide addresses how outside material becomes attributed to the person on an application, and what that applicant can verify before an interview.

We built a 15-row matrix: 12 evidence nodes across a public post that reached an employer, organized doxxing that attached people to a disputed affiliation, and commercial reports that a U.S. regulator alleged were inaccurate, plus three U.S. rights controls. We classified each row as confirmed, reported, alleged, unconfirmed, or federal guidance instead of turning a dramatic headline into a fact. The resulting Applicant Exposure Matrix is downloadable and auditable. This English edition uses a U.S. federal rights module; English language alone does not establish U.S. jurisdiction. If the job, employer, or screening company is elsewhere, keep the audit method and use that location’s regulator and applicant-data rules.

Use the method to find the weakest attribution, not to promise erasure.

How a Digital Footprint Becomes a Hiring Signal
#

A search result becomes a hiring signal only after someone attaches it to the applicant and uses it in a decision. Audit that chain - Anchor, Pivot, Attribution, Decision - because finding a page is not proof that it belongs to you.

Anchor: the application supplies stable facts such as a name, email, phone number, city, school, or employer.
Pivot: a searcher follows an anchor to a handle, image, group list, public record, or people-search report.
Attribution: matching facts are treated as proof that the result belongs to the applicant.
Decision: the attributed material changes an interview, offer, or formal adverse-action process.

Call this the Applicant Identity-Attachment Chain. It separates three routes that are usually blurred together:

Route	What creates the attachment	Weak point	Best applicant control
Direct public search	A hiring team searches the open web itself	Same-name collision, missing context, stale pages	Create a clean professional anchor and document false matches
Organized doxxing	A campaign publishes names, affiliations, or employer contacts	Unverified association amplified as fact	Preserve evidence, request correction, prepare a short verification packet
Third-party consumer report (U.S. module)	An employer obtains a report from a screening company	Bad source data or mistaken record matching	Use notice, report-copy, and dispute rights where the FCRA applies

The routes can overlap, but their remedies do not. A correction email may help with a public webpage. It cannot fix a consumer reporting agency’s file. A Fair Credit Reporting Act (FCRA) dispute may correct a report, but it does not remove a viral screenshot. Start by identifying the route.

Three Documented Failure Paths
#

Three cases expose three different attachment failures: disputed group affiliation, a public post routed inside an employer, and a commercial report alleged to misframe records. Their facts and remedies must stay separate.

Harvard, 2023: affiliation was treated as identity
#

In October 2023, a statement attributed to more than 30 Harvard student organizations triggered an organized effort to identify people connected to the groups. The Harvard Crimson later reported doxxing websites, a vehicle displaying student names and faces, and unsigned mailers identifying 26 students allegedly connected to nine groups. Some people disputed any relationship to the statement; the reporting said one person no longer belonged to the named organization. One anonymous graduate student told the Crimson that a company rescinded an offer after an investigation.

Those are separate facts, and the separation is essential. The reporting does not establish that the vehicle, a particular site, or a particular mailing caused an employer to withdraw an offer. Nor does appearing on a list prove that a student wrote, approved, or even knew about the statement. The case demonstrates a narrower and better-supported mechanism: a group affiliation can become a pivot from school and name to a public allegation, while the attribution remains contested.

For an applicant, the lesson is not to hide every association. It is to test whether search results state an association more confidently than the underlying evidence permits. If they do, preserve the claim, the URL, the date, and the contrary evidence before asking for a correction.

Cisco, 2009: a post reached the organizational graph
#

In 2009, Network World preserved a short public exchange. A prospective Cisco hire posted about weighing a paid job against disliking the work. A Cisco-affiliated employee replied publicly, asking who the hiring manager was. The exchange quickly became the “Cisco Fatty” story.

The documented event is the routing, not the employment outcome. The source does not establish that Cisco revoked the offer. Treating the episode as a proven firing story would repeat the attribution problem this article is meant to prevent.

What the case does show is how little information a direct route may need. A company name in a public post supplied the employer anchor; an employee supplied the internal pivot; the hiring manager was the intended destination. No background-check vendor or private-account access was required. A public post can reach an employment decision-maker through the organization’s own social graph.

FTC, 2023: a report can attach the wrong meaning to a record
#

The third route is structurally different. In 2023, the Federal Trade Commission alleged that TruthFinder and Instant Checkmate deceived users about the accuracy of background reports and violated the FCRA. The agency said some marketing alerts presented a traffic ticket as a criminal or arrest record and alleged that third-party data was not verified. A signed stipulated order entered October 11, 2023 imposed a joint $5.8 million civil penalty. The defendants did not admit or deny the underlying allegations except as needed for jurisdiction.

This is not merely a bad search result. When an employer obtains a consumer report from a company in the business of compiling background information, U.S. federal law generally creates a formal sequence: disclosure and written authorization before the report, a copy of the report and a Summary of Rights before adverse action, and notice plus dispute information after the decision. State and local laws may add requirements.

Pathway	Confirmed input	What is uncertain or disputed	Defensive evidence
Harvard reporting	Public campaign, group lists, 26 mailed names, one anonymously reported rescinded offer	Whether each person was affiliated; what caused the employment result	Organization records, dated screenshots, correction correspondence
Cisco reporting	Public post and Cisco-affiliated employee response	Whether an offer was revoked	Original post context, offer status, dated correspondence
FTC case	Agency complaint, case record, signed joint-penalty order	Underlying conduct was alleged, not admitted	Consumer report, source records, dispute file, employer notices

When we applied the four-stage chain to the matrix, a name search could catch the Cisco-style self-post. It could not resolve the Harvard affiliation disputes or reveal whether a consumer-report vendor had attached the wrong record. That is why “Google yourself” is a useful first step and an inadequate audit by itself.

What Employer Social-Media Surveys Actually Measure
#

There is no honest single percentage for 2026. Surveys use different populations and mix recruiting, candidate research, and formal screening, so use them to establish plausibility rather than predict what any employer will do.

A 2015 Society for Human Resource Management survey received 410 HR responses overall. Among valid responses to its screening items, SHRM’s combined finding was that 43% of organizations used public social media or online searches to screen candidates. Among the organizations that screened this way, 36% had rejected a candidate because of information they found. Those numbers are a historical baseline, not a current prevalence estimate.

A separate 2022 Harris Poll survey commissioned by Express Employment Professionals questioned 1,002 U.S. hiring decision-makers. It reported that 70% used social media to research potential candidates, 17% did so for every candidate, and 80% handled the research in-house. It also reported that 51% had never found content that caused them not to hire someone. The study is useful for showing how broad the practice can be under one definition, but it is sponsor-commissioned, U.S.-specific, and not a universal 2026 rate.

Treat public research as plausible, not universal.

What Employers May See - and Which Legal Lane It Uses
#

The key boundary is not “online versus offline.” It is who collected the information. A hiring manager’s direct public-web search and a report purchased from a consumer reporting agency can surface similar facts while triggering different processes.

Information source	What may surface	Process to look for	Important limit
Search engine and public profiles	Namesakes, public posts, biographies, images, organization pages	Usually an internal direct search	A match is not proof; FCRA permission is not automatically required for the employer’s own public lookup
Public social-media content	Posts, replies, visible photos, public connections	Direct search or a documented screening service	It does not grant general access to private messages or locked accounts; screenshots and reposts can still spread beyond those controls
Consumer report from a screening company	Identity data, public records, employment or education information within applicable rules	Stand-alone disclosure, written authorization, and adverse-action notices under the U.S. federal baseline	Scope and restrictions vary; state and local law may be more protective
Doxxing page or third-party allegation	Names, alleged affiliations, contact information, copied images	Often outside a formal screening process	Publication and repetition do not verify the allegation

Federal anti-discrimination rules still constrain how employers use background information regardless of whether it came from a public search or a report. That does not mean every political opinion is a federally protected characteristic, and it does not turn all unfairness into an FCRA claim. The Equal Employment Opportunity Commission and FTC both advise employers to apply standards consistently and not use background information in a discriminatory way.

The Seven-Step Pre-Interview Audit
#

Audit before a high-stakes application, but do not start by deleting. Record what an evaluator can attach to you first; then choose context, removal, separation, or a formal dispute. Use a personal device, not a workplace account.

1. Freeze the identity anchors in your application
#

List the exact forms of your name, email domain, phone number, city, schools, employers, job titles, dates, portfolio domain, and profile URLs you plan to submit. This is your anchor sheet. Do not add sensitive identifiers that are not already necessary for the application.

Mark which anchors are unique. A common name plus a rare employer and city can be more identifying than a distinctive name alone. Also note old names or transliterations that a legitimate record may use.

2. Run a bounded public search
#

Search the exact name in quotation marks, then combine it with one application anchor at a time: school, employer, city, or professional handle. Check at least two search engines because indexes differ. Review image results and the first few result pages; endless searching adds anxiety faster than coverage.

Search the public-facing application email and phone number only if doing so will not expose a sensitive value to a questionable site. Never enter a Social Security number, passport number, or full birth date into an unverified lookup service.

3. Build a pivot map
#

For each result, record which anchor found it and what new pivot it exposes: another handle, group, image, domain, address, or record. Stop when a pivot leaves the employment threat model. The objective is not to map your whole life. It is to see which application fact crosses into a risky context.

This step also catches AI-assisted deanonymization: a reused handle or writing pattern can link two identities even when your legal name never appears on the pseudonymous account.

4. Classify every material result
#

Use three labels:

Mine: the result is yours and the context is substantially accurate.
Not mine: it belongs to a namesake, impersonator, or unrelated record.
Ambiguous: some facts match, but ownership or context is not established.

Do not quietly promote “ambiguous” to “mine” because a result feels embarrassing. The attribution burden belongs in the audit. Record what confirms or contradicts the match.

5. Preserve evidence before changing anything
#

For a false, threatening, or consequential result, save a dated screenshot, full URL, page title, visible author or publisher, and a short note explaining the error. Where lawful and safe, save the page or PDF. Keep the evidence on a personal device, not an employer-managed machine.

Evidence preservation matters because a removal request may succeed while copied versions remain, or the page may change after you dispute it. If there is a credible physical threat, prioritize safety and local professional help over perfect documentation.

6. Apply the route-specific control
#

For your own accurate public post, add context, restrict visibility, separate handles, or remove it after preserving anything needed. For a false webpage, use the publisher’s correction or impersonation process and then request search-engine de-indexing where eligible. For organized doxxing, avoid public argument that amplifies the page; preserve, report, and ask a trusted person to monitor if viewing it is harmful.

For durable traces, use the deeper social-footprint permanence protocol. This audit deliberately does not duplicate its cache, archive, and downstream-copy workflow.

7. Prepare a correction packet
#

Make one short document you can use if an employer asks: the disputed claim, why it is wrong or incomplete, the supporting record, and a reliable contact or official source that can verify the correction. Keep it factual and small. A recruiter needs a resolvable discrepancy, not your complete harassment history.

If a consumer report is involved, keep the employer’s notices, the report itself, the reporting company’s contact details, your dispute, supporting documents, and delivery confirmation together. Correcting the report does not by itself reverse the hiring decision, but that packet creates a timeline if the error recurs.

Your U.S. Rights When a Background Report Is Used
#

When a U.S. employer obtains a consumer report from a reporting company, the FCRA generally creates notice, authorization, pre-adverse review, and post-adverse dispute steps.

This is general U.S. federal information, not legal advice. It applies by jurisdiction, not by the language of the applicant. Rules and exceptions vary, and state or local law may add protections.

According to FTC employer guidance, when an employer uses a company in the business of compiling background information, the employer generally must provide a clear written disclosure in a stand-alone format and obtain written permission before getting the report. If the employer may take adverse action based on the report, it must first provide a copy of the report and the FCRA Summary of Rights. That pre-adverse step is the moment to look for wrong people, outdated dispositions, duplicated records, or misleading descriptions.

If the product is an investigative consumer report based on personal interviews about character, reputation, or lifestyle, the same FTC guidance says the employer must also notify the applicant of the right to request a description of the investigation’s nature and scope.

After adverse action, the notice should identify the reporting company, state that the company did not make the employment decision, and explain the right to dispute the report’s accuracy or completeness. FTC applicant guidance also says you may ask the reporting company for an additional free copy within 60 days of the employer’s decision.

Stage	What the federal flow generally provides	Applicant action
Before the report	Clear disclosure and written authorization	Read the disclosure; keep a copy; ask what company will prepare the report
Before adverse action	Report copy and FCRA Summary of Rights	Compare identifiers and dispositions; dispute errors immediately with evidence
After adverse action	Reporting-company details and dispute notice	Request the additional free report within 60 days; preserve the decision timeline

This sequence is specific to the consumer-report lane. If a recruiter rejects an applicant after the recruiter’s own public search, the FCRA report-copy process may not apply. Other anti-discrimination, privacy, record-sealing, or local hiring laws may still matter; a qualified local lawyer or legal-aid organization is the right escalation for a consequential case.

What Cleanup Cannot Fix
#

Cleanup can reduce exposure, but it cannot prove a negative or recall a copied allegation. The goal is a smaller and more accurate attachment surface, not a spotless first page of search results.

A deleted post can remain in screenshots, archives, or someone else’s quote. A correction can coexist with the original headline. A disputed consumer report can be rebuilt from the same bad source later. And a well-compartmented identity can still be targeted by someone who already knows the connection. This is why the audit produces records as well as removals.

It also has a human limit. Repeatedly searching harassment pages can become its own harm. If you are already being targeted, give a trusted person a precise monitoring brief instead of compulsively checking. If home information or a physical threat appears, move from reputation management to a safety plan; workplace-monitoring defenses address a different, post-hire threat and should not be substituted for doxxing response.

Bottom Line - Match the Defense to the Route
#

Match the remedy to the route: control context for your own public material, preserve disputed attribution in a doxxing claim, and use report-copy and dispute rights for a third-party consumer report.

The highest-leverage question is not “what embarrassing thing can an employer find?” It is: which fact on my application leads to which claim, how strong is the match, and who has the power to correct it? That question turns a vague digital footprint into a finite set of joins you can test.

Frequently Asked Questions
#

The questions below separate plausible employer research from capabilities and rights that are often overstated. The answers keep direct public search, private accounts, deletion, and third-party consumer reports in their proper lanes.

Do employers Google every job applicant?
#

No reliable source supports “every.” A 2022 Harris Poll survey of 1,002 U.S. hiring decision-makers reported that 70% used social media to research candidates and 17% did so for every candidate, but definitions and practices vary. Treat public research as plausible, not universal, and audit the high-confidence routes from your application.

Can an employer see private social-media accounts or messages?
#

A normal public-web search does not unlock private messages or a locked account. However, public replies, copied posts, screenshots, shared contacts, and previously public pages may reveal material outside the current privacy setting. Do not treat a lock icon as retroactive erasure.

Does an employer need my permission to search my name online?
#

FTC guidance distinguishes an employer’s own public research from obtaining a consumer report through a company that compiles background information. The FCRA’s written-permission process generally applies to the latter, not automatically to every direct public search. Other laws and employer policies may apply.

What should I do if a background report belongs to someone with the same name?
#

Use the pre-adverse copy to identify the mismatched fields, then dispute the report with the consumer reporting agency and provide narrow evidence that separates you from the other person. Keep the report, the employer’s notices, your dispute, supporting records, and proof of delivery. Do not send more identity data than the legitimate process requires.

Should I delete old posts before applying for a job?
#

Review them, but do not mass-delete first. Preserve any false attribution, impersonation, harassment, or context that may matter in a dispute. Then reduce accurate, controllable exposure according to the route. Deletion is risk reduction, not erasure; caches, archives, screenshots, and quoted copies can remain.

References
#

Each external claim set below has both a live source and an exact Internet Archive replay. The list moves from U.S. regulator guidance and orders to the two reported cases and historical employer surveys.

#	Source	URL	Archive
1	FTC - Background Checks: What Employers Need to Know	https://www.ftc.gov/business-guidance/resources/background-checks-what-employers-need-know	https://web.archive.org/web/20260717052817/https://www.ftc.gov/business-guidance/resources/background-checks-what-employers-need-know
2	FTC - Employer Background Checks and Your Rights	https://consumer.ftc.gov/articles/employer-background-checks-and-your-rights	https://web.archive.org/web/20260423200314/https://consumer.ftc.gov/articles/employer-background-checks-and-your-rights
3	FTC - TruthFinder LLC, FTC v. (case page linking the signed order)	https://www.ftc.gov/legal-library/browse/cases-proceedings/truthfinder-llc-ftc-v	https://web.archive.org/web/20260521224619/https://www.ftc.gov/legal-library/browse/cases-proceedings/truthfinder-llc-ftc-v
4	FTC - Fair Credit Reporting Act, revised March 2026	https://www.ftc.gov/legal-library/browse/statutes/fair-credit-reporting-act	https://web.archive.org/web/20260719204956/https://www.ftc.gov/legal-library/browse/statutes/fair-credit-reporting-act
5	EEOC and FTC - Background Checks: What Job Applicants and Employees Should Know	https://www.eeoc.gov/laws/guidance/background-checks-what-job-applicants-and-employees-should-know	https://web.archive.org/web/20260723022448/https://www.eeoc.gov/laws/guidance/background-checks-what-job-applicants-and-employees-should-know
6	The Harvard Crimson - Doxxing Attacks, Employment Losses (Dec. 2023)	https://www.thecrimson.com/article/2023/12/8/doxxing-students-palestine-feature/	https://web.archive.org/web/20260720063907/https://www.thecrimson.com/article/2023/12/8/doxxing-students-palestine-feature/
7	Network World - The Cisco public-post exchange (Mar. 2009)	https://www.networkworld.com/article/763101/cisco-subnet-tweeted-out-of-a-job-the-cisco-fatty-story.html	https://web.archive.org/web/20250820182213/https://www.networkworld.com/article/763101/cisco-subnet-tweeted-out-of-a-job-the-cisco-fatty-story.html
8	SHRM - HR Weeds Out Applicants Through Public Social Media Searches (2015 survey)	https://www.shrm.org/topics-tools/news/talent-acquisition/hr-weeds-applicants-public-social-searches	https://web.archive.org/web/20260410095524/https://www.shrm.org/topics-tools/news/talent-acquisition/hr-weeds-applicants-public-social-searches
9	Express Employment Professionals / Harris Poll - Social Media Integral to Recruiting (2022 survey)	https://www.expresspros.com/newsroom/news-releases/news-releases/2023/05/social-media-integral-to-recruiting-as-most-businesses-use-it-to-source-research-and-screen-candidates	https://web.archive.org/web/20251216153245/https://www.expresspros.com/newsroom/news-releases/news-releases/2023/05/social-media-integral-to-recruiting-as-most-businesses-use-it-to-source-research-and-screen-candidates

Cora Aegis

Cora Aegis writes privacy-first OPSEC guidance at CypherpunkGuide. For this article, she reconstructed 12 evidence nodes across public search, organized doxxing, and consumer-report pathways, then mapped three U.S. rights controls while preserving uncertainty where reporting could not prove causation.

More about Cora ->

What AI Geolocation Can Find in One Photo (2026)

Sat, 04 Jul 2026 00:00:00 +0000

I publish under a pseudonym and an AI-generated portrait, so “just keep your face out of frame” was never going to be my whole answer to location privacy. The uncomfortable part is what stands behind the face. In April 2025, a developer sat OpenAI’s o3 model against a GeoGuessr Master — a top-ranked human at the game of naming a place from a single street view — and the model won, 23,179 points to 22,054, correctly naming the country in all five rounds and landing within a few hundred meters twice. In the same tests, o3 ignored fake GPS coordinates planted in the file’s metadata and reasoned its way to the real location from the pixels alone.

That last detail is the whole story. For twenty years, the standard advice for photo privacy was “strip the EXIF” — remove the hidden GPS tag your phone writes into the file. It was good advice against what is now the easy half of the problem. The hard half is that a machine can read the rooftops, the plants, the road paint, the angle of the sun, and the script on a shop sign, and place you with no metadata at all. A Stanford model called PIGEON identifies the country of an ordinary photo 91.96% of the time and beat a world-champion GeoGuessr player across six straight games. On one 2025 benchmark, a general-purpose Gemini model pinned the correct city 64.3% of the time; the humans it was measured against managed 1.7%.

So the question here is not “can AI find your location” — it can — but what actually changes your exposure once it can. Working through the public benchmarks and Bellingcat’s own field guides, I traced how a locator narrows a photo, then ran that chain backward into a defense. The short version: location now leaks in two layers, and they have different fixes. The metadata layer you can clean. The visible layer you can only manage — by controlling what is in the frame and when it goes out, the same way an open-source investigator would work the problem in reverse.

What One Photo Gives Away, Now That AI Reads It
#

AI geolocation is the inference of where a photo was taken from its visible content — buildings, vegetation, road markings, sun angle, signage — rather than from any GPS tag. This is the shift that matters: the capability recently crossed from “a skilled human hobby” to “a cheap, fast, automated guess,” and it did so against expert players, not novices. The numbers below come from peer-reviewed benchmarks and one widely reproduced head-to-head, not from vendor marketing.

The scale of the gap between machine and human is the part most people underestimate. On a 2025 academic benchmark, a Gemini model reached 83.7% country-level and 64.3% city-level accuracy, while human testers on the same images scored 9.5% and 1.7%. A human who is good at this — a ranked GeoGuessr player — is still competitive, which is exactly why o3 beating a Master, and PIGEON sweeping a champion, are the alarming results: the ceiling, not the average, is what an adversary rents.

System	Country-level	City-level	Note
PIGEON (Stanford, 2024)	91.96%	median error ~44 km	Beat a GeoGuessr champion 6 games to 0
Gemini (2025 benchmark)	83.7%	64.3%	Same benchmark, humans: 9.5% / 1.7%
GPT-4o (2025 benchmark)	74.0%	63.3%	Consumer-facing model, same human-comparison set
o3 (2025, head-to-head)	all 5 rounds	within a few hundred m ×2	Beat a human Master; ignored fake EXIF

Two caveats keep this honest. First, accuracy is uneven: models do markedly better on North America and Western Europe than on under-represented regions, so “AI can’t place my town” is sometimes true and never something to rely on. Second, specialized tools go further than general chatbots. GeoSpy, a commercial system from Graylark Technologies, was trained on tens of millions of street-level images; the company claims street-level precision on good inputs. Its trajectory is its own warning: after launch, users posted videos asking it to locate specific women, and the company pulled public access and restricted the tool to law-enforcement, enterprise, and government customers. The capability is real enough that its makers decided the public could not be trusted with it.

How an Investigator Locates a Photo — and Why That Helps You
#

An open-source investigator does not need AI to place a photo; the discipline of geolocation — confirming where an image was taken from visible evidence — predates the models by a decade. Understanding their method matters because a good defense is their method run backward: the clues they hunt for are exactly the ones you want out of your frame. Bellingcat, the investigative outlet that formalized much of this practice, teaches it as a checklist of layers.

The layers stack from coarse to fine. Chronolocation uses shadows: the length and direction of a shadow, matched against a sun-position calculator for a candidate date, narrows both the time of day and the latitude. Architecture and infrastructure narrow the country — utility-pole design, traffic-signal shape, curb and bollard styles differ by jurisdiction, and reference databases catalog those differences. Vegetation distinguishes climates and regions. Signage and script often hand over a city or a single street outright. And reflections — a shopfront window, a car mirror, sunglasses — can expose what the camera was pointed away from. Bellingcat’s confirmation of the MH17 convoy route — tracing the transporter that carried the missile which downed a passenger airliner over Ukraine in 2014 — was built from exactly this kind of stacking: shadow analysis plus landmark matching, pinned to an exact stretch of road.

What AI changed is not the method but the cost. A human investigator spends hours per image; a model runs the same inference in seconds for cents, and can be pointed at thousands of images at once. The defensive takeaway is precise and slightly liberating: you do not have to defeat a genius, you have to remove the stackable clues. Every layer you deny — no signage, no distinctive skyline, no reflective surface, no unobstructed shadow — is a layer the locator, human or machine, no longer gets to use.

The Two Layers of Location Leakage
#

Here is the frame that reorganizes everything else, and the one most guides blur: a photo leaks location on two independent layers, and only one of them is a solved problem. Conflating them is why “I stripped the metadata” gives people a confidence they have not earned.

Layer 1 is metadata — the EXIF block your camera writes into the file, including, if location services were on, exact GPS coordinates. This layer is solvable. The data is discrete, it sits in a known place in the file, and you can remove it completely before the photo ever leaves your device. Strip it and that coordinate is simply gone.

Layer 2 is content — the visible scene itself. This is what vision models read, and it is not strippable, because it is not attached to the photo; it is the photo. You cannot delete the architecture without deleting the picture. When o3 ignored the fake GPS tag and located the image from its pixels, it was demonstrating that Layer 2 now stands on its own — an adversary who gets nothing from Layer 1 still has the whole visible frame to work with.

That reframes the entire defense. Layer 1 is a cleaning problem: do it once, mechanically, every time. Layer 2 is a composition problem: it is decided when you press the shutter and when you press post, and no after-the-fact tool fixes a skyline you already published. The rest of this article treats them separately, because treating them together is the mistake.

“But I Stripped the Metadata” — What That Actually Fixes
#

Stripping metadata is necessary and no longer sufficient. It closes Layer 1 cleanly and does nothing for Layer 2 — and even within Layer 1, the platform behavior most people rely on is narrower than they think. Two beliefs need dismantling: that social platforms already handle this for you, and that a quick screenshot launders a photo clean.

Most major platforms do re-encode public uploads and drop the EXIF block from the version other users can download — but the guarantees are conditional. Independent metadata-testing services report, as of 2026, that the exception is consistent across apps: “send as document” or “send as file” modes bypass the re-encode and preserve everything, one tap away from the safe path and with no warning. And stripping the public copy is not the same as deletion — Meta’s own privacy policy describes retaining original image data server-side for its own purposes. The table below is a synthesis of tested behavior and official policy; treat it as “where the traps are,” not as a promise about any single upload.

Path	Public EXIF	The trap
Instagram / Facebook (public post)	Stripped on the downloadable copy	Original retained server-side; higher-quality DM sends can differ
X (public post)	Stripped	Internal retention; scheduling and third-party API clients are unverified
Reddit (native `i.redd.it`)	Stripped on re-encode	External image hosts (e.g. imgur links) may preserve GPS
TikTok (post)	Stripped	App collects location by other means; strip ≠ untracked
WhatsApp / Signal / Telegram (photo mode)	Stripped by compression	“Document / send as file” preserves full EXIF, no warning

The screenshot myth deserves its own line, because search engines keep recommending it. Taking a screenshot does produce a new file without the original GPS tag — it is a real Layer 1 fix. It does nothing whatsoever for Layer 2: the screenshot still shows the same street, the same skyline, the same shop sign, and a model reads those exactly as well from a screenshot as from the original. A screenshot changes the file; it does not change the frame.

A Defense Protocol That Matches Your Threat Model
#

There is no single correct amount of caution here — the right protocol depends on who might be looking and what they could do with a hit. Blanket rules like “never post outdoors” are unlivable and, for most people, unnecessary; the useful move is to match effort to threat — the same threat-modeling logic EFF’s Surveillance Self-Defense is built around. The tiers below escalate: everyone should do the baseline, and each higher tier adds to the one before it rather than replacing it.

The dividing line between tiers is consequence. For a casual sharer, a located photo is a privacy nick. For a public creator or a woman already facing harassment, it is a step toward a real-world encounter — and this is not hypothetical, given that AI geolocation feeds the same stalking and intimate-partner violence (IPV) threats Privacy International catalogs in its risk taxonomy, and given why GeoSpy’s makers shut the public door. For an activist, journalist, or abuse survivor, a single geolocated frame can be a physical-safety event. Locate yourself on that ladder first, then apply the matching row.

Tier	Who	Add these habits
Baseline (everyone)	Casual sharer	Strip EXIF locally before upload (don’t rely on the platform); never post home, work, or your child’s school in real time; remember a screenshot is not safe
Elevated	Public persona, creators, anyone facing harassment	Delay posting so “here now” becomes “here last week”; scrub backgrounds — windows, reflections, license plates, distinctive skylines; avoid recurring, routine locations
High	Activist, journalist, IPV survivor, whistleblower	Assume any published photo is permanently geolocatable; run a “what does this frame reveal” review before posting, not after; keep a device and account compartment that never carries location-bearing images

Three techniques need honest labels so you don’t over-trust them. Stripping EXIF is best done locally and mechanically — the command-line tool ExifTool removes everything in one pass (exiftool -all= photo.jpg), and because it runs on your machine, the photo never leaves it. Delayed posting defeats real-time leakage — an adversary learning where you are right now — but does nothing against retrospective analysis, because the background still resolves to a place whenever it is examined. And blurring the background is weaker than it looks: a light blur can be partially reversed by deblurring, so the honest options are heavy pixelation or simply not including the thing. Name each technique by the layer it addresses, and you stop confusing “I did something” with “I am covered.”

Bottom Line — How Much Should You Actually Do?
#

For most people, the whole protocol collapses to two habits: strip metadata locally as a reflex, and stop posting the places you return to — home, work, the school run — in real time. That closes Layer 1 completely and denies Layer 2 its most valuable clue, which is a routine location an adversary can act on. Everything above that is threat-model-dependent, and the people who need the high tier usually already know who they are.

The mental shift is the durable part. The old question — “did I remember to turn off geotagging?” — is a Layer 1 question, and Layer 1 is nearly automatic once ExifTool is a habit. The question that protects you now is a Layer 2 question: what does this frame say about where I am, and would I hand that to a stranger who wanted to find me? When I audit a photo before it goes out, that is the only question I ask, because it is the only one the machines can no longer be stopped from answering for me.

Key Takeaways

Two layers, two fixes: EXIF metadata is solvable (strip it locally); the visible background is not strippable and can only be managed by composition and timing.
AI beats experts, not just novices: PIGEON identifies a photo’s country 91.96% of the time and swept a GeoGuessr champion 6–0; a Gemini model hit 64.3% city-level where humans scored 1.7%.
Stripping metadata is necessary, not sufficient: o3 located photos after their GPS tags were faked, reading the pixels alone — and a screenshot removes EXIF but keeps the whole geolocatable frame.
Platform stripping has traps: public posts are usually re-encoded, but “send as document/file” modes preserve full EXIF, and platforms may retain the original server-side.
Match effort to threat: everyone should strip EXIF and avoid real-time home/work posts; creators and harassment targets add delay and background scrubbing; activists and survivors treat every published photo as permanently locatable.

Frequently Asked Questions
#

Does stripping the EXIF data hide my location?
#

It solves half the problem. Removing EXIF deletes the exact GPS coordinate your camera embedded — a real and worthwhile fix. But modern vision models infer location from the visible scene — architecture, vegetation, sun angle, signage — with no metadata at all. In documented tests, OpenAI’s o3 located photos even after their GPS tags were replaced with fakes. Strip metadata as a baseline, then treat the picture’s actual content as the harder, unsolved layer.

Is posting a screenshot instead of the original photo safe?
#

A screenshot removes the original EXIF, so it closes the metadata layer — but it changes nothing about the image itself. The street, skyline, and any readable signs are still in frame, and an AI reads them from a screenshot exactly as well as from the original file. A screenshot changes the file, not the frame; it is not a geolocation defense.

Can AI really locate a photo better than a person?
#

Yes, and against skilled people, not just novices. A Stanford model, PIGEON, identifies a photo’s country 91.96% of the time and beat a world-champion GeoGuessr player across six games. On a 2025 benchmark, a Gemini model reached 64.3% city-level accuracy where human testers scored 1.7%. Accuracy is uneven by region, but the ceiling — what a determined adversary can rent — is very high.

Does blurring the background protect me?
#

Only if it is heavy enough. A light blur or low-strength pixelation can be partially reversed by deblurring techniques, recovering text and detail. If a background element would give away your location — a street sign, a distinctive building, a reflection — the reliable options are heavy pixelation or excluding it from the shot entirely, not a soft blur.

What is the single highest-value habit?
#

Stop posting your recurring, real-world locations — home, workplace, your child’s school, the gym you go to on a schedule — especially in real time. A one-off vacation photo is a smaller risk than a routine an adversary can act on. Combine that with stripping EXIF locally before upload, and you have closed the metadata layer and denied the content layer its most actionable clue.

#	Source	URL	Archived
1	Privacy International — “Nowhere to Hide? Privacy Risks and Policy Implications of AI Geolocation” (2026)	https://privacyinternational.org/report/5736/nowhere-hide-privacy-risks-and-policy-implications-ai-geolocation	https://web.archive.org/web/*/https://privacyinternational.org/report/5736/nowhere-hide-privacy-risks-and-policy-implications-ai-geolocation
2	Haas et al. — “PIGEON: Predicting Image Geolocations” (Stanford, CVPR 2024)	https://arxiv.org/abs/2307.05845	https://web.archive.org/web/*/https://arxiv.org/abs/2307.05845
3	Huang et al. — “AI Sees Your Location, But With A Bias Toward The Wealthy World” (VLMs as GeoGuessr Masters, arXiv, 2025)	https://arxiv.org/abs/2502.11163	https://web.archive.org/web/*/https://arxiv.org/abs/2502.11163
4	Sam Patterson — “Can o3 beat a GeoGuessr Master?” (2025)	https://sampatt.com/blog/2025-04-28-can-o3-beat-a-geoguessr-master/	https://web.archive.org/web/*/https://sampatt.com/blog/2025-04-28-can-o3-beat-a-geoguessr-master/
5	Simon Willison — “o3 beats a GeoGuessr master” (2025)	https://simonwillison.net/2025/Apr/28/o3-geoguessr/	https://web.archive.org/web/*/https://simonwillison.net/2025/Apr/28/o3-geoguessr/
6	Bellingcat — “Using the Sun and the Shadows for Geolocation” (2020)	https://www.bellingcat.com/resources/2020/12/03/using-the-sun-and-the-shadows-for-geolocation/	https://web.archive.org/web/*/https://www.bellingcat.com/resources/2020/12/03/using-the-sun-and-the-shadows-for-geolocation/
7	TechNADU — “GeoSpy Sparks Privacy Concerns After Public Misuse” (2025)	https://www.technadu.com/ai-powered-tool-geospy-sparks-privacy-concerns-after-public-misuse/570730/	https://web.archive.org/web/*/https://www.technadu.com/ai-powered-tool-geospy-sparks-privacy-concerns-after-public-misuse/570730/
8	Electronic Frontier Foundation — Surveillance Self-Defense	https://ssd.eff.org/	https://web.archive.org/web/*/https://ssd.eff.org/
9	Meta — Privacy Policy (image metadata retention)	https://www.facebook.com/privacy/policy/	https://web.archive.org/web/*/https://www.facebook.com/privacy/policy/

This article is the photo-specific companion to a wider thread on this site. The same machine inference, applied to your text rather than your images, is mapped in AI Deanonymization: How Inference Undoes Your Anonymity, and the assumptions AI breaks across your whole threat model are laid out in OPSEC in the AI Age: Rebuilding Your Threat Model. Because a located photo, once posted, does not un-post, the audit of what actually survives deletion lives in How Permanent Is Your Social Media Footprint?. For the same threat aimed at your body rather than your background, see Your Voice and Face Are Credentials Now; and for how these techniques converge on a real target, How Streamers Get Doxxed — and the Pseudonym Playbook.

Your Voice and Face Are Credentials Now: OPSEC Against AI Cloning (2026)

Thu, 18 Jun 2026 00:00:00 +0000

I publish under a pseudonym, and I am a woman, so this is the threat I weigh before I record anything. The old assumption behind a familiar voice or face was that it authenticated itself: if your mother heard your voice on the phone, it was you, because forging it required your participation. That assumption is gone. The same biometric features you treat as proof of “you” — the timbre of your voice, the geometry of your face, even the rhythm of your writing — are now raw material a model can use to impersonate you, from samples you published yourself.

This is the fourth broken assumption from the AI-age threat model, and it deserves its own treatment because the defense is unusual: it is almost entirely preventive. You cannot recall a voice sample, and as we will see, you cannot reliably make a model forget one. So the work is front-loaded — what you release, and what you agree in advance with the people who would be targeted through you. Below is the dual nature of the problem, why it falls unevenly on women and on anyone who publishes under a name, the minimisation that lowers your exposure, and the full verification protocol that the previous article only promised.

Your Biometrics Became Logins and Targets at the Same Time
#

A credential is something that proves identity; an attack surface is something an adversary can exploit. Voice, face, and writing style are now both at once — the same features that vouch for you also let a model forge you. The collapse is recent and measured. Microsoft researchers showed in 2023 that their VALL-E model could synthesise a speaker’s voice from only a three-second sample; a handful of photos is enough for a convincing synthetic likeness; a corpus of your posts is enough to mimic how you write. None of this requires your cooperation beyond having published in the first place.

What makes this a credential problem and not just a forgery problem is that institutions started trusting biometrics precisely as they became cheap to fake. Banks deployed voiceprint phone authentication; families rely on a recognised voice; assistants unlock to a face. The U.S. Federal Trade Commission flagged the consequence directly, launching a Voice Cloning Challenge in November 2023 and publishing Approaches to Address AI-enabled Voice Cloning in April 2024. The thing that authenticates you is now the thing that compromises you.

Your biometric	Trusted today as a credential by	Now also an attack surface because
Voice	Bank phone-ID, family trust, voice assistants	A ~3-second clip yields a convincing clone
Face	Photo-ID checks, social proof, device unlock	A handful of images yields a synthetic likeness
Writing style	“It sounds like them”	A corpus of posts enables style transfer

The defensive consequence is that you should stop thinking of these as self-authenticating. A voice on the phone is no longer proof; a face in a video is no longer proof. Everything downstream in this article follows from accepting that.

Why This Lands Hardest on Women and Pseudonyms
#

This risk is not evenly distributed. Impersonation, fabricated intimate imagery, and voice-based fraud fall disproportionately on women and on anyone with a motivated harasser — which makes it a question of bodily and reputational sovereignty, not merely data hygiene. The evidence is consistent across sources. A 2019 Deeptrace study found 96% of deepfake videos were pornographic and that effectively all targeted individuals were women; a 2023 industry survey by the deepfake-tracking firm Security Hero put the pornographic share at 98%, with 99% of targets being women. These are tracking studies, not government data — but their direction is corroborated by harder reporting.

In December 2024, the American Sunlight Project found that roughly one in six women in the U.S. Congress — about 16% — had been depicted in non-consensual deepfake imagery, and that women were targeted some 70 times more often than men (first reported by The 19th). UN Women, reviewing the broader pattern, notes that more than half of deepfake victims in the United States contemplated suicide, and that digital violence routinely spills into offline harassment. The harm is not abstract reputational risk; it is targeted, gendered, and designed to silence.

For a pseudonymous creator the bind tightens into a contradiction. A named persona is built on voice and presence — a podcast, a talk, a face that makes the work feel human — yet every clean recording and every face-forward photo is also training data for someone who wants to impersonate that persona or attach it to my legal self. Minimisation, the first defense below, trades directly against reach. I will not pretend that tension away; I will show how to manage it instead of being managed by it.

Prevention First: Minimise the Samples You Publish
#

The first lever is minimisation: reduce the volume and clarity of the raw biometric samples you put into public, accepting that this is mitigation, not a cure. This is the same logic that governs AI-scale deanonymization — the cheapest attack reads what you already published, so the highest-leverage control is upstream of any takedown. A clone’s quality is bounded by its training material. Long, clean, solo recordings are the ideal sample; noisy, short, co-present audio is a poor one. You get to choose which you supply.

Concretely, that means separating the named persona’s media from high-fidelity biometric capture wherever you can, and stripping the metadata that pins a sample to a time and place. For a public creator the goal is not silence — it is deliberate degradation of sample quality relative to reach: co-hosted audio instead of solo monologue, an illustrated avatar carrying the named identity instead of a face tied to a legal name, and a hard refusal to let your voice double as an authentication factor.

What you publish	The risk it creates	Lower-exposure alternative
Long, clean, solo voice recordings	A high-fidelity training sample	Shorter clips; co-hosted audio; ambient noise/music under voice
Face-forward photos tied to your legal name	A likeness and an identity link	An illustrated avatar for the named persona; keep any real face off the legal name
Voiceprint as a bank/login factor	A clone becomes a working credential	Disable voice authentication; use a non-biometric second factor

None of this is a cure, and saying otherwise would be dishonest. Samples already public stay public, and a determined adversary can work with poor material. Minimisation lowers the probability and the fidelity of a successful clone; it does not zero them. That is exactly why it is paired with the second lever, which assumes a clone will eventually exist.

The Verification Protocol, In Full
#

The second lever is pre-registered trust: agree, in advance and out of band, on a verification step with the people who could be targeted through you — so a cloned voice cannot manufacture urgency. Most advice stops at “pick a family safe word.” That is the right instinct and an incomplete protocol. A safe word works not because it is secret but because it forces a second, attacker-controlled-channel-independent check at the moment urgency is weaponised. Build the whole mechanism around that principle, not around a single shared phrase.

The design rule is simple: the verification must never travel on the same channel as the request. A cloned voice controls the inbound call; it does not control a callback to a number you already hold, or a private memory it was never trained on. Episodic memory — a specific shared moment, not a fact that could be posted anywhere — is the part of you a model cannot synthesise.

Protocol element	How to set it up	Why a clone can’t beat it
Out-of-band rule	Verify on a different channel than the request arrived on (a call → a text to a known number)	The clone controls one channel, not a second independent one
Lived-memory challenge	A question answered only from a shared experience, never posted; rotate it	Models synthesise voice, not private episodic memory
Callback discipline	Hang up; call back the number you already have stored	Defeats spoofed caller ID and time pressure
Duress signal	A pre-agreed word meaning “I am being coerced — comply and get help”	Covers the case where the person is real but compelled
Pseudonym extension	For pseudonymous contacts, pre-share a one-time token out of band, not tied to legal identity	Lets a pseudonym verify without de-pseudonymising

That last row is the piece written for people like me, and the one no family-safe-word guide covers. If your trusted contacts know you only as a pseudonym, you cannot fall back on shared family history without breaking the wall between persona and person. A one-time verification token — exchanged once over an encrypted channel, used to bootstrap a rotating challenge — lets a network of pseudonymous collaborators authenticate each other without anyone learning a legal name. The protocol scales from a two-person household to a distributed activist or creator network precisely because it never depends on a shared legal identity, only on a shared secret established out of band.

“Just Delete It” Doesn’t Work — Which Is Why Prevention Is the Whole Game
#

Prevention carries the weight here because deletion does not load-bear. Removing a voice or likeness from a trained model is, at production scale, still a research-stage capability — not a button you can press today — so the control that actually works is not releasing the sample. This is the same hand-off as the permanence of your published footprint: timing beats cleanup, because ingestion is continuous and removal is partial.

The research is honest about its own limits. MIT Technology Review reported in July 2025 that researchers can make a text-to-speech model “unlearn” a specific speaker, but the process takes days, slightly degrades the model’s permitted voices, and in the researchers’ own words “would need faster and more scalable solutions” for real use. So the accurate statement is not “deletion is impossible” — it is that machine unlearning is still a research-stage capability, not a button you can press today. Treat any “remove my voice” offering as partial and forward-looking, not as an undo.

Which reorders everything. If the sample, once public, is effectively permanent, then the only fully effective control sits before publication — and the second-best control is the verification protocol that assumes the clone exists. Detection tools and takedown services have their place, but they are the outer, weakest ring. The inner rings — minimise, and pre-register trust — are the ones you control completely.

Key Takeaways
#

Voice, face, and writing are now credentials and attack surfaces at once. Stop treating a recognised voice or face as self-authenticating proof.
The defense is preventive, not reactive. A ~3-second clip clones a voice; you cannot recall a sample, and unlearning is not yet production-ready.
The threat is gendered. Synthetic intimate imagery and impersonation fall overwhelmingly on women and public pseudonyms — this is bodily and reputational sovereignty, not mere data hygiene.
Minimise sample quality relative to reach. Co-hosted audio, avatars for the named persona, no voiceprint logins, stripped metadata.
Pre-register an out-of-band verification step. Callback discipline, a lived-memory challenge, a duress signal, and — for pseudonyms — a one-time token that verifies without de-pseudonymising.

Frequently Asked Questions
#

Can AI really clone my voice from a short clip?
#

Yes. A 2023 Microsoft research model demonstrated voice synthesis from a three-second sample, and commercial tools now offer similar short-sample cloning. In a 2025 UC Berkeley study (Barrington & Farid, Scientific Reports), listeners mistook such clones for real voices roughly 80% of the time. The practical takeaway is to treat any clean, public recording of your voice as a usable sample, and to reduce how many of them exist.

Do family “safe words” actually work?
#

They work when they force a check on a channel the attacker doesn’t control — which is why the stronger version is a callback to a known number plus a question answered only from private, shared memory, not a single static phrase. A password can be guessed, overheard, or socially engineered; a rotating lived-memory challenge plus a duress signal is far more resilient. The phrase is the seed of the protocol, not the whole of it.

Can I remove my voice or face from AI models that already trained on it?
#

Not reliably, at scale, today. Researchers can make a model “unlearn” a speaker, but the process is slow, imperfect, and not yet deployed in production systems (per MIT Technology Review, 2025). Opt-outs and “do not train” signals mostly affect future ingestion where platforms honour them. Treat removal as partial and forward-looking — which is exactly why minimising what you publish matters more than any takedown.

Why frame this as a women’s issue specifically?
#

Because the data is lopsided. Tracking studies put women at the overwhelming majority of deepfake-pornography targets, and an American Sunlight Project study found about one in six women in Congress depicted in non-consensual imagery — roughly 70 times the rate for men. A defense that ignores who is actually targeted will under-protect the people most at risk, so the protocol here is built for the harasser-and-impersonation threat model, not only the fraud one.

What is the single most effective step?
#

Stop letting your voice or face act as an authentication factor — disable voiceprint banking and biometric “something you are” logins where a non-biometric second factor exists. It is the one move that removes a working credential from the attacker’s reach immediately, while minimisation and the verification protocol do the slower structural work.

Home Router Security Audit: A 2026 OPSEC Guide

Fri, 28 Aug 2026 00:00:00 +0000

A note on funding: CypherpunkGuide carries no surveillance advertising — no ad networks, tracking pixels, or sponsored content. It is funded by transparent streams: reader donations now; subscription and editorially-aligned affiliate links later. This guide makes no vendor recommendation and contains no router or VPN affiliate link.

Your home internet can keep working while your router serves someone else. In March 2026, an FBI technical alert (FLASH) on AVrecon said the malware had been observed in devices in approximately 163 countries and that the SocksEscort service was believed to have compromised and sold access to about 369,000 devices since 2020. The agency said AVrecon targeted about 1,200 router and Internet of Things (IoT) device models, with the vast majority of observed infections affecting small-office/home-office (SOHO) routers. The point was not always to break the owner’s connection. It was to make attacker traffic appear to come from an ordinary residential IP address.

That makes the usual router advice — change the password, enable WPA3, buy a VPN — incomplete. Operational security (OPSEC) means protecting information and systems by examining what an adversary can observe and exploit. Those steps do not answer the hard questions: Is this exact model still supported? Is its management interface reachable from the internet? Did an unauthorized person change DNS, accounts, or port forwards? If something is wrong, should you tighten its settings, rebuild it from known settings, or replace it?

I reviewed the current FBI, U.S. Department of Justice (DOJ), Federal Trade Commission (FTC), and National Institute of Standards and Technology (NIST) router guidance, then converted it into an 18-row Home Router Evidence Audit. I also put the same audit question to four current AI systems. All four produced a familiar checklist; several blurred power cycling, factory reset, and malware removal. This guide keeps those actions separate and leaves unknown evidence marked unknown.

Download the Home Router Evidence Audit before you begin. It is a worksheet, not a scanner: it never needs your configuration file, public IP address, Wi-Fi password, or router serial number.

What Home-Router Compromise Means in 2026
#

A home-router compromise is unauthorized control of the device that moves traffic between your network and the internet. Attackers may change settings, relay traffic through your IP, attack local devices, or use the router in a wider campaign.

Compromise does not prove that an attacker can read every password or encrypted page. HTTPS, the encryption used by most modern websites, and a correctly configured client VPN can still encrypt content in transit. Nor does a slow connection prove compromise. The useful task is to verify that the router is supported, updated, and configured as intended, then leave missing evidence marked unknown.

Recent primary sources show several distinct routes:

Evidence set	Reported scale	Router role	What the evidence does not prove
FBI AVrecon FLASH, March 2026	SocksEscort was believed to have compromised and sold access to about 369,000 devices since 2020; AVrecon was observed in about 163 countries and targeted about 1,200 models	Residential proxy, remote command access, malware loader, and botnet node, meaning one device in an attacker-controlled network	That every listed model or every household unit was infected
DOJ IoT-botnet disruption, March 2026	Court documents alleged that the four botnets had hijacked more than 3 million devices worldwide	Wi-Fi routers were among the IoT devices used for distributed denial-of-service (DDoS) attacks that flood a target with traffic	That all three million devices were routers, that each device was a router, or that every alleged command succeeded
FBI end-of-life router alert, May 2025	No universal device count	Some end-of-life (EOL) routers with remote administration enabled were used as TheMoon proxies	That a particular old router is infected merely because it is old
DOJ GRU disruption, February 2024	A network of hundreds of SOHO routers	Criminal Moobot infections on default-password Ubiquiti EdgeOS routers were repurposed by Russia’s military intelligence service, the GRU	Direct Microsoft Office-token extraction by each router

The scale is not limited to one malware family. A March 2026 DOJ operation cited court documents alleging that four botnets had hijacked more than three million devices worldwide; Wi-Fi routers were one device class among cameras, recorders, and other equipment.

The Office-token limit corrects an important headline shortcut. The DOJ’s GRU disruption notice says the router network concealed and enabled targeted phishing and credential-harvesting campaigns designed to steal login information. It does not say that an unpatched household router directly harvested Office tokens. The router was infrastructure in a larger operation.

The difference between attack infrastructure and direct credential theft matters for defense. A router used as a quiet relay may show none of the obvious signs people expect from a “hack.” You need evidence that the device is supported and configured as intended, not a dramatic symptom.

Start With the Support Decision
#

Support status is the first gate because configuration cannot patch a product whose manufacturer or internet service provider (ISP) no longer supplies security fixes. Check the exact model and hardware revision; age alone is not the decision.

Do this from a trusted, updated device you control while connected to the router’s local network. Do not search from the router by copying its full configuration, serial number, public IP address, or credentials into a web form or chatbot.

Record who owns the router. If your ISP supplied it, ask whether the ISP controls firmware and remote management. Do not disable a required management channel or install retail firmware on ISP-managed equipment.
Record the exact identity. Use the label and status page to note manufacturer, model, hardware revision, and installed firmware. A similar model name is not close enough for a firmware decision.
Find the official lifecycle page. Search the manufacturer’s or ISP’s support site for that exact revision. Save the URL and the checked date.
Find the official firmware record. Compare the installed version and release date with the official current release. Confirm whether updates are automatic, manual, or ISP-managed.

The FBI’s 2025 alert says routers dated 2010 or earlier likely no longer receive updates. Treat that as a warning sign, not a universal expiration date. A newer product can also be unsupported; an older ISP-managed unit may still receive fixes. The exact lifecycle record controls the decision.

I found no primary source that replaces this model-specific check with a universal age cutoff.

Use these routes:

Finding	Route	Why
Exact model is EOL or no trusted update path exists	Replace	Known vulnerabilities can remain permanently unpatched
Support status cannot be established	Unknown / escalate	Guessing “still safe” silently converts missing evidence into a pass
Supported but behind on official firmware	Harden	Apply the vendor/ISP update process, then verify the installed version
Current, supported, and managed by the ISP	Continue audit	Support does not prove the configuration or device is uncompromised

Replacement does not mean “buy the most expensive gaming router.” It means choose a product whose support period, update mechanism, secure defaults, and recovery procedure you can establish before purchase. NIST IR 8425A is a manufacturer-oriented profile, not a consumer seal, but its outcomes form a useful purchase checklist: configuration access that requires authentication, verified updates, limited interfaces, secure reset, and security evidence such as login attempts and system status.

Run the 18-Check Evidence Audit
#

The audit records pass, fail, and unknown evidence across ownership, support, exposure, configuration, clients, and recovery. Its highest-severity finding controls the response; there is no invented 87/100 security score.

Before changing anything, open the downloaded CSV in a local spreadsheet or text editor and add your result in a new column. Keep secrets out of it. Record “remote management disabled,” not the admin password; record “expected resolver matched,” not a complete sensitive configuration export.

1. Verify firmware and administrator control
#

Confirm the installed firmware after the update, not merely that you clicked an update button. Review every administrator account. Replace a default or reused administrator password with a unique one your password manager can generate and store. Your router administrator password and Wi-Fi password are different controls; changing one does not change the other.

If you find an administrator account you did not create, stop treating the task as routine hardening. Photograph or locally capture the account name, timestamp, firmware version, and relevant log entry before deleting or resetting anything. An unknown account is an investigation trigger, not proof of a nation-state attack.

If you are reorganizing credentials, use the same narrow, verified approach as a password-manager migration: change high-impact secrets from a trusted, updated device, do not paste them into random diagnostic services, and preserve recovery access.

2. Close unnecessary management paths
#

Review settings named Remote Management, Remote Administration, Web Access from WAN (wide-area network, the internet-facing side), Cloud Management, Telnet, or SSH command-line access. NIST’s router profile recommends that remote WAN access be disabled by default and management be confined to the local-area network (LAN). Disable internet-facing administration unless you have a documented requirement and a method that restricts who can connect.

Also inspect:

WPS (Wi-Fi Protected Setup): disable it, as the FTC baseline recommends.
UPnP (Universal Plug and Play): disable it if nothing needs automatic port mappings. First record current mappings and expect some consoles, calling apps, or media devices to need adjustment.
DMZ host and port forwards: these settings expose a local device or service to incoming internet traffic. Every entry needs a current device owner and purpose. A stale forward to a local address that now belongs to another device is not harmless paperwork.
Dynamic DNS: this gives a changing public IP address a stable hostname. Verify the configured service and account.
VPN and other tunnel profiles: verify every configured service. An unknown profile is a reason to preserve evidence and escalate.

The FTC home Wi-Fi baseline recommends disabling remote management, WPS, and UPnP. That is a sound default for a household audit, but availability and business needs vary. Document the exception rather than pretending the feature is off.

3. Verify wireless encryption and segmentation
#

Use WPA3-Personal where all necessary devices support it, or WPA2-Personal with AES where WPA3 is unavailable. WEP, the original WPA, and an open primary network are replacement or reconfiguration signals, not acceptable “compatibility” modes.

List every SSID (network name), including guest, IoT, and hidden networks. Then test isolation instead of trusting the label. A guest network that can still reach your laptop, network storage, printer admin page, or router console is not meaningfully isolated.

Put less-trusted smart devices on an isolated segment where the router actually enforces separation. This does not make an obsolete camera safe; it reduces what that camera can reach. The principle matches a broader AI-age threat model: limit how many other devices an incident can reach when prevention fails.

4. Inventory clients and configuration state
#

Review the connected-client list, the Dynamic Host Configuration Protocol (DHCP) lease list of addresses the router assigned, and any reserved addresses. Classify each current device by owner and type. Do not assume every unfamiliar identifier is an intruder: modern phones may use a private or randomized Media Access Control (MAC) address, and a remembered device can appear under a vendor chip name.

Then compare these settings with what you intended:

WAN and LAN DNS resolvers;
firewall state for both IPv4 and IPv6;
port forwards, DMZ host, and exposed services;
administrator accounts and recent login attempts;
time zone and clock synchronization;
firmware version and update history;
remote-management and cloud-management state.

Unexpected DNS, an unknown admin account, or an unexplained port forward is more actionable than vague overheating. Preserve the exact evidence, then use a trusted, updated device and official vendor or ISP support to decide whether the change was legitimate.

5. Inspect the security evidence the product exposes
#

NIST’s profile says a router product should report security-relevant activity and status, including login attempts, administrative events, system status, firewall status, component status, and time synchronization. Many consumer interfaces expose only part of that set.

If a log is unavailable, write unknown. Do not write pass. If logs exist, look for administration from unexpected sources, configuration changes you did not make, repeated update failures, unexplained restarts, or a clock so wrong that the timestamps are unusable. Do not upload logs to a public paste site; they can reveal internal addresses, hostnames, domains, and account names.

I designed the worksheet around observable evidence for exactly this reason. It does not claim to detect malware. It shows which support and configuration claims have evidence and which remain unknown.

Choose: Observe, Harden, Reinitialize, or Replace
#

Choose the route from the most serious finding, not the number of green rows. One unsupported firmware path outweighs ten tidy Wi-Fi settings. One unauthorized administrator account outweighs a strong passphrase.

In this guide, reinitialize means preserving evidence, following the model-specific official reset or recovery path, and rebuilding from settings you have verified. It does not mean pressing the Reset button as a reflex.

Route	Trigger examples	Next action
Observe	Supported, current, no unexplained exposure or state change, recovery path known	Save the checked date; review after security notices and on a regular cadence
Harden	Supported but behind on firmware; defaults remain; WPS/unused UPnP or WAN management enabled	Record the before-state, apply official changes one at a time, verify connectivity and the after-state
Reinitialize	Credible compromise notice; validated unauthorized admin, DNS, tunnel, or port-forward change; settings reappear; updates repeatedly fail	Preserve evidence first, contact ISP/vendor, then follow the exact official reset/reflash procedure and rebuild from known settings
Replace	EOL/unsupported; no trustworthy firmware path; required secure encryption unavailable; trusted state cannot be restored	Retire the device, set up a supported replacement with new admin credentials, and do not import an untrusted full configuration backup

“Observe” is not a certificate of cleanliness. Consumer logs cannot prove that no hidden implant exists. It means this audit found no known failure and the router remains supportable.

“Reinitialize” is deliberately conditional. If a router is evidence in stalking, targeted intrusion, financial loss, or a workplace investigation, a reset destroys configuration and logs that may matter. Disconnect or isolate only as safety requires, photograph the state, and seek qualified incident-response or law-enforcement guidance before wiping. For lower-consequence household anomalies, vendor or ISP support can provide the model-specific recovery sequence.

Power Cycle, Factory Reset, Reflash, and Replacement Are Not Synonyms
#

No button universally restores router trust. A power cycle restarts it; a factory reset restores documented settings; a firmware reinstall replaces software through an official path; replacement starts with a new device and support lifecycle.

Action	What it can do	What it cannot establish
Power cycle	Restart the router; complete a reboot that official update or recovery instructions require	That vulnerabilities are patched, unauthorized settings are gone, or malware cannot return
Factory reset	Return settings and stored customer data to the product’s documented defaults; remove many unauthorized configuration changes	That firmware or lower-level components are authentic; that default credentials are safe; that EOL vulnerabilities are fixed
Official firmware reinstall/recovery	Replace firmware through a vendor-supported verified path on some models	A universal cure for startup code (the bootloader), hardware, supply-chain, or unsupported-device compromise
Replacement	Remove the old device and establish a new support and update lifecycle	That imported settings, reused secrets, exposed services, or compromised local devices are now safe

The FBI’s 2025 EOL-router alert recommends a sequence: replace EOL equipment if possible, apply patches, disable remote administration, use a unique password, and reboot after those changes. Quoting only “reboot the router” removes the controls that prevent the same exposure from remaining.

If you reinitialize a supported router, use the exact vendor or ISP instructions. Obtain the official firmware and recovery documentation before starting. Record required ISP connection settings without copying secrets into the public worksheet. After reset or reflash, configure new admin credentials and safe management settings before reconnecting unnecessary local devices. Verify the installed firmware afterward.

Do not restore a full backup made after suspicious changes unless the vendor or an incident responder has established that it is safe. A backup can faithfully restore the problem you meant to remove.

What a VPN Can and Cannot Fix
#

A VPN is an encrypted tunnel between a VPN client and a VPN server. It can reduce what a router or ISP can read about traffic inside that tunnel, but it does not repair the router carrying it.

NIST SP 800-77 Rev. 1 makes the boundary explicit: a VPN protects traffic between its tunnel endpoints. It does not update the forwarding router’s firmware or authenticate that router’s configuration.

Question	Client VPN on a laptop or phone	VPN running on the router
Can it patch router firmware?	No	No
Can it close exposed remote administration?	No	No
Can it remove router malware or unknown accounts?	No	No
Can it encrypt supported client traffic to the VPN server?	Yes, when correctly configured	Yes, but the router itself is the tunnel endpoint
Can it stop a compromised router from acting as a proxy or attacking the LAN?	No	No
Does it hide all metadata?	No; the router still sees the VPN endpoint, timing, and volume	No; the compromised endpoint handles the traffic before or after tunneling

HTTPS already encrypts much web content between the browser and website. A client VPN adds a different tunnel and can be valuable for privacy, but neither encryption layer changes the router’s support status. If the router itself hosts the VPN client, compromising that router compromises the device that creates and routes the tunnel.

This is why the guide does not rank VPN providers or recommend “always on” as its router defense. Choose network privacy tools as part of a broader privacy stack only after you can verify the router’s updates and management settings.

If You Find an Unauthorized Change
#

Preserve enough evidence to explain what changed, then restore trust from a trusted, updated device and an official recovery path. Do not rotate every account from a device you suspect is compromised.

Record the router model, hardware revision, firmware, current time, and who owns/manages it.
Capture the specific unauthorized account, DNS entry, forward, tunnel, log event, or notice. Keep it local and redact secrets before sharing with legitimate support.
If the router is ISP-managed, contact the ISP’s security/support channel. If retail, use the manufacturer’s official support route.
For an EOL device, replace it. Do not spend hours perfecting settings that cannot receive a patch.
For a supported device, follow the official reset/recovery/reflash sequence. Rebuild settings rather than automatically importing an untrusted backup.
From a trusted, updated device, change the router administrator password and any credential that evidence shows may have been exposed. Enable multi-factor authentication on sensitive accounts where available.
Recheck firmware, WAN administration, accounts, DNS, forwards, firewall, clients, and logs after recovery.

If evidence points to account exposure outside the router, use a focused post-breach defense plan for credentials and identity records. Do not infer that every account is compromised simply because one router setting was wrong.

Bottom Line: Restore Verifiable Trust
#

A useful router audit produces a support record, a configuration record, and a justified action. It does not produce a magic score or claim to rule out sophisticated compromise.

Start with the exact model and support lifecycle. Then verify firmware, administrator control, WAN management, wireless encryption, port exposure, DNS, clients, segmentation, and available logs. Mark missing evidence unknown. Replace unsupported hardware; preserve unauthorized changes before erasing them; and follow official, model-specific recovery instructions.

The quiet risk in 2026 is not only that someone reads traffic. It is that a household device becomes someone else’s infrastructure while looking normal to its owner. The defense is equally quiet: fewer exposed interfaces, current verified software, known configuration, evidence you can inspect, and a recovery path you can trust.

Frequently Asked Questions
#

These answers separate routine hardening from incident response, keep unknown evidence visible, and avoid promises that consumer devices cannot support. They do not promise malware detection.

How often should I audit my home router?
#

Check support status and the full configuration now, after any model-specific security notice, after an unexplained settings change, and on a regular cadence you can sustain. Monthly firmware/version confirmation is reasonable for manually updated devices; ISP-managed or automatic-update devices still need periodic verification that updates actually arrive. The exact interval is less important than recording the checked version and date.

Does restarting a router remove malware?
#

A restart changes running state, but the cited government sources do not establish that it removes AVrecon, TheMoon, Moobot, or any other router malware. It does not patch a vulnerability, establish firmware authenticity, remove every persistent change, or prevent reinfection. Treat it as one operational step when official update or recovery instructions require it, not proof that the router is clean.

Is a factory reset enough after router compromise?
#

Not universally. A factory reset can restore documented default settings and remove many configuration changes. It can also restore default credentials and erase useful evidence. It does not guarantee removal of modified firmware or lower-level persistence. Follow the exact vendor/ISP recovery procedure, apply current official firmware, rebuild safely, and replace unsupported hardware.

Should I disable UPnP and WPS?
#

The FTC recommends disabling both. Disable WPS. UPnP can be needed by some games, calling apps, or media devices, so first record its mappings and test the affected applications after disabling it. If you retain a UPnP exception, document which device and application owns it rather than leaving automatic exposure unexplained.

Can I check whether my model was in the AVrecon botnet?
#

The FBI FLASH lists observed manufacturers and models and says about 1,200 models were targeted, but a model match is not proof that your unit was infected. Use the model to check official firmware, lifecycle, applicable vulnerability notices, and the FBI indicators. A mismatch also does not certify safety. Contact the vendor or ISP when the exact model or indicator is unclear.

References
#

The live sources below are primary government and standards materials. Each archive link is an exact replay that returned a successful web response (HTTP 200) during independent source verification on August 28, 2026.

#	Source	Live URL	Archive
1	FBI FLASH 20260312-001 - AVrecon Malware-Infected Routers Exploited as Residential Proxies by SocksEscort	https://www.fbi.gov/file-repository/cyber-alerts/avrecon-malware-infected-routers-exploited-as-residential-proxies-by-socksescort.pdf	https://web.archive.org/web/20260402044918/https://www.fbi.gov/file-repository/cyber-alerts/avrecon-malware-infected-routers-exploited-as-residential-proxies-by-socksescort.pdf
2	FBI - Evading Residential Proxy Networks: Protecting Your Devices from Becoming a Tool for Criminals	https://www.fbi.gov/investigate/cyber/alerts/2026/evading-residential-proxy-networks-protecting-your-devices-from-becoming-a-tool-for-criminals	https://web.archive.org/web/20260808054457/https://www.fbi.gov/investigate/cyber/alerts/2026/evading-residential-proxy-networks-protecting-your-devices-from-becoming-a-tool-for-criminals
3	FBI - Cybercriminal Proxy Services Exploiting End-of-Life Routers	https://www.fbi.gov/investigate/cyber/alerts/2025/cybercriminal-proxy-services-exploiting-end-of-life-routers	https://web.archive.org/web/20260822065226/https://www.fbi.gov/investigate/cyber/alerts/2025/cybercriminal-proxy-services-exploiting-end-of-life-routers
4	DOJ - Authorities Disrupt IoT DDoS Botnets Responsible for Record-Breaking Attacks	https://www.justice.gov/usao-ak/pr/authorities-disrupt-worlds-largest-iot-ddos-botnets-responsible-record-breaking-attacks	https://web.archive.org/web/20260825205257/https://www.justice.gov/usao-ak/pr/authorities-disrupt-worlds-largest-iot-ddos-botnets-responsible-record-breaking-attacks
5	DOJ - Court-Authorized Disruption of Botnet Controlled by Russia’s GRU	https://www.justice.gov/archives/opa/pr/justice-department-conducts-court-authorized-disruption-botnet-controlled-russian	https://web.archive.org/web/20260808070920/https://www.justice.gov/archives/opa/pr/justice-department-conducts-court-authorized-disruption-botnet-controlled-russian
6	NIST IR 8425A - Recommended Cybersecurity Requirements for Consumer-Grade Router Products	https://doi.org/10.6028/NIST.IR.8425A	https://web.archive.org/web/20260506061206/https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8425A.pdf
7	FTC - How To Secure Your Home Wi-Fi Network	https://consumer.ftc.gov/articles/how-secure-your-home-wi-fi-network	https://web.archive.org/web/20260821194423/https://consumer.ftc.gov/articles/how-secure-your-home-wi-fi-network
8	NIST - 7 Tips to Keep Your Smart Home Safer and More Private	https://www.nist.gov/blogs/taking-measure/7-tips-keep-your-smart-home-safer-and-more-private-nist-cybersecurity	https://web.archive.org/web/20260816082442/https://www.nist.gov/blogs/taking-measure/7-tips-keep-your-smart-home-safer-and-more-private-nist-cybersecurity
9	NIST SP 800-77 Rev. 1 - Guide to IPsec VPNs	https://doi.org/10.6028/NIST.SP.800-77r1	https://web.archive.org/web/20260816065058/https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-77r1.pdf

Cora Aegis

Cora Aegis writes privacy-first OPSEC guidance at CypherpunkGuide. For this article, she reconciled four current U.S. government router cases with NIST's consumer-router profile, tested the query across Google AI Mode and four additional AI systems, and translated the resulting evidence boundaries into an 18-check audit without scanning or changing a reader's network.

More about Cora Aegis ->

Encrypted Backups: Can You Restore Your Files? (2026)

Thu, 03 Sep 2026 00:00:00 +0000

A note on funding: CypherpunkGuide carries no surveillance advertising — no ad networks, tracking pixels, or sponsored content. Funding comes from transparent streams: reader donations now; subscriptions and editorially aligned affiliate links later. This article contains no affiliate links and does not recommend a storage vendor.

Photos, correspondence, and records can outlive the computer that created them. Encrypting a backup helps keep those files private. Recovering them later also depends on access to the backup, a working unlock method, the right saved version, and software that can read the result.

I designed a restoration experiment around 12 artificial files and six test cases, using restic, an open-source encrypted backup program. In one case, the repository check, full data check, and restore command all reported success while only 11 of the 12 intended files came back. In another, all 12 files returned and passed their format checks, but one contained an older revision.

The useful question is therefore specific: can you recover the records you intended to keep, in the version you need, and use them? This guide connects a personal backup plan to a reproducible lab and a safe restore drill. The lab uses generated test files, not anyone’s personal archive. It does not measure drive lifespan, off-site resilience, or recovery of an entire computer.

Separate Sync, Backup, and Long-Term Preservation
#

Sync keeps working copies aligned; backup retains copies you can recover; long-term preservation also maintains their meaning and readability as devices and software change. One service may provide several of these functions, but each needs its own check.

A synchronized deletion can be the correct behavior of a sync service. Recoverability depends on its retained versions, deletion rules, and account access. Conversely, a disconnected disk can hold a valuable copy while lacking anything written since it was disconnected. Name the function you need before choosing the storage.

Function	What it is for	What you still need to establish
Sync	Keep active files available across devices	Whether deleted or overwritten versions remain recoverable, and for how long
Backup	Recover from loss or unwanted changes	Which files and versions are included, whether the copy survives the likely failure, and whether restoration works
Long-term preservation	Keep selected records usable over years	Descriptions, formats, readers, media renewal, and a continuing recovery path

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) describes the 3-2-1 approach as three copies in total, on two different media types, with one off site. Its ransomware guidance also recommends offline, encrypted backups and regular integrity and restoration testing. Off site describes location; offline describes connectivity. A remotely stored copy that the same compromised account can erase does not become independent merely because it is in another building. See the CISA backup guidance and ransomware guide.

For a personal archive, list concrete failures: a stolen laptop, a mistaken deletion, a home fire, an account lockout, or loss of an unlock method. Ask which copy remains usable after each one. This extends the same question used in a personal privacy stack: which failure is each control intended to address?

Keep a Recovery Route Outside the Failed System
#

Encryption protects backup contents from someone who lacks a valid unlock method. It does not preserve that method, keep an account accessible, or ensure that all copies remain available. A recovery plan must address these dependencies separately.

Write down the backup location, the program and format used, the account-recovery route if relevant, and how an authorized person obtains the required unlock information. Keep credentials protected. Do not publish them in a worksheet or send them to a chatbot. A note that says “recovery instructions are in the sealed packet” serves a different purpose from exposing the secret itself.

With restic, repository data is encrypted and access is mediated by password-protected keys. A repository can have multiple such keys. Losing one password does not imply permanent loss if another valid key and password remain available. Losing every usable unlock route is a different situation. The official repository-creation documentation explains this model.

Watch for a circular dependency: the only copy of your backup password is inside the backup, or your password manager’s recovery materials exist only on the laptop you are trying to replace. Our guides to passkey recovery and password-manager migration approach the same access problem from the account side.

Self-hosting changes who operates the system; it also leaves you responsible for its recovery. A self-hosted service on the same machine as its only backup still has one machine to lose.

Understand What Each Check Establishes
#

A backup check answers the question it was designed to answer. Repository consistency, reading stored data, recovering expected files, matching their bytes, and opening their formats are separate tests. Passing one does not silently pass the others.

As checked on September 3, 2026, the restic documentation distinguishes ordinary check from check --read-data. Ordinary checking examines repository structure and consistency; it does not read and verify all stored pack contents. A pack is a file containing backup data. Adding --read-data reads every pack, which can take substantial time and network traffic. See Working with repositories.

Check	Useful evidence	What a successful result does not establish
Ordinary repository check	The repository structures examined are consistent	Every stored data byte was read and verified
Full stored-data check	Stored packs passed that tool’s data checks	You included every intended file or chose the right version
Expected-file comparison	Restored paths match a separately prepared list	The bytes match or the application can use them
Hash comparison	Restored bytes match the chosen reference values	The reference was correct, current, or readable
Format/application check	The tested reader can interpret the tested content	Every feature works, every other file works, or future software will support it

A manifest is a list of expected files, optionally with sizes and hashes. A cryptographic hash, such as SHA-256, is a value calculated from a file’s bytes to help detect change. Keep a protected reference made from the files you actually intend to preserve. A list generated only from the backup cannot reveal a file that never entered that backup. File names can themselves be sensitive, so the manifest belongs within your privacy plan too.

The Library of Congress distinguishes bit-level preservation from preserving future access in its digital-collections glossary. I used the September 2025 archived edition because the live page blocked retrieval during this review. That distinction shaped the experiment below: byte equality is valuable evidence, but an already malformed file can be copied perfectly.

Six Restore Cases, Tested With Artificial Files
#

The lab separates command success from the reader’s desired outcome. Under restic 0.19.1 on Windows, checking the repository, reading all its data, and restoring it all succeeded despite a missing intended file or an old revision. Comparison with an independent reference exposed those differences.

I built the corpus before applying any exclusion. It contains 12 files in seven format groups: UTF-8 text, JSON, CSV, XML, ZIP, WAV, and TOML. These are artificial notes, structured records, an archive, and a generated tone. Python’s standard-library readers test their format-level readability; no photo viewer, office suite, or audio-player interface was tested.

Each case uses a selected snapshot ID — the identifier of a saved backup version — and a new, empty restore destination. The run records ordinary checking, full data checking, restoration, expected paths, hashes, and parsing separately. A command exit code of 0 means command success; a nonzero value means an error for that command. Neither is a personal-archive quality score.

Results
#

Case	Ordinary check / full data check / restore	Intended paths restored	Hashes matching the case’s expected version	Format checks passed / files tested
S1: unchanged, valid files	0 / 0 / 0	12/12	12/12	12/12
S2: wrong public test password	12 / 12 / 12	0/12	0/12	Not run; no files restored
S3: one byte altered in a disposable repository’s data payload	0 / 1 / 1	11/12	11/12	11/11
S4: one intended file excluded from backup	0 / 0 / 0	11/12	11/12	11/11
S5: older snapshot selected	0 / 0 / 0	12/12	11/12	12/12
S6: malformed JSON present before backup	0 / 0 / 0	12/12	12/12	11/12

Path and hash counts use the 12 intended files as their denominator. Format checks use only the restored files actually tested: a missing file has no restored bytes to parse. Hashes in S5 are compared with the independently recorded required current revision, not with a list taken from the old snapshot. In S6, the reference records the already malformed input so that preserving bytes and reading the format remain separate questions.

What the failures mean
#

S2 tests access with one incorrect password. It demonstrates rejection of that test password, not the impossibility of recovery through another valid key. The published password is an obvious synthetic fixture and must never be used for a real backup.

S3 changes actual stored data while retaining the surrounding repository structure. Ordinary checking succeeded; the full data read and restoration detected trouble. That observation is specific to the injected corruption. It does not claim that ordinary checks miss every kind of corruption, or that a damaged real repository always loses exactly one file. I retained the separate command results because collapsing them into a single “backup failed” label would hide the useful difference.

S4 is an inclusion error. The backup program successfully saved the selected files. Our intended inventory also contained documents/contacts.csv, which the experiment deliberately excluded. A program cannot infer that a valid exclusion contradicts your wishes. Review selection and exclusion rules as part of the backup, using the restic backup documentation.

S5 is a version error. The older documents/status.json remained valid JSON and restored correctly. Its hash differed from the required current revision. Neither file counts nor successful parsing establishes freshness. An older snapshot can be exactly what you want after an accidental deletion; it is a problem only when it is the wrong version for your recovery goal.

S6 preserves malformed input faithfully. The experiment deliberately creates invalid documents/records.json before backup. All three restic operations succeed, and all 12 restored hashes match their source references. Yet the JSON reader rejects that file both before and after backup. This is a source-quality problem, not corruption introduced by restoration. The other 11 files pass their format checks.

Reproduce the bounded experiment
#

The downloadable experiment script accepts only the pinned official restic 0.19.1 Windows amd64 release ZIP. It checks the archive and executable hashes, creates its own synthetic files and disposable repositories, and refuses existing source or restoration locations. It intentionally damages a copy created inside that experiment. It does not accept your real backup repository.

Inspect the method and limitations, results table, detailed results, synthetic file manifests, and sanitized command log. These assets document generated files only. The command log replaces host-specific identifiers and locations; it is not an untouched terminal transcript.

Run it with Python 3.11 or later in an empty disposable working folder, after reading the script. Download the matching ZIP from the official restic 0.19.1 release and compare it with the release checksums. Then run:

python restore-lab.py --restic-zip restic_0.19.1_windows_amd64.zip

The run leaves its test directory in place for inspection. This experiment was executed with Python 3.12.10. It is a mechanism demonstration with one small corpus and defined faults, not a failure-rate estimate or a comparison of backup products. File permissions, entire operating systems, network outages, independent locations, hardware aging, and full application behavior are outside its scope.

Run a Safe Restore Drill on Your Own Backup
#

Restore into a new, empty folder and check it before changing any originals. Select the version for the recovery task, compare independently expected files and contents, and open representative files in their intended applications. A small sample provides limited evidence, not a pass for the entire archive.

Restic’s restore documentation warns that restoration overwrites existing files by default. Other programs have their own rules. Read the instructions for your installed version and confirm the destination before starting. Do not point a trial restore at your working documents folder.

Define the recovery goal. For example: “recover the correspondence and photos up to the last completed backup,” or “recover the version before yesterday’s deletion.” Record which folders and dates should be included. If the source still exists, prepare the expected inventory independently of the backup selection and associate it with the intended version. A working file changed after backup will differ from that snapshot; the difference alone is not restoration damage.
Confirm access and capacity. Locate the backup and its valid unlock route. Choose a trusted computer and a separate, empty destination with sufficient free space. Restored files may be readable plaintext; protect that destination and keep it out of unintended sync or sharing.
Select a specific saved version. Record its identifier and relevant date. “Latest” describes an ordering rule; it does not establish that the snapshot contains the changes you expect.
Run the documented checks and restoration. Distinguish a quick structural check from a complete data read. Review warnings and errors, including those from the original backup job. Do not interpret the existence of a snapshot as proof that every source file was read.
Compare the result with your goal. Check expected paths, representative contents and versions, and trusted hashes where available. Open documents, inspect photos, play recordings, and try the application features that make those records useful. Record what you tested and what remains untested.
Keep the working copies until the result is verified. A successful trial does not justify deleting the only other usable copy. Protect or remove the trial files under your own retention policy after verification; avoid destructive cleanup while investigating a mismatch.

Start with a limited selection if time or space prevents a full restore, and record that limit. Expand coverage over time. If the source has already disappeared and no independent inventory exists, say that completeness is unknown; a count from the surviving backup cannot settle it.

Preserve Readability as Well as Storage
#

Long-term preservation requires periodic checks of media, connections, readers, formats, and recovery access. A lifespan claim for one storage material does not guarantee that a whole archive will remain recoverable for that period.

The Library of Congress’s personal-records guidance recommends checking saved files at least annually and making new media copies every five years or when needed. Its media-durability note explains why lifetime estimates are uncertain. Treat the schedule as maintenance guidance, not as a promise that a drive will survive until the next date. Recheck after a migration, an unlock-method change, or a suspected failure too.

Dependency	What to retain or review	Evidence to record
Storage and connection	Usable media plus access to compatible drives, cables, and interfaces	Date a copy was fully read; detected errors; migration result
File meaning and format	Originals, descriptions, and usable export or access copies where appropriate	Which reader opened which files; features lost in conversion
Unlock and account access	Protected recovery information and an authorized way to obtain it	A successful recovery exercise without writing secrets into the log
Selection and versions	Intended inventory and a retention policy suited to the records	Missing paths, required revisions, and latest verified coverage

Do not choose a disk by a universal “HDD lasts X years” or “SSD lasts Y years” rule. Likewise, Verbatim’s M-DISC longevity claim concerns an optical-storage product; it does not guarantee future access to a compatible reader, intact unlock information, or readable file formats. The U.S. National Archives describes uncertain lifespans and storage conditions of video media, including optical discs. These limitations do not establish that every optical disc will fail.

Where formats or applications are becoming difficult to use, make a documented access copy while retaining the original. Converting a complex document can lose layout or features; a new hash will also differ because conversion changes bytes. Verify the conversion against what matters in the record, label it, and establish a new reference for the converted copy. Do not overwrite the original to make a folder look tidy.

I compared the cases by recording the intended inventory, required version, and reader checks beside each command result. Use those separate records to decide what to fix. A missing file needs an inclusion review; an old revision needs a version decision; unreadable source material needs preservation work. Buying another disk does not, by itself, answer those questions.

FAQ
#

Is cloud sync a backup?
#

It can provide some recovery functions if it retains versions and deletions for a suitable period. Check those rules and account-recovery requirements. Synchronization alone does not establish that an unwanted change, deletion, or account loss is recoverable.

Does a successful restic check mean every file is safe?
#

No. Ordinary checking does not read every stored pack’s contents. Full data checking still does not establish that your intended files were included, that you chose the required version, or that applications can read the restored files.

Can I recover an encrypted backup if I forget its password?
#

It depends on the tool and your remaining unlock routes. Restic can have multiple password-protected keys. Another valid key and password may still work. Do not assume the storage provider can decrypt the backup, or that one failed password proves every recovery route is lost.

How often should I test a personal archive?
#

The Library of Congress advises checking saved files at least annually. Use a schedule that reflects how often your important records change, and test after significant storage, software, or recovery-access changes. Record whether you checked a sample or the whole set; neither a calendar date nor a small sample guarantees continued recovery.

Which storage medium will preserve files for decades?
#

No medium removes the need for independent copies, inspections, and migration. Consider storage conditions and access to compatible readers as well as the medium. Long-term availability also depends on formats, software, and unlock information. Keep verified originals when creating newer access copies.

Sources and Reproduction Record
#

Primary sources were checked on September 3, 2026. The experiment’s results apply to the stated runtime and artificial inputs. Archived editions preserve source history and may predate the live version used for a claim.

#	Primary source	Original	Archived edition
1	CISA — Data Backup Options	PDF	2026-08-05
2	CISA — StopRansomware Guide	Guide	2026-08-30
3	restic — Preparing a New Repository	Documentation	2026-08-19
4	restic — Working With Repositories	Documentation	2026-08-22
5	restic — Restoring From Backup	Documentation	2026-08-22
6	Library of Congress — Digital Collections Management Glossary	Glossary; retrieval blocked	2025-09-16
7	Library of Congress — Personal Digital Records	Guide	2026-08-28
8	Library of Congress — How Long Will Digital Storage Media Last?	PDF	2025-11-07
9	Verbatim — M-DISC Optical Media	Manufacturer statement	2026-05-02
10	U.S. National Archives — Video Condition Assessment	Preservation guidance	2026-05-15
11	restic — Backing Up	Documentation	2026-08-22
12	restic 0.19.1 — Release	Official release	2026-08-18; release notes, not a binary mirror

Cora Aegis

Cora Aegis writes about privacy and digital autonomy at CypherpunkGuide. For this guide, she designed and reviewed a synthetic encrypted-backup restoration experiment and compared its results with official restic and preservation guidance. The experiment used no personal backup data.

More about Cora Aegis ->

Self-Hosting Sovereignty in 2026: A Five-Layer Audit

Wed, 01 Jul 2026 00:00:00 +0000

Somewhere in the last few years, “self-host it” became the reflexive answer to every privacy problem. Run your own cloud instead of renting Google’s. Run your own Bitcoin node instead of trusting a company’s. Run your own mail server, your own VPN, your own everything — and, the pitch goes, owe nothing to Big Tech. The word attached to this is sovereignty, and it is a beautiful word. It is also, most of the time, doing more work than the setup underneath it can support.

The uncomfortable part is not that self-hosting is useless. It is that self-hosting solves one or two layers of a five-layer problem and then quietly borrows the reassurance of having solved all five. A rented server whose host — the hypervisor, the software layer that runs many virtual machines on one physical box — can read its memory is not compute you control. A home service still hands your connection metadata to your ISP, which can retain it for months, and, if it is a mail server, to every recipient’s provider on earth. And a stack that is flawless from key to packet collapses the instant you registered its domain under your real name or paid for it with a card that resolves to you.

Reviewing node-operator guidance, VPS provider documentation, and published mail-server runbooks, we graded three canonical setups — a home Bitcoin node, Nextcloud on a rented VPS, and a self-hosted mail server — against a five-layer sovereignty model, and in every one the weakest layer was not the layer the setup was built to solve. That is the pattern this piece is about. Sovereignty is not a badge you earn by moving a workload off someone else’s platform; it is a property you can only claim at the layer where you are actually still exposed. This is an audit, not a sales page — a way to grade your own setup honestly and find the layer that is quietly undoing the rest.

What Digital Sovereignty Actually Requires
#

Digital sovereignty is exclusive, un-compellable control over every layer a service depends on — the keys, the data, the hardware, the network, and the identity behind it — and self-hosting, by itself, delivers at most a couple of those. The common mistake is treating sovereignty as a binary you flip by moving a workload in-house. It is not binary and it is not a single thing. It is a stack, and the stack is only as sovereign as its weakest layer.

That last sentence is the load-bearing one, so it is worth stating plainly: sovereignty is the minimum across your layers, not the sum. A setup that scores nine out of ten on custody and two out of ten on identity is a two-out-of-ten setup, because an adversary attacks the weak layer, not the strong one. This is the same logic that governs a chain, a threat model, or a security boundary — the defender has to be right everywhere, the attacker only has to be right once. Averaging the layers to feel better about the total is precisely the self-deception this framework exists to interrupt.

There is a second, subtler trap: self-hosting relocates dependency far more often than it removes it. Move off a cloud provider and onto a home server, and you have not escaped dependency — you have traded a dependency on Amazon for dependencies on your electric utility, your internet provider, the semiconductor supply chain that made your hardware, the Tier-1 networks your packets cross, and the certificate authorities that make your TLS trusted. Those dependencies are quieter and easier to forget, which is exactly why they read as sovereignty. The feeling of independence is real; the independence often is not. Naming which dependencies you actually shed, and which you merely moved somewhere less visible, is the whole discipline.

The Five-Layer Sovereignty Audit
#

A useful sovereignty audit grades five independent layers — custody, data, compute, network, and identity — because a setup can be strong at one and naked at another, and only the layer-by-layer view shows you which. Below is the model we grade against. Read the rightmost column first: it is the list of things that keep leaking after you have “self-hosted,” and it is where most of the honest work lives.

Layer	What sovereignty means here	How self-hosting typically scores	What still leaks
1. Custody	You alone hold the keys and root secrets	✅ Often the one layer done well	Hot keys on a reachable server; backup custody
2. Data	No third party can read or be compelled for your data	◐ Mixed	Encryption at rest ≠ in use; who can be subpoenaed
3. Compute	You control the hardware executing the code	✗ Fails on any rented server	The host can read guest RAM; runtime plaintext
4. Network	Reachability and metadata don’t depend on one watcher	✗ Usually leaks more, not less	ISP sees destinations/timing; mail metadata to every hop
5. Identity	Pseudonymity and jurisdictional separation hold	✗ The silent killer	Real-name domain, KYC-linked payment, one card that resolves to you

The reason to separate these is that the layers fail independently and for different reasons. Custody is a possession problem — do you hold the secret. Compute is a hardware-trust problem — whose silicon runs your plaintext. Network is a metadata problem — who watches the envelope, regardless of the letter inside. Identity is a correlation problem — whether any single real-world fact ties the whole thing back to you. Solving one does nothing for the others, and the strong layers can lull you into ignoring the weak ones. The audit’s only rule is the one from the previous section: your score is the lowest row, not the average. The next three sections take the three rows self-hosters most reliably get wrong.

Compute and Network: The Layers Self-Hosting Quietly Leaks
#

The two layers self-hosting is worst at are the two it feels best at: a rented server is not compute you control, and a home server usually leaks more network metadata than a cloud account, not less. These are the layers where the reassurance is strongest and the reality is thinnest, so they deserve the most precise language.

Start with compute on a rented VPS. When you rent a virtual server, a hypervisor you do not control runs your virtual machine, and by design that hypervisor can read your VM’s memory — it manages the very page tables (the CPU’s map of where your data sits in RAM) that address it. Disk encryption does not save you here: encryption at rest protects the disk when the machine is off, but a running server holds its keys and plaintext in RAM, and the host can read that RAM. This is not an accusation that your provider does snoop; it is the observation that they can, and nothing in your setup can stop them, which means compute sits outside your trust boundary no matter how reputable the company is. The one real fix — confidential computing, where the CPU encrypts guest memory against the host (AMD SEV-SNP, Intel TDX) — exists, and the major clouds (Azure, Google Cloud) now offer it as a premium option, but it is still absent from the commodity VPS plans most self-hosters actually use in 2026. Owning bare-metal hardware moves the problem, but reintroduces physical exposure, including cold-boot attacks, which recover encryption keys from RAM in the seconds after power is cut.

Compute model	Who can read your data while it runs	Residual exposure	Sovereign compute?
Rented VPS (standard)	The host — the hypervisor can read guest RAM	Provider’s datacenter and staff	No — outside your trust boundary
Rented VPS + confidential computing	The CPU encrypts RAM against the host	Rare in 2026; firmware/attestation trust	Partial, where actually available
Bare-metal you own	Only someone with physical access	Cold-boot and physical seizure	Yes, with physical security

The network layer is where the self-hosting myth is most inverted. The intuition says a home server keeps your traffic private. The reality is that your ISP sees the metadata of every connection — destination addresses, timing, volume, and, unless you have deployed encrypted DNS and encrypted SNI (Server Name Indication — the part of a TLS handshake that otherwise reveals which site you are reaching), the very domain names you reach. Content encryption does not hide the envelope: as the EFF’s Surveillance Self-Defense project explains, metadata alone reveals a great deal — including which sites you connect to, even when the payload is encrypted. A home service can make this worse — an always-on server produces a distinctive, continuous traffic signature that is easier to profile than intermittent browsing. And a self-hosted mail server leaks by protocol design: SMTP stamps a Received-header chain and the sender’s IP into every message, exposed to each recipient’s provider and every relay in between. You cannot self-host your way out of metadata; you can only choose who collects it, and self-hosting often chooses your own name and address as the collector-of-record. This is the same correlation surface we trace in The AI Deanonymization Playbook — scattered “harmless” metadata, fused.

Identity and Jurisdiction: The Layer That Collapses the Stack
#

Identity is the layer that can be perfect nowhere else and still take down everything: one real-name domain registration, one KYC-linked payment, or one card that resolves to you, and a flawless custody-to-packet stack deanonymizes in a single query. It is also the layer nearly every self-hosting guide omits, because it is not a technical setting — it is the boring paper trail of who paid for what, and it is where sovereignty most often quietly dies.

The mechanics are unforgiving. You run your own node, hold your own keys, encrypt everything — and then the coins that funded it came from an exchange that verified your government ID, because the overwhelming majority of centralized exchanges enforce KYC — over 90%, by the count of the compliance vendor Sumsub — and every fiat on-ramp is an identity checkpoint. Or the VPS is paid with a card in your name; or the domain’s registrar holds your real details; or all three share one billing identity that ties the “sovereign” infrastructure into a single legal person. Custody sovereignty without payment-path separation is a locked door in a glass wall — which is why we treat buying Bitcoin without KYC and on-chain payment privacy as prerequisites to the stack, not afterthoughts, and why holding keys is necessary but not sufficient once a real adversary is in the picture.

Jurisdiction is the identity layer’s legal twin, and it is widely misunderstood. The common belief is that where your data physically sits decides who can compel it. Under the US CLOUD Act (Clarifying Lawful Overseas Use of Data Act), that is simply false: a US-based provider can be compelled to produce data regardless of where in the world it is stored (18 U.S.C. § 2713), because jurisdiction follows the provider’s legal domicile, not the bytes. Renting an EU-located server from a US company does not move your data out of US reach. This is a place where genuine self-hosting — on hardware you own, in your own jurisdiction — actually changes the picture, because it removes the third-party provider that could be served an order at all. But notice what it substitutes: direct legal and physical exposure in your jurisdiction, where the order comes to your door instead of a data center’s. Self-hosting does not delete the jurisdiction problem. It swaps a corporate compulsion point for a personal one, and which trade is safer depends entirely on who you are and where you live.

That “who you are” is not a footnote. For a domestic-abuse survivor, a dissident, or anyone whose safety depends on a pseudonym, the identity layer is not the last item on a checklist — it is the whole point, the layer a self-hosting guide written without an explicit threat model prices at zero. Sovereignty that publishes your name in a WHOIS record or a payment ledger is sovereignty for people who were never really at risk.

Grading Three Setups Against the Five Layers
#

Grade any real setup layer by layer and the weakest-layer rule stops being abstract: in each of the three below, the setup nails the layer it was built for and fails a different one hard enough to set the whole score. The grades are deliberately coarse — the point is the shape of the exposure, not false precision.

Setup	Custody	Data	Compute	Network	Identity	Real sovereignty (= weakest)
Home Bitcoin node	Strong	Strong	Strong (your hardware)	Weak (ISP sees node traffic)	Weak (KYC coins)	Weak — network + identity
Nextcloud on rented VPS	Medium	Weak (host-readable)	Very weak (hypervisor)	Weak (provider + ISP)	Medium	Very weak — compute
Self-hosted mail server	Strong	Medium	Depends (VPS vs owned)	Very weak (SMTP metadata)	Weak (IP ↔ real name)	Very weak — network

A home Bitcoin node is the success story people cite, and on custody, data, and compute it earns the praise — the keys are yours, the validation is yours, the hardware is yours. But run the audit and the score drops to its network and identity layers: your ISP sees the node’s traffic (Blockstream’s own guidance recommends Tor precisely because of this), and if the coins arrived from a KYC exchange, the identity layer was never sovereign at all. Nextcloud on a rented VPS feels like owning your cloud, and it does improve custody over Google Drive — but the compute layer is host-readable by design, so “your” cloud is legible to your provider. And a self-hosted mail server, the most demanding project of the three, buys strong custody and then hemorrhages network-layer metadata through SMTP to every correspondent’s provider. In all three, the effort went into the visible layer and the exposure lives in a quiet one. That is not a coincidence; it is what “theater” means here — the performance of sovereignty concentrated exactly where the audience (and the operator) is looking.

The Cypherpunk Read: Build It Into the Mechanism
#

The cypherpunks settled the underlying question thirty years ago: privacy that depends on trusting a provider, a jurisdiction, or your own discipline is privacy granted out of beneficence, and the durable kind has to be built into the mechanism instead. Read against the self-hosting debate, that is not nostalgia — it is a design test you can apply to any layer of the audit.

“We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy out of their beneficence. … We must defend our own privacy if we expect to have any.” — Eric Hughes, A Cypherpunk’s Manifesto, 1993

The manifesto’s point, carried into 2026, is that the question is never “do I trust this host, this ISP, this registrar” — it is “does my privacy survive if I don’t.” A rented VPS fails that test at the compute layer; a self-hosted mail server fails it at the network layer; a KYC-funded node fails it at identity. Self-hosting is a genuine cypherpunk instinct — the manifesto’s “defend our own privacy” made concrete — but the instinct only pays off when it removes a trust dependency rather than relocating one. The most durable moves are structural, the same lesson that holds when personal technique meets institutional power: prefer designs where no single party can betray you, over designs where you are simply betting they won’t.

Bottom Line — Fix Your Weakest Layer First
#

The only productive move is to find your weakest layer and fix it first, because every other improvement is capped by the minimum. The mistake is optimizing the layer you already understand. The audit’s payoff is that it points you at the layer you have been avoiding — in the three setups we graded, always network or identity — which is almost always the one setting your real score.

Run the audit before you buy hardware. Grade all five layers of your current setup honestly and find the minimum. If your weakest layer is identity — KYC-linked coins, a real-name domain, a card that resolves to you — no amount of new hardware helps; fix the paper trail first, because it caps everything above it.
Stop paying the compute tax you can’t see. If sovereignty is the goal, a rented VPS is not compute you control; treat anything on it as legible to the host. Reserve self-hosting-on-rented-infra for workloads where that is acceptable, and use owned hardware (accepting its physical and jurisdictional exposure) for the ones where it is not.
Assume the network layer leaks, and plan for it. Your ISP and every mail hop see metadata regardless of content encryption. Encrypted DNS and SNI, Tor for services that support it, and simply not self-hosting the workloads (like public email) whose protocols broadcast your identity are worth more than another server.
Judge every layer by the cypherpunk test. Not “do I trust this party,” but “does my privacy hold if I don’t.” A setup that passes that test at all five layers is sovereign. One that passes at four is exactly as sovereign as its fifth.

Sovereignty is not a place you arrive by moving a workload in-house. It is a property you can only claim at the layer where you are still exposed — and the honest move is to find that layer, name the dependency you merely relocated, and decide, with open eyes, whether the trade was worth it.

Key Takeaways

Sovereignty is the minimum, not the sum: your real score is your weakest layer — custody, data, compute, network, or identity — because an adversary attacks the weak one, not the strong one.
A rented VPS is not compute you control: the hypervisor can read your VM’s RAM by design, and encryption at rest doesn’t help a running server; confidential computing is the only fix and remains rare in 2026.
Self-hosting usually leaks more network metadata, not less: your ISP sees destinations and timing regardless of content encryption, and a self-hosted mail server stamps identifying metadata into every message via SMTP.
Jurisdiction follows the provider, not the bytes: under the US CLOUD Act, a US company can be compelled to hand over data stored anywhere in the world — so an EU-located rented server from a US provider is not out of reach.
Identity collapses the whole stack: one KYC-linked payment or real-name domain deanonymizes a flawless custody-to-packet setup, and it’s the layer most guides omit entirely.

Frequently Asked Questions
#

Is self-hosting more private than using the cloud?
#

Not automatically, and at some layers it is less private. Self-hosting can improve custody and, on hardware you own, compute — you hold the keys and control the machine. But it does nothing for network metadata (your ISP still sees your traffic) and often makes it worse, since an always-on home server has a distinctive traffic signature. And a self-hosted mail server actively leaks more identifying metadata than a mainstream provider. Privacy is a per-layer question; “self-hosted” answers only one or two of the five.

Can my VPS provider read my data?
#

Yes, at the compute layer, and you cannot prevent it with ordinary encryption. The hypervisor that runs your virtual machine can read the machine’s memory by design, and while disk encryption protects data at rest, a running server keeps its keys and plaintext in RAM, which the host can access. Whether a given provider actually does this is a trust question, but the capability means compute on a rented VPS is outside your control. Confidential computing (AMD SEV-SNP, Intel TDX) is the only real fix; the major clouds offer it as a premium option, but it is still absent from the commodity VPS plans most people use.

Does storing my data in Europe protect it from US law?
#

Not if the provider is a US company. The US CLOUD Act compels US-based providers to produce data regardless of where in the world it is stored, because jurisdiction follows the provider’s legal domicile, not the physical location of the bytes. An EU data center owned by a US firm is still reachable. Removing the third-party provider entirely — genuine self-hosting on hardware you own — changes this, but substitutes direct legal exposure in your own jurisdiction.

What is the weakest layer in a typical self-hosting setup?
#

Usually identity or network, because those are the layers people don’t think of as part of “hosting.” A home Bitcoin node can be flawless on custody and compute and still be tied to you by KYC-linked coins (identity) or ISP-visible traffic (network). Since your real sovereignty equals your weakest layer, fixing the paper trail and the metadata often matters more than any hardware upgrade.

Is “digital sovereignty” through self-hosting just marketing?
#

The word is oversold, but the practice isn’t worthless. Self-hosting genuinely relocates control — the honest question is whether it removes a trust dependency or just moves it somewhere less visible (your ISP, your power utility, your hardware supply chain, the certificate authorities). It becomes real sovereignty only where it removes a party who could otherwise be compelled or could betray you. Graded layer by layer against that test, some self-hosting is true sovereignty and much of it is theater.

#	Source	URL	Archive
1	US CLOUD Act — Cross-Border Data Forum FAQ	https://www.crossborderdataforum.org/frequently-asked-questions-about-the-u-s-cloud-act/	https://web.archive.org/web/*/https://www.crossborderdataforum.org/frequently-asked-questions-about-the-u-s-cloud-act/
2	EFF Surveillance Self-Defense — Why Metadata Matters	https://ssd.eff.org/module/why-metadata-matters	https://web.archive.org/web/*/https://ssd.eff.org/module/why-metadata-matters
3	Wikipedia — Cold boot attack	https://en.wikipedia.org/wiki/Cold_boot_attack	https://web.archive.org/web/*/https://en.wikipedia.org/wiki/Cold_boot_attack
4	Blockstream — Keeping your Bitcoin node secure and private	https://help.blockstream.com/education/nodes/set-up-and-optimization/how-do-i-keep-my-bitcoin-node-secure-and-private	https://web.archive.org/web/*/https://help.blockstream.com/education/nodes/set-up-and-optimization/how-do-i-keep-my-bitcoin-node-secure-and-private
5	IETF — RFC 5321, Simple Mail Transfer Protocol (trace / Received headers)	https://www.rfc-editor.org/rfc/rfc5321	https://web.archive.org/web/*/https://www.rfc-editor.org/rfc/rfc5321
6	VPSBG — Intel SGX vs AMD SEV (confidential computing)	https://www.vpsbg.eu/blog/intel-sgx-vs-amd-sev-the-ultimate-comparison/	https://web.archive.org/web/*/https://www.vpsbg.eu/blog/intel-sgx-vs-amd-sev-the-ultimate-comparison/
7	Sumsub — Custodial vs non-custodial wallets & KYC	https://sumsub.com/blog/custodial-vs-non-custodial-wallets/	https://web.archive.org/web/*/https://sumsub.com/blog/custodial-vs-non-custodial-wallets/
8	Eric Hughes — A Cypherpunk’s Manifesto (1993)	https://www.activism.net/cypherpunk/manifesto.html	https://web.archive.org/web/*/https://www.activism.net/cypherpunk/manifesto.html
9	US CLOUD Act — 18 U.S.C. § 2713 (statute text)	https://www.law.cornell.edu/uscode/text/18/2713	https://web.archive.org/web/*/https://www.law.cornell.edu/uscode/text/18/2713

Cora Aegis

Cora Aegis writes privacy-first OPSEC guidance at CypherpunkGuide, reading the tools and slogans of the privacy world for the mechanism underneath — here, why "self-hosting" earns the word sovereignty at some layers and quietly borrows it at others.

More about Cora →

Bitcoin Silent Payments: A Hands-On Guide (2026)

Thu, 09 Jul 2026 00:00:00 +0000

There is a small, quiet contradiction at the center of receiving Bitcoin. Every guide tells you never to reuse an address — reuse is one of the cleanest signals a chain-analyst has. Yet the moment you want to be paid — a tip jar in a bio, a donation line in a README, an invoice you send once and forget — you need an address that stays put. Rotating addresses and static identity pull in opposite directions.

Silent Payments (BIP-352) are the protocol that resolves it: you publish one address, and every person who pays you derives a different on-chain address for it, so an observer watching the chain sees unrelated outputs with no shared destination. It is among the most significant changes to receiving privacy in years. It is also widely misunderstood, half-shipped across wallets, and carries a real cost that the enthusiastic write-ups tend to gloss.

I write under a pseudonym and treat every coin I hold as already watched, so I did not want to take the protocol on faith. Before writing a word of this guide, I wrote a from-scratch implementation of BIP-352 in Python — using libsecp256k1 through the coincurve library — and ran it against the specification’s official test vectors: 28 of 28 sending sub-cases and 29 of 29 receiving sub-cases matched, bit for bit, in under 200 milliseconds (bundle log). What follows is the working version — what it protects, which wallets deliver it in 2026, and the scanning cost you should understand before you rely on it.

The promise	The reality	The catch
“One address, total privacy”	One address, receiving privacy only	Amounts and your senders are untouched
“It replaces mixing”	It solves a different problem than CoinJoin	It does not mix; it prevents the reuse link
“Just publish it and forget it”	Publishing is free; receiving is not	Someone has to scan the chain for your coins
“Every wallet supports it now”	Sending is common; receiving is newer	Check send vs. receive per wallet, per version

What a Silent Payment Actually Is (and What It Doesn’t Protect)
#

A Silent Payment is a reusable Bitcoin address, defined by BIP-352, that lets a payer derive a unique, unlinkable on-chain address for you from a single string you publish once. It protects the receiving link — the connection between separate payments to the same identity — and nothing else. It does not hide amounts, it does not protect your senders, and it does nothing about the off-chain records that tie coins to your name.

The address is two public keys — a scan key and a spend key — encoded together. On mainnet it begins with sp1; on a test network it begins with tsp1 (the human-readable prefix is sp / tsp, and the 1 is just the bech32m separator). When someone pays you, their wallet combines its own input keys with your scan key to compute a shared secret, and from that secret derives a fresh Taproot output that only you can detect and spend. No two payers produce the same output, and there is no “notification transaction” announcing the link, the key improvement over the older BIP-47 payment-code approach.

What it leaves exposed is worth stating plainly, because the word “private” does a lot of unearned work in this space. Silent Payments are a receiving tool. The amount you receive is still visible on-chain. The payer’s own privacy is their problem, not yours. And the strongest attack on a named pseudonym is rarely the chain at all — it is the writing, the metadata, the KYC exchange where coins meet a passport. That is the additive model laid out in how on-chain tracing actually works and, off-chain, in AI deanonymization. Silent Payments close one specific, valuable gap. They are necessary, not sufficient.

Which Wallets Support Silent Payments in 2026
#

Support is real but uneven, and the single most useful habit is to check sending and receiving separately — they shipped at different times, in different wallets, sometimes years apart. Sending to a Silent Payment address is now common; being able to receive to one, which requires the wallet to scan the chain, is newer and rarer. The table below reflects primary sources as of 2026-07-09; verify against each project’s release notes before you move real money, because this list moves.

Wallet	Send	Receive	Notes (as of 2026-07-09)
Sparrow	✅ v2.3.0 (Oct 2025)	✅ v2.5.0 (May 2026)	Fullest desktop implementation; hardware-wallet signing via BIP-375 added v2.4.0 (Feb 2026). Latest v2.5.2
Cake Wallet	✅	✅	First full-feature mobile wallet (v4.18.0, late May 2024). Uses on-device scanning — heavier on battery and sync time
Bitcoin Core	⏳ not merged	⏳ not merged	The `libsecp256k1` cryptographic module is merged (PR #1765); wallet-level support is still open (PR #35301 / #35302)

Two cautions the table compresses. First, “receive” is the line that matters and the one that lags — a wallet can let you pay a friend’s sp1 address long before it can hold one of your own. Second, the way a wallet scans is a privacy decision, not just a performance one, and it is the subject of the next two sections. For acquiring the coins you will receive this way in the first place, without seeding the identity link at the exchange, see buying Bitcoin without KYC.

Sending: The Easy Half
#

Sending to a Silent Payment address is the straightforward half of the protocol, because the sender does all their work locally and never has to scan anything. In a wallet that supports it — Sparrow is the reference desktop experience — you paste the recipient’s sp1… address into the send field exactly as you would any other, and the wallet does the derivation invisibly.

Under the hood, your wallet takes the private keys of the inputs it is spending, combines them with the recipient’s scan key to compute a shared secret, and uses that secret to derive a one-time Taproot output address for this specific payment. Because the derivation folds in your inputs, the same recipient address yields a different on-chain output every time a different person — or a different set of your coins — pays it. The sender needs nothing from the recipient beyond the published address: no round-trip, no notification, no interaction. That is why send-side support arrived first and is now the common case. The asymmetry is the whole story of the next section: the cost that sending avoids is precisely the cost that receiving cannot.

Receiving: The Scanning Cost Nobody Warns You About
#

To receive Silent Payments, your wallet must examine candidate outputs across the blockchain and test each one against your keys to find the payments meant for you — there is no address on the chain to simply “look up.” This scanning cost is the central, under-reported tradeoff of BIP-352, and how your wallet resolves it determines both your convenience and your privacy. Publishing the address is free. Finding what was sent to it is not.

If you run your own full node, scanning is a local computation over block data — demanding but private, because nothing leaves your machine. The friction appears when you want to receive on a phone or a laptop without a node. That is where an indexing server comes in. For Sparrow, the server is Frigate (a Silent Payments Electrum server, latest v1.5.3), and a public instance exists at frigate.2140.dev. You do not “visit” it in a browser — it speaks the Electrum protocol, not HTTP. In Sparrow you choose it under Preferences → Server → Public Server, then test the connection.

Here is the part the cheerful tutorials skip, and it is a privacy point, not a footnote. To let a server scan on your behalf, your wallet hands that server your scan private key and your spend public key. Even when the server holds them only in memory, as Frigate is designed to, a malicious or compromised indexer can use them to reconstruct exactly the picture Silent Payments are meant to deny an observer: the full list of payments you have received. The hands-on guide at bennet.org says it directly — a bad server “could build exactly the picture of your receiving history that Silent Payments are meant to prevent.” So the honest framing is a spectrum: your own node is fully private and more work; a public indexer is convenient and asks you to trust its operator with your receiving history. Choose deliberately, and do not let “I use Silent Payments” become a false sense of safety when a stranger’s server is doing your scanning.

I Reproduced BIP-352 by Hand
#

The fastest way to trust a privacy protocol is to make it run and check it against the specification’s own numbers, which is what I did rather than take the claims on faith. My from-scratch implementation reproduces all 57 official test-vector sub-cases exactly — 28/28 sending, 29/29 receiving — and the full log plus the scripts ship with this article (bip352-verification.txt), so you can reproduce them yourself. More useful than the pass count, though, is watching a single payment derive step by step.

Take one published address and trace what a sender computes. The values below are real, from the specification’s own test vectors:

Step	What it is	Value (abbreviated)
`a`	Sum of the sender’s input private keys	`7ed265a6…56345f86`
`A`	Sum of the matching public keys	`032562c1…dedc4bee`
`input_hash`	Hash binding the specific coins spent	`5bfe5321…b7ad0668`
`ecdh`	Shared secret both sides derive independently (`input_hash · a · B_scan`)	`028158af…3e14d80d`
`t₀`	Tweak, `hash(ecdh‖0)`	`f438b401…c2e7eef6`
output	`B_spend + t₀·G` (the on-chain address)	`3e9fce73…de46e3c1`

Now the property that makes the whole thing worthwhile. I constructed a second, independent sender myself — different key material, a notional different coin — paying the same published address (no transaction is broadcast here; like the trace above, this is pure derivation). Its output was 3f1dd702…879b98ad. Two payments, one address, and on-chain the two outputs share nothing: no common address, no visible link. Only the holder of the scan key can run the reverse computation and recognize both as theirs. That is the receiving-privacy guarantee, and you can watch it hold in the trace rather than believe it as an assertion. It is the on-chain counterpart to the reuse problem dissected in Bitcoin on-chain privacy — the same clustering that reuse hands an analyst for free is exactly what this derivation withholds.

The Gotchas: Multisig, Labels, and the K_max Limit
#

Beyond the scanning cost, three implementation details decide whether Silent Payments fit your setup — and each is the kind of thing you want to learn before you rely on it, not after. These are the corners the how-it-works explainers rarely turn.

Multisig and collaborative transactions are awkward. Because a sender derives the payment from the private keys of the inputs being spent, sending from a multisignature wallet or a CoinJoin — where the signing keys are split across parties who must not simply pool them — does not compose cleanly with BIP-352. Silent Payments solve the reuse link, not the mixing problem; if you want amount and graph privacy, that is still the province of collaborative transactions, covered in on-chain privacy. Treat them as complementary, not interchangeable.
Labels are convenience with an asymmetry. BIP-352 lets a receiver derive labeled variants of one address — useful for telling apart which outputs came from which source. The label information is meaningful only to you, the holder; it is not exposed on-chain. But it is bookkeeping you keep, which means it is bookkeeping a compromised wallet or backup can leak. Convenience, tracked honestly.
There is a recipient limit, K_max = 2323. The specification (v1.1.0, March 2026; current v1.1.1, April 2026) caps how many outputs a single group may derive, as a defense against transactions crafted to blow up a receiver’s scanning work. You will never hit it as an individual — but it is why a naïve “pay 3,000 outputs to one address” fails by design, and it tells you the protocol authors took the scanning-cost attack seriously.

A related reality check on light clients, since it is where people expect the scanning problem to be already solved: as of mid-2026 there is no single production-ready, trust-minimized light-client tool you can just install. The blindbitd wallet daemon was archived in August 2025; only its companion indexer, blindbit-oracle, is actively maintained, and the light-client specification is still a work in progress. Experimental libraries like bdk-sp exist, but their own authors warn against mainnet use. If a guide implies phone-based Silent Payments receiving is a solved, no-tradeoff experience, it is ahead of the software.

Bottom Line: Should You Use Silent Payments Yet?
#

Silent Payments are ready for a specific, valuable job — a reusable public receiving address that does not leak a reuse link — and not yet ready to be your only privacy tool or a frictionless mobile default. Match the tool to the job, and run your own node if the receiving history is sensitive. The honest goal here is better receiving privacy, not anonymity.

Your situation	Verdict	How
A public tip/donation address (creator, project, pseudonym)	Strong fit	Publish one `sp1…` address; scan with your own node if you can
Everyday receiving, you run a node	Good fit	Sparrow + your node; fully private scanning
Everyday receiving, no node, phone-first	Partial	Works via a public indexer — accept the trust tradeoff, or wait for light clients
You want amount or sender-graph privacy	Wrong tool	Silent Payments don’t do this; see collaborative transactions and Lightning
Sending from multisig / CoinJoin	Check carefully	Composition is awkward; verify your wallet’s support first

Whatever your case, the sequence is the same as it always is: name the adversary, fix the cheap and irreversible links first — no-KYC acquisition where lawful, coin hygiene, never reusing a plain address — and add Silent Payments where they close the specific gap of a published address you want kept unlinkable. It is a genuine advance. It is also a receiving tool with a scanning bill, and knowing who pays that bill — you, or a server you trust — is the difference between privacy and the feeling of it.

Key Takeaways

Receiving only: Silent Payments (BIP-352) give one reusable sp1… address with no on-chain link between payments to it — but they do not hide amounts, protect senders, or touch off-chain identity leaks.
Send is easy, receive has a cost: sending derives locally with no interaction; receiving requires scanning the chain, either on your own node or via an indexing server.
The public-server tradeoff is real: a public indexer like Frigate receives your scan private key and spend public key, so a malicious server can reconstruct your receiving history — run your own node when it matters.
Support is uneven in 2026: Sparrow sends (v2.3.0, Oct 2025) and receives (v2.5.0, May 2026); Cake Wallet does both on-device; Bitcoin Core’s wallet support is still unmerged.
I verified it: a from-scratch BIP-352 implementation matched all 57 official test vectors (28/28 sending, 29/29 receiving); the log and scripts ship with this article.

Frequently Asked Questions
#

What is a silent payment address?
#

A silent payment address is a reusable Bitcoin address, defined by BIP-352, that you can publish once — it begins with sp1 on mainnet. Unlike an ordinary address, every payer derives a different one-time on-chain address from it, so payments to you carry no shared, linkable destination. It encodes two public keys (a scan key and a spend key) rather than a single script.

Do Silent Payments hide the amount I receive?
#

No. Silent Payments protect the receiving link — the connection between separate payments to the same identity — and nothing else. The amount of each payment is still recorded on the public blockchain, your senders’ own privacy is unaffected, and off-chain records (such as a KYC exchange) are untouched. For amount privacy, Lightning or collaborative transactions are the relevant tools.

Which wallets support Silent Payments in 2026?
#

As of 2026-07-09, Sparrow supports both sending (since v2.3.0, October 2025) and receiving (since v2.5.0, May 2026); Cake Wallet supports both with on-device scanning (since v4.18.0, late May 2024). Bitcoin Core’s wallet-level support is not yet merged, though the underlying cryptographic module is. Always check send and receive support separately, and verify against current release notes.

Why is receiving a Silent Payment slow?
#

Because there is no address on the chain to look up. To find payments sent to you, your wallet must scan candidate outputs across blocks and test each against your keys. On your own node this is a private local computation; without a node, you rely on an indexing server, which is faster but introduces a trust tradeoff. Light-client tooling that removes both the cost and the trust is still a work in progress.

Are Silent Payments still private if I use a public server?
#

Only partially. To scan on your behalf, a public indexer receives your scan private key and spend public key. Even held only in memory, those keys let a malicious or compromised server reconstruct the full history of payments you have received — the very thing Silent Payments are meant to prevent from a chain observer. Running your own node avoids this; a public server trades that privacy for convenience.

#	Source	URL	Archived
1	BIP-352 — Silent Payments (specification, v1.1.1)	https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki	https://web.archive.org/web/*/https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki
2	Bitcoin Optech — Silent Payments topic	https://bitcoinops.org/en/topics/silent-payments/	https://web.archive.org/web/*/https://bitcoinops.org/en/topics/silent-payments/
3	Sparrow Wallet — Releases	https://github.com/sparrowwallet/sparrow/releases	https://web.archive.org/web/*/https://github.com/sparrowwallet/sparrow/releases
4	Frigate — Silent Payments Electrum server	https://github.com/sparrowwallet/frigate	https://web.archive.org/web/*/https://github.com/sparrowwallet/frigate
5	bennet.org — Silent Payments hands-on guide (server privacy tradeoff)	https://bennet.org/learn/silent-payments-bitcoin-privacy/	https://web.archive.org/web/*/https://bennet.org/learn/silent-payments-bitcoin-privacy/
6	libsecp256k1 — Silent Payments module (PR #1765, merged)	https://github.com/bitcoin-core/secp256k1/pull/1765	https://web.archive.org/web/*/https://github.com/bitcoin-core/secp256k1/pull/1765

Three threads on this site connect here. Silent Payments answer the receiving half of the reuse problem dissected in Bitcoin On-Chain Privacy: How Tracing Works — read that for what clustering sees and what it doesn’t. Because the address is only as private as the coins you receive into it, pair this with Buying Bitcoin Without KYC, which fixes the identity anchor upstream. And because the chain is never the whole threat, AI Deanonymization covers the off-chain inference that runs in parallel to all of it.

Age Verification 2026: The Anonymity Cost and Your Defense

Wed, 24 Jun 2026 00:00:00 +0000

For most of the open web’s life, you could read, watch, and speak without first proving who you were. That assumption is now being repealed in law. In 2025 and 2026, a wave of statutes across the UK, the European Union, the United States, and Australia has made age verification a precondition for ordinary online access, and the quiet detail inside almost every one of them is that everyone must verify, not only the children the laws are named for. To prove a stranger is over a threshold, the system first has to learn who that stranger is.

That is the trade the headlines skip. The UK’s Online Safety Act age checks have been enforced since mid-2025, with the regulator Ofcom already issuing penalties for non-compliance. In June 2025 the US Supreme Court upheld a Texas age-verification law, removing the constitutional objection that had blocked a dozen state copies. Australia switched on a nationwide under-16 social-media ban in December 2025. And every one of these regimes runs on the same machinery: a checkpoint that collects, or checks against, a government-grade identity — and a database that holds the result.

We read the statutes and the breach disclosures side by side, the way this site always reads a threat, looking past the stated intent to the mechanism it creates. The pattern that emerges is not the one the “just use a VPN” guides describe. The lasting harm is rarely the inconvenience of a check at the door; it is the permanent, pre-correlated identity record the check leaves behind, the fact that the people most exposed by it are the vulnerable ones it claims to shield, and the reality that no single tool buys back the anonymity it removes. What actually protects you depends on how the specific law checks you — and that is a different problem than “how to get past the age gate” sets out to solve.

What the 2026 Age-Verification Wave Actually Requires
#

Age verification in 2026 is no longer a proposal but enforced law across the UK, Australia, and a growing list of US states, with the EU and others close behind — and what unites these regimes is that adults must prove identity to reach ordinary services, most often by handing over a government ID, a face scan, or a credit card. The “age check” framing implies a light touch. In practice the dominant methods bind a real identity to an access event, which is the opposite of a light touch.

The map below is the landscape we assembled from the primary statutes and regulator guidance: who requires what, and where each stands as of mid-2026. Status matters, because several of these laws are live, several are still moving, and at least one has already been struck down — a reminder that the trend is strong but not uniform.

Jurisdiction	What it requires	Status (as of 2026-06)
UK — Online Safety Act	Age assurance for pornographic and other “harmful” content	In force since July 2025; Ofcom enforcing with investigations and fines
US — Texas HB 1181 + state copies	Age verification for adult-content sites	SCOTUS upheld the Texas law in June 2025; roughly half of US states now have laws, some blocked in court
Australia	Ban on under-16s holding social-media accounts	In force since December 2025; penalties up to A$49.5M per platform
EU — DSA + eIDAS wallet	Age-verification methods for very large platforms; an EU age-verification app	Blueprint published 2025, member-state pilots running, target operation by end of 2026
France	Ban on under-15s on social media	National Assembly passed it (Jan 2026); the Senate passed a divergent version (Apr 2026), so it is not yet law — reconciliation pending
US federal — KOSA, SAFE Kids Act	Various duties and age checks	Introduced and debated, but not enacted as of mid-2026

Two facts inside that table do the real work. First, the US Supreme Court’s June 2025 decision in Free Speech Coalition v. Paxton upheld Texas’s law 6-3 under intermediate scrutiny (a middle-tier constitutional test, less demanding than the strict review that had blocked earlier versions), which removed the First Amendment barrier and opened the door for the other states. Second, the laws reach adults by construction: a system that blocks minors must test everyone, so the UK’s age-assurance duty and Australia’s under-16 rules make the entire adult population prove itself too. The “think of the children” framing obscures a universal identity checkpoint.

How that checkpoint works is the part that determines your exposure, and your defense. Three methods dominate, and they are not equivalent on privacy:

Verification method	How it works	Privacy property
Location / IP gate	Blocks or allows by detected region	Weakest privacy impact, but trivially defeated by a VPN; being phased toward stronger methods
ID upload or facial age-estimation	You submit a government ID or a selfie scanned for estimated age	Highest identity exposure; relies on a third-party vendor whose data handling you cannot inspect
Digital ID / zero-knowledge token	A wallet or credential asserts “over N” without revealing the underlying data	Strongest in design, but the credential must still be issued by someone who verified your identity first

The strongest-on-paper method is the EU’s stated direction: a wallet that proves you are over a threshold while revealing no identity data to the website. That is a genuine improvement over an ID upload, and it deserves to be the standard. But it is a design claim, not yet a deployed guarantee, and it does not erase the identity step that happens upstream when the credential is first issued. Hold that distinction; the defense section turns on it.

The Honeypot You Cannot Reset
#

An age-verification system does not check you and forget you — it creates a pre-correlated identity record (your name, face, date of birth, and the list of sites you proved yourself to) concentrated in one place, and unlike a password, a leaked faceprint cannot be reset. This is the harm the convenience framing hides. A password breach is recoverable: you rotate the secret and move on. A biometric and identity-document breach is permanent, because you cannot reissue your face or your birth date. The database assembled “just this once” to protect children becomes a standing attack surface that outlives the law that demanded it.

Two properties make it worse than an ordinary data store. The first is pre-correlation. A breached marketing list is a pile of emails an attacker still has to enrich and link. An age-verification record arrives already joined: identity, biometric, and the sensitive fact of which adult services an individual accessed, in one row. That is the exact correlation engine described in The AI Deanonymization Playbook, except the law assembles it for the attacker in advance. The second is permanence as a planning assumption. The honest threat model treats any such database as already breached on day one, the same assume-breach posture we apply to government data in When the Government Leaks Your Data — because the moment a verification record is created, its eventual exposure is a question of when, not whether, and its contents never expire.

This is not hypothetical. When Discord rolled out age checks, an October 2025 breach of its third-party verification vendor exposed roughly 70,000 users’ government-ID images (Cybernews) — the identity-honeypot risk critics had warned of, made real. A verification record is exactly the high-value, irreversibly sensitive target attackers hunt, and these laws conjure one into existence at every gate. Each incident is a permanent disclosure: the people exposed cannot un-verify, cannot rotate the leaked identity, and cannot remove the record from the broker markets and archives that copy it. As we documented in How Permanent Is Your Social Media Footprint, deletion at the source does not reach the copies — and a verification database is the most sensitive copy of all.

The “just this once” justification deserves particular suspicion, because surveillance infrastructure reliably outlives its stated purpose. A database built for age-gating is a database, and databases get repurposed, subpoenaed, sold in a bankruptcy, and breached. The question to ask of any age-verification mandate is not “do I trust this provider today” but “am I comfortable with this identity record existing forever, in every hand it eventually reaches.” For most people, honestly answered, the answer is no.

Whose Safety? The Users Age Verification Puts at Risk
#

The stated case for age verification is child safety, yet the people it most reliably exposes are the vulnerable ones it claims to protect — LGBTQ youth in unsupportive homes, domestic-abuse survivors, and dissidents — for whom anonymity is not a convenience but the precondition of safety. This is the dimension the regulatory debate treats as an afterthought, and treating it as an afterthought is how laws get written that harm the people in their own titles.

For a young person in a hostile household, anonymous access is often the only route to supportive community, health information, or simply a space where they are not surveilled by the people they live with. Civil-liberties organizations have documented at length how age-verification and parental-linkage requirements cut off that access, converting a lifeline into a checkpoint that reports back to the home. The mechanism that “protects” a child in a safe home endangers one in an unsafe home, and the law cannot tell the two apart.

The same inversion holds for domestic-abuse survivors, and here the harm is structural, not incidental. Anonymity is how a survivor reads, plans, and reaches help without an abuser tracking the activity — and an age-gate that ties identity to access, or that routes through a shared family account or device, is a ready-made surveillance lever for a controlling partner. This is the intimate-partner threat surface the gender-neutral guides price at zero, the same blind spot we trace in How Activists Are Doxxed in Authoritarian Regimes: a control that assumes a benign household becomes a weapon in a coercive one. For dissidents and journalists, the logic is identical at the scale of the state — mandatory identity at the door turns a reading habit into a record.

None of this means child safety is not a real goal. It means the chosen instrument — mandatory identity verification for everyone — transfers risk onto the most exposed users while doing little the determined evade anyway, since minors routinely find the bypasses the same systems leave open. A coalition of digital-rights and civil-liberties groups has warned legislators of exactly this trade, that the mandates undermine the privacy and safety of the young people they target, and EFF maintains a running catalogue of who these mandates harm. When a safety measure’s first casualties are the vulnerable, the measure is worth defending against, not just complying with.

What Actually Protects You, and What Is Theater
#

No single tool restores the anonymity an age check removes, and any guide promising one is selling theater — what works depends entirely on how the law checks you, because a VPN defeats a location gate and nothing else, Tor defeats geography but not an ID upload, and even a zero-knowledge age proof still hides an identity check at the moment the credential is issued. Honest defense starts by matching the tactic to the verification method, then accepting the residual risk that no tactic removes.

The matrix below is our synthesis of what each common defense actually defeats, and where it fails. Read it as a decision tool, not a menu: the right row depends on the method in the first table above.

Defense	What it genuinely defeats	Where it fails	Honest verdict
VPN	Location- and IP-based gates (some current UK-style blocks)	Identity or facial checks; provider logging; methods are shifting to defeat it	Partial and fragile; a stopgap, not a shield
Tor Browser	Geolocation gating, network-level observation	ID uploads and facial scans; exit nodes can see unencrypted traffic	Partial; strong for geography, useless against identity proof
Privacy-preserving ZK age proof	Identity exposure at the point of use	Credential issuance still requires an upstream identity check; not yet widely deployed	Promising and worth demanding, but incomplete
No-account / decentralized platforms	The age-gate entirely, by removing the central gatekeeper	Smaller reach; not where most audiences are	Structural, durable, limited in scope
Data minimization / non-compliance	The record that cannot leak if it never existed	Loss of access; not always a real option	Situational; the only defense that prevents the honeypot

A few rows deserve plain language. A VPN is the reflex answer and the weakest one: it relocates you past a location gate, but the moment a law demands an ID upload or a face scan, the VPN is irrelevant, and the regimes are deliberately moving toward methods it cannot touch. Tor is stronger against geography and surveillance but equally helpless against an identity check, and its exit nodes (the last relay before the open internet) are not a place to send an unencrypted ID — the Tor Project’s own guidance warns that an exit relay can read unencrypted traffic. The genuinely interesting option is the zero-knowledge age proof — a credential that proves “over 18” while disclosing nothing else. It is the right direction, and the EU blueprint and several pilots are pursuing it. But its limit is precise and underreported: the proof reveals nothing at presentation, yet someone still had to verify your identity to issue the credential, which relocates the trust problem to the issuer rather than eliminating it. Brave’s engineers make the issuer-chokepoint case directly — a small set of credential issuers gains gatekeeping power over the web. The deeper limit is logical: an issuer cannot vouch that you are over 18 without first establishing it, so the identity check moves upstream rather than disappearing. Zero-knowledge is a real improvement over ID uploads; it is not anonymity restored.

The pattern across the table is the lesson cypherpunks have always drawn where personal technique meets institutional power: the most durable defenses are structural, not tactical. A VPN or a workaround is a delaying move against a system designed to close it. Choosing platforms with no central gatekeeper to compel, and handing over the least identity the situation permits, are the only moves that change the shape of the problem rather than postponing it. That is the same infrastructure-over-identity principle that holds for publishing under repression, and it holds here.

The Cypherpunk Read: A Thirty-Year Pattern
#

Age verification is the 2026 form of a demand that recurs every decade — a request to weaken everyone’s privacy in the name of protecting children — and recognizing it as a pattern, from the Communications Decency Act of 1996 through today’s age-assurance mandates, is what keeps you from mistaking the latest version for a novel emergency. The specifics change; the structure does not. A genuine concern about minors is offered as the reason to build an identity checkpoint that, once built, applies to everyone and serves purposes far beyond the original.

The cypherpunks named the underlying truth thirty years ago, before the web most of these laws govern even existed.

“Privacy is necessary for an open society in the electronic age. … We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy out of their beneficence.” — Eric Hughes, A Cypherpunk’s Manifesto, 1993

Read against the age-verification wave, the line is not nostalgia; it is a design spec. Privacy that depends on a verification vendor’s good behavior, a regulator’s restraint, or a database that is never breached is privacy granted out of beneficence — exactly the kind Hughes warned would not hold. The cypherpunk answer was never “refuse all safety measures.” It was that privacy has to be built into the mechanism, so it does not rely on trust that institutions reliably betray. Applied to age verification, that is a concrete and constructive position: prefer device-level and zero-knowledge methods that prove a fact without storing an identity; reject centralized identity databases as the single most dangerous design; and treat any system that makes the open web conditional on showing your papers as the surveillance infrastructure it is, however kindly it is named. The goal of protecting children is real. The method of mandatory universal identity is the thing a privacy-literate public should refuse — and build alternatives to.

Bottom Line — Which Defense Fits Your Threat Model
#

The right response depends on who you are and what the law in front of you actually checks, not on a single tool you can install and forget.

If you live under an enforced location-style gate (UK-style blocks): a VPN buys access today, but treat it as a fragile stopgap, not protection — the methods are shifting to defeat it. The durable move is to minimize the identity you ever submit and to prefer platforms and protocols that do not run a central age-gate at all.
If you are a vulnerable user — LGBTQ youth, a domestic-abuse survivor, a dissident or journalist: anonymity is your safety, not your convenience. Hand over the least identity any service will accept, avoid age-gates that link to a shared family account or device, and treat a parental-linkage or identity-binding requirement as a tracking vector to route around, because for you it is one.
If you build or advocate: push hard for privacy-preserving age assurance — zero-knowledge proofs, device-level signals, double-blind verification (where neither the platform nor the verifier learns the other’s identity) — over ID uploads and facial scans, and against centralized identity databases in every venue you can reach. The technology to prove a fact without storing a person exists; the policy choice to require it does not yet, and that is where the leverage is.

Across all three, the same truth holds that has held in every privacy fight before it: once an identity record exists, you cannot un-leak your way back to anonymity. You can only decide, before the checkpoint, how much of yourself you hand over — and, past the limit of individual technique, push for the systems that prove what is needed without building a database that follows everyone forever.

Key Takeaways

The wave is real and global: the UK’s age checks have been enforced since July 2025, the US Supreme Court upheld Texas’s law in June 2025, and Australia’s under-16 ban took effect in December 2025 — and each tests every adult, not only minors.
The lasting harm is the honeypot, not the inconvenience: an age-verification record is a pre-correlated identity (name, face, date of birth, sites accessed) that, unlike a password, cannot be reset once breached — and breaches have already happened.
The vulnerable pay first: LGBTQ youth in hostile homes, domestic-abuse survivors, and dissidents lose the anonymity that is their safety, while determined minors find the bypasses anyway.
No tool restores anonymity: a VPN defeats only location gates, Tor only geography, and a zero-knowledge proof still hides an identity check at issuance — match the tactic to the method and accept the residual risk.
Structural beats tactical: the durable defenses are choosing no-gatekeeper platforms and minimizing the identity you ever submit, because those change the problem instead of postponing it.

Frequently Asked Questions
#

Does age verification check my age or my identity?
#

In most current systems, both at once. To confirm you are over a threshold, an ID upload or facial age-estimation method first establishes who you are, then derives the age from it. Only the emerging zero-knowledge and device-level methods aim to prove the age without retaining the identity — and even those rely on an identity check upstream, when the age credential is first issued. Treat any ID-upload or face-scan system as identity verification, because that is what it is.

Can a VPN get around age verification?
#

Only against location-based gates, and only for now. A VPN changes the region a site detects, so it can bypass a block that works purely by geography. It does nothing against a law that requires you to upload an ID or scan your face, because those check identity rather than location — and several regimes are deliberately moving to identity-based methods precisely to close the VPN route. Useful as a short-term stopgap; not a reliable shield.

Why is an age-verification database called a “honeypot”?
#

Because it concentrates the most sensitive personal data — government ID, biometrics, date of birth, and the services a person accessed — in one place, pre-correlated and irresistible to attackers. Unlike a leaked password, a leaked faceprint or ID cannot be reset, so any breach is permanent. Security researchers and breaches of real age-check systems have already shown the dynamic, which is why privacy advocates treat any such database as a liability that should not be created in the first place.

Who is most at risk from age-verification laws?
#

The vulnerable users the laws claim to protect. LGBTQ youth in unsupportive homes lose anonymous access to supportive community; domestic-abuse survivors lose the unmonitored access they need to seek help; dissidents and journalists have a reading habit turned into a record. For all of them, anonymity is a safety mechanism, and identity-binding age checks remove it — while determined minors evade the same systems.

Is there a privacy-preserving way to prove my age?
#

Partly. Zero-knowledge age proofs and device-level age signals can assert “over 18” without disclosing your name, document, or date of birth to the website, and the EU’s blueprint points in this direction. They are a real improvement over ID uploads and the standard worth demanding. The limit is that someone still verifies your identity to issue the credential, so the trust problem moves upstream rather than disappearing. It is better, not solved — and far better than a centralized database of IDs and faces.

#	Source	URL	Archive
1	UK Government — Online Safety Act collection	https://www.gov.uk/government/collections/online-safety-act	https://web.archive.org/web/*/https://www.gov.uk/government/collections/online-safety-act
2	US Supreme Court — Free Speech Coalition v. Paxton (23-1122)	https://www.supremecourt.gov/opinions/24pdf/23-1122_3e04.pdf	https://web.archive.org/web/*/https://www.supremecourt.gov/opinions/24pdf/23-1122_3e04.pdf
3	Australian eSafety Commissioner — Social media age restrictions	https://www.esafety.gov.au/about-us/industry-regulation/social-media-age-restrictions	https://web.archive.org/web/*/https://www.esafety.gov.au/about-us/industry-regulation/social-media-age-restrictions
4	European Commission — EU age verification	https://digital-strategy.ec.europa.eu/en/policies/eu-age-verification	https://web.archive.org/web/*/https://digital-strategy.ec.europa.eu/en/policies/eu-age-verification
5	EFF — 10 (Not So) Hidden Dangers of Age Verification	https://www.eff.org/deeplinks/2025/12/10-not-so-hidden-dangers-age-verification	https://web.archive.org/web/*/https://www.eff.org/deeplinks/2025/12/10-not-so-hidden-dangers-age-verification
6	EFF — The Human Cost of Online Age Verification	https://www.eff.org/deeplinks/2026/01/effecting-change-human-cost-online-age-verification	https://web.archive.org/web/*/https://www.eff.org/deeplinks/2026/01/effecting-change-human-cost-online-age-verification
7	Cybernews — Discord breach exposes ~70,000 government IDs from age verification	https://cybernews.com/news/discord-70000-gov-ids-exposed-zendesk-third-party-breach-scattered-spider/	https://web.archive.org/web/*/https://cybernews.com/news/discord-70000-gov-ids-exposed-zendesk-third-party-breach-scattered-spider/
8	Brave — The limits of zero-knowledge proofs for age verification	https://brave.com/blog/zkp-age-verification-limits/	https://web.archive.org/web/*/https://brave.com/blog/zkp-age-verification-limits/
9	Eric Hughes — A Cypherpunk’s Manifesto (1993)	https://www.activism.net/cypherpunk/manifesto.html	https://web.archive.org/web/*/https://www.activism.net/cypherpunk/manifesto.html
10	Tor Project — Plaintext over Tor is still plaintext	https://blog.torproject.org/plaintext-over-tor-still-plaintext/	https://web.archive.org/web/*/https://blog.torproject.org/plaintext-over-tor-still-plaintext/
11	EFF — Who Is Harmed by Age-Verification Mandates	https://www.eff.org/pages/whos-harmed-age-verification-mandates	https://web.archive.org/web/*/https://www.eff.org/pages/whos-harmed-age-verification-mandates

Cora Aegis

Cora Aegis writes privacy-first OPSEC guidance at CypherpunkGuide, reading new surveillance laws for the mechanism the coverage skips — here, how an age check at the door becomes a permanent identity record, and which defenses actually hold.

More about Cora →

OPSEC in the AI Age: Rebuilding Your Threat Model (2026)

Sun, 14 Jun 2026 00:00:00 +0000

For as long as operational security has existed — OPSEC, the discipline of protecting information by thinking the way the people who want it think — it has rested on one picture of the adversary: a person. An investigator with a budget. A stalker with patience. A recruiter, a border officer, an ex. You learned to build a threat model — a short, honest map of what you are protecting, who wants it, what they can realistically do, and what it costs you to stop them — and then you spent your effort where that map said it mattered. For two decades of digital life, that map was enough.

It is now wrong in four specific places, because the adversary is increasingly not a person but a machine. A machine does not get tired, does not forget, does not need a warrant to read what is already public, and does not work at human scale. The shift is not hypothetical: in a March 2026 Pew Research summary, 50% of U.S. adults said they feel more concerned than excited about the spread of AI — up from 37% in 2021 — and an earlier Pew survey of people familiar with AI found 81% expecting their personal information to be used in ways they would find uncomfortable. The concern is rational. We keep this site’s own server logs under watch for the dozen-or-so self-identifying AI crawler user-agents — GPTBot, ClaudeBot, PerplexityBot, Google-Extended and their peers — and they arrive continuously, on their own schedule, not ours.

We built the four-assumption frame below after working through the privacy guidance that already exists — and finding that most of it either secures enterprise AI systems or stops at a list of consumer tools, leaving the individual’s own threat model unwritten.

So how do you rebuild a threat model when the adversary is a machine? Not by hunting for a delete button — none reaches a model’s trained weights. You rebuild it the way you would after learning the locks on your house no longer fit the door: assumption by assumption. Below are the four that AI breaks, what each one changes, and where your remaining effort actually moves your exposure rather than merely soothing you.

The four-assumption diff — classic OPSEC assumed a human adversary; a machine adversary breaks all four at once (correlation, inference, permanence, synthetic identity), each with a lever that still holds.

Classic OPSEC assumed…	The machine adversary instead…	Your real lever
Linking scattered data is slow, manual work	Correlates millions of fragments cheaply and instantly	Reduce what is linkable across contexts
You only expose what you choose to post	Infers unposted facts from patterns	Manage the signal, not just the statement
Deleting at the source removes the data	Has already absorbed copies into model weights	Prevent at publication; deletion is partial
Identity needs your participation to forge	Synthesizes your voice, face, and writing	Pre-register trust; minimise raw samples

Assumption 1 — Correlation Is No Longer Slow
#

Correlation at scale is the first assumption AI breaks. A machine can join data points that are individually harmless — a reused username, a photo’s embedded location, the cadence of when you post — into a single profile faster and far more cheaply than any human investigator ever could. The old protection was friction: linking your accounts took a person hours, so most adversaries never bothered. That friction is gone.

Correlation here means connecting separate pieces of information into one picture. The danger was never any single post; it was the join. Your professional handle and your anonymous one share a turn of phrase. A landscape photo carries GPS coordinates in its metadata — the invisible data attached to a file, recording where and when it was made. A delivery review, a race result, a public wishlist: each is trivial alone, and together they are a dossier. Machines are built precisely to find those joins across millions of records at once.

This reframes a classic rule. “Don’t post anything sensitive” was always incomplete, because the sensitive thing is often emergent — it appears only when fragments combine. The discipline that replaces it is compartmentation: deliberately preventing your contexts from sharing linkable features. Different identities get different usernames, different writing registers, different devices and networks where it matters; metadata gets stripped before anything leaves your hands. When the state itself is the one compelling the data that later gets correlated, that is a related threat with its own playbook — When the Government Leaks Your Data.

Assumption 2 — You Expose More Than You Post
#

Inference is the second broken assumption: a model can deduce facts you never disclosed — your likely location, employer, health status, relationships, or sexual orientation — from patterns in what you did post. The old mental model was a ledger: your exposure equalled the sum of what you typed. Inference turns that ledger into a surface, where the negative space speaks too.

The mechanism is ordinary machine learning. Given enough examples, a model learns that people who write a certain way, follow certain accounts, and post at certain hours tend to share traits — and it applies that pattern to you. You did not state your city; your photo backdrops, your “good morning” timestamps, and the local slang you reuse imply it. This is why aggressive deletion can feel productive and change little: removing a single post rarely removes the pattern that lets the inference stand.

The lever is to manage the signal, not just the statement. Vary or blur the patterns an adversary would mine — posting times, location backdrops, the linguistic fingerprint that ties two identities together — and treat any data that reveals relationships and location as the highest-value target, because those are what inference compounds fastest. For most people the realistic goal is not to defeat inference but to raise its error rate enough that you are no longer the cheapest profile to build. A fuller dissection of how these inference chains run end to end is coming in a companion piece in this series.

Assumption 3 — Deletion No Longer Reaches the Data
#

Permanence is the third assumption AI breaks. Once your public text or image has been absorbed into a model’s training data, deleting the original does not remove what the model has already learned — there is no “delete” that reaches inside trained weights. The old promise was reversibility: a mistake could be unpublished. Against a model, publication is closer to a one-way door.

Public posts, captions, and images are collected into web-scale datasets — Common Crawl — the web-scale archive of the public internet that most major labs train on — is the best known — and used to train language and image models. The research field of machine unlearning, which tries to make a trained model forget specific data, treats the problem as genuinely hard and unsolved at scale; the only reliable remedy is retraining without the data, which owners almost never do for one person. And ingestion is not a harmless blur: security researchers have demonstrated that fragments of training data can be extracted back out of large models.

This is the dimension where the AI age meets the older problem of the permanent web most directly, so rather than repeat it, this is the hand-off: the full audit playbook for what survives deletion — backups, brokers, archives, and the training corpora — lives in How Permanent Is Your Social Media Footprint?. The threat-model consequence to carry forward is blunt: timing beats cleanup. Because ingestion is continuous, the only fully effective control is not publishing the sensitive thing in the first place. Every defense applied afterward is partial — and that single fact should reorder your priorities away from deletion tools and toward what you release at all.

Assumption 4 — Your Voice and Face Are Now Credentials
#

Synthetic identity is the fourth broken assumption: with a small sample of your voice, face, or writing, a model can generate convincing forgeries — and the same biometric features you treat as proof of “you” become raw material for impersonating you. The old assumption was that forging your identity required your participation or your secrets. It now requires only your published media.

A few seconds of clear audio is enough for voice cloning; a handful of photos is enough for a synthetic likeness; a corpus of your posts is enough to mimic your writing. This collapses a quiet protection most people relied on without noticing — that a familiar voice or face was self-authenticating. It is also not an evenly distributed risk. Impersonation, fabricated intimate imagery, and voice-based fraud fall disproportionately on women and on anyone with a motivated harasser, which makes this dimension a matter of bodily and reputational sovereignty, not merely data hygiene.

Two levers apply. The first is minimisation: limit the volume and clarity of raw biometric samples you publish — fewer high-fidelity voice clips, fewer face-forward photos tied to your legal name — accepting that this is mitigation, not a cure. The second is pre-registered trust: agree, in advance and out of band — over a separate channel an attacker cannot intercept — on a verification step with the people who matter — a shared word, a callback number, a second channel — so that a cloned voice on the phone cannot manufacture urgency. A dedicated treatment of voice- and face-as-credential, with the family-verification protocol in full, is coming in this series.

Rebuilding the Model — A Four-Dimension Checklist
#

Rebuilding your threat model for the AI age means re-asking the four classic OPSEC questions against a machine adversary, then re-deciding where your effort changes real exposure. You do not need to defend every dimension equally; you need to find which one is your weakest link and start there. In working through this frame ourselves, the dimension we see underestimated most is inference — people guard what they say and forget that the patterns around it speak just as loudly.

Walk your own situation through the four dimensions — in rough priority order for someone without a specific adversary:

Dimension	What the machine does	Your lever	Where to start
Permanence	Retains what you publish inside model weights	Publish less; treat the public version as undeletable	First — it is irreversible
Synthetic identity	Forges voice and face from small samples	Minimise raw samples; pre-register out-of-band verification	First — high personal harm
Correlation	Joins scattered fragments into one profile cheaply	Compartment: separate usernames, devices, stripped metadata	Next
Inference	Deduces unposted facts from your patterns	Manage the signal: blur location, routine, relationship cues	Ongoing

Order them against your own life, not this table — the point is to find your weakest link and act there first, not to defend all four equally.

A note on what not to over-invest in: regulation. The EU AI Act begins applying most of its provisions on 2 August 2026, but its most demanding obligations for high-risk systems were pushed back — under the May 2026 “Digital Omnibus” agreement — to December 2027 and August 2028. Data-protection regulators are engaging seriously; the European Data Protection Board’s Opinion 28/2024, adopted 18 December 2024, set out how GDPR principles apply to AI models, including when a model can be considered anonymous and what unlawfully-trained models risk. This is a live frontier worth tracking — and a poor thing to rely on. Your threat model has to hold in the years before the law catches up, which is exactly why it has to be yours.

“Privacy is necessary for an open society in the electronic age. … We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy out of their beneficence.” — Eric Hughes, A Cypherpunk’s Manifesto, 1993

That sentence was written about cryptography and email. It reads now as a description of the machine adversary: the tools changed, the principle did not. You build the model because no one builds it for you. Then you spend your effort where it moves your real exposure — and you keep the rest of the Privacy pillar close, because each dimension here has its own deeper map.

Bottom Line — Which Dimension Is Your Weakest Link?
#

The right level of AI-age OPSEC is the one that matches your threat model — which dimension is your weakest link depends entirely on who you are protecting yourself from.

If you are a general user with no specific adversary: the highest-leverage moves are permanence and synthetic identity — adopt a publishing pause, and cut your most identifiable raw voice and face samples. Skip the rest until you have a reason.
If you maintain separate identities — a pseudonymous creator, an activist, anyone whose contexts must not connect: correlation is your front line. Compartment ruthlessly; one reused username can undo everything else.
If you carry asymmetric risk — women facing harassment, survivors, public-facing professionals: prioritise synthetic identity and inference, and treat the out-of-band verification protocol as non-optional.

Across all four, the same truth holds that held in the human-adversary era — you cannot reliably delete your way to safety after the fact. You can only model the adversary you actually have, decide deliberately, and publish less of what you would not want a machine to keep.

Key Takeaways

AI-age OPSEC is threat-modeling against a machine adversary — one that correlates, infers, remembers, and synthesizes — rather than only a human one.
Correlation: a machine joins individually-harmless fragments (a reused handle, photo GPS metadata, posting cadence) into one profile; the lever is compartmentation, not silence.
Inference: models deduce unposted facts — location, relationships, employer — from patterns, so deleting one post rarely removes the pattern that exposes you.
Permanence: once absorbed into training data, content survives in model weights; machine unlearning is unsolved at scale, so timing beats cleanup.
Synthetic identity: seconds of voice or a few photos enable convincing forgeries — a gendered risk — so minimise raw samples and pre-register out-of-band verification.
Don’t wait for the law: the EU AI Act’s high-risk obligations were delayed to 2027–2028; your threat model has to hold in the meantime.

Frequently Asked Questions
#

What is AI-age OPSEC? AI-age OPSEC is operational security rebuilt for a machine adversary. Classic OPSEC modelled a human investigator with finite time; AI-age OPSEC models a system that correlates data at scale, infers what you never posted, retains what you publish inside model weights, and can synthesize your voice and face. In practice it means re-running the standard threat-model questions — what you protect, who wants it, what they can do — against those four capabilities.

Can AI really deanonymize me from “anonymous” data? Often, yes. Anonymity by omission — leaving your name off a post — is weak against inference and correlation, because a model can re-identify you from patterns and from joins across separate datasets. Strong unlinkability comes from compartmentation (separate usernames, devices, networks, and stripped metadata), not from simply withholding your name.

Does opting out of AI training actually help? Partly, and mostly going forward. Opt-outs and “do not train” signals can reduce future ingestion where platforms honour them, but they do not reach data already absorbed into trained models, and machine unlearning remains unsolved at scale. Treat opt-out as one prevention control among several, not as a delete button.

Will the EU AI Act protect me as an individual? Not soon, and not as a substitute for your own threat model. Most of the Act’s provisions apply from August 2026, but its strictest high-risk obligations were deferred to December 2027 and August 2028 under the May 2026 Digital Omnibus agreement. Regulation is a slow, uneven backstop; the controls in this article are what you hold in the meantime.

#	Source	URL	Archive
1	Pew Research Center — “What the data says about Americans’ views of AI” (Mar 2026)	https://www.pewresearch.org/short-reads/2026/03/12/key-findings-about-how-americans-view-artificial-intelligence/	https://web.archive.org/web/*/https://www.pewresearch.org/short-reads/2026/03/12/key-findings-about-how-americans-view-artificial-intelligence/
2	Pew Research Center — “How Americans View Data Privacy” (Oct 2023)	https://www.pewresearch.org/internet/2023/10/18/how-americans-view-data-privacy/	https://web.archive.org/web/*/https://www.pewresearch.org/internet/2023/10/18/how-americans-view-data-privacy/
3	EU Artificial Intelligence Act — Implementation Timeline	https://artificialintelligenceact.eu/implementation-timeline/	https://web.archive.org/web/*/https://artificialintelligenceact.eu/implementation-timeline/
4	EDPB — Opinion 28/2024 on AI models and GDPR (18 Dec 2024)	https://www.edpb.europa.eu/news/news/2024/edpb-opinion-ai-models-gdpr-principles-support-responsible-ai_en	https://web.archive.org/web/*/https://www.edpb.europa.eu/news/news/2024/edpb-opinion-ai-models-gdpr-principles-support-responsible-ai_en
5	Carlini et al. — “Extracting Training Data from Large Language Models” (USENIX Security 2021)	https://arxiv.org/abs/2012.07805	https://web.archive.org/web/*/https://arxiv.org/abs/2012.07805

Claude (Anthropic) — Identity & Data-Handling Facts

Tue, 14 Jul 2026 00:00:00 +0000

Disclosures: nature of this page · affiliations · corrections

This page is a factual record — not advice, not a recommendation, not a solicitation, not an endorsement. Inclusion is not approval. Policies change; check the provider's primary documents before you rely on any value.
We currently have no affiliate relationship with any listed service. If that ever changes, we will disclose it inline, it will not affect what is listed or how it is ordered, and the change will be recorded here.
Listed provider and believe a value is wrong? If our review confirms an error, we correct it and record the correction publicly — write to editor@cypherpunkguide.com
How this data is collected and checked (methodology)

Pilot record status

Names: Claude · Claude.ai
Provider: Anthropic (direct chat provider)
Recorded dimensions: 8 of 17 dimensions have at least one scoped record
Claim sources: 8 provider-stated · 0 interface-observed

No current scoped record in this pilot:

Signup identifiers
Payment and billing identity
Inputs sent to downstream providers
Human review of chats
Retention
Optional privacy controls
Data controller's stated jurisdiction
Third-party site analytics
Metadata collected (including IP)

Account required

conditional

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: mandatory
Account verification method: email confirmation
Triggered by: upgrading to a paid plan
Linked to: your account
Received by: Anthropic (Claude)
Applies to: Region: global default · Plan: free/paid · Platform: web/API
First recorded by KYC Drift: 2026-07-13

To access our Services, we may ask you to create an Account.

— archived copy · captured 2026-07-13

you must sign up for a subscription with us (a “ Subscription ”), first by creating an Account

— archived copy · captured 2026-07-13

Sign-in methods (SSO/wallet)

Google SSO or email magic-link

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Linked to: your account · third party
Received by: Anthropic (Claude) · Google
Applies to: Region: global default · Plan: free/paid · Platform: web/desktop/mobile
Document date: 2026-05-19 (document states last updated)
First recorded by KYC Drift: 2026-07-13

you will see two different options for logging in to your Claude account. Continue with Google ... Continue with email

— archived copy · captured 2026-07-10

Phone at signup

required

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: mandatory
Account verification method: SMS one-time code
Restrictions: VoIP numbers rejected · Google Voice rejected · app-generated numbers rejected · landlines rejected · supported locations only · one account per number
Linked to: your account
Received by: Anthropic (Claude)
Applies to: Region: supported locations · Plan: free/paid · Platform: web/desktop/mobile · Signup path: Google SSO/email
Document date: 2026-05-19 (document states last updated)
First recorded by KYC Drift: 2026-07-13

We require phone verification for all new users, and there isn't a way to skip this step.

— archived copy · captured 2026-07-13

you'll be asked to enter your phone number from a supported location to receive a verification code via text message

— archived copy · captured 2026-07-13

you cannot use VoIP numbers, Google Voice, phone numbers created using apps, landlines, or other numbers that can't receive texts to verify your account.

— archived copy · captured 2026-07-13

Email at signup

conditional

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: may collect (policy wording)
Triggered by: choosing the email signup path (Google SSO is the alternative)
Linked to: your account
Received by: Anthropic (Claude)
Applies to: Region: supported locations · Plan: free/paid · Platform: web/API
First recorded by KYC Drift: 2026-07-13

Anthropic collects identifiers, including your name, email address, and phone number when you sign up for an Anthropic account

— archived copy · captured 2026-07-13

Minimum age

18+

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Linked to: your account
Received by: Anthropic (Claude)
Applies to: Region: global default · Plan: free/paid · Platform: web/API
First recorded by KYC Drift: 2026-07-13

You must be at least 18 years old or the minimum age required to consent to use the Services in your location, whichever is higher.

— archived copy · captured 2026-07-13

Continued use

Later identity or phone checks

conditional

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: may collect (policy wording)
Account verification method: government ID or age proof
Triggered by: provider's discretion ('in certain circumstances')
Linked to: your account
Received by: Anthropic (Claude)
Applies to: Region: global default · Plan: free/paid · Platform: web/API
First recorded by KYC Drift: 2026-07-13

Verification Data: In certain circumstances, we may ask you to verify your age or identity.

— archived copy · captured 2026-07-13

Inputs used for training

on by default; opt-out available

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: mandatory
Linked to: your account
Received by: Anthropic (Claude)
Applies to: Region: global default · Plan: free/paid · Platform: web
First recorded by KYC Drift: 2026-07-13

We may use your Inputs and Outputs to train and improve Anthropic AI models, unless you opt out through your account settings.

— archived copy · captured 2026-07-13

Deletion

Deletion and identifier reuse

available

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Linked to: your account
Received by: Anthropic (Claude)
Applies to: Region: global default · Plan: free/paid · Platform: web
First recorded by KYC Drift: 2026-07-13

You also are able to delete individual conversations, which will be removed immediately from your conversation history and automatically deleted from our back-end within 30 days.

— archived copy · captured 2026-07-13

Evidence

The table separates the source capture from the latest supporting re-check in each immutable evidence stream. Document sha256 values fingerprint retained decoded bodies; interface-run digests fingerprint reviewed, redacted artifacts. A digest detects change but does not itself timestamp the bytes.

Evidence role	Source	Archive or result	Captured or observed	recorded / content checked	sha256
source capture · latest supporting re-check	https://www.anthropic.com/legal/consumer-terms	archived copy	2026-07-13	2026-07-13	`731724432cfff0c19f2b8a2da4610f0107442a100d35c405a2d88ff4bcff1070`
source capture · latest supporting re-check	https://support.claude.com/en/articles/13189465-log-in-to-your-claude-account	archived copy	2026-07-10	2026-07-13	`2493243a906bbc42a13cb20a5767449b03f2a9462cdeb5eecb8532269f8059cb`
source capture · latest supporting re-check	https://support.claude.com/en/articles/8287232-verify-your-phone-number	archived copy	2026-07-13	2026-07-13	`c789de708f21e72e768e9eda79de4bd3374e6dca0690b6ccf91148f93f48177c`
source capture · latest supporting re-check	https://www.anthropic.com/legal/privacy	archived copy	2026-07-13	2026-07-13	`a2fdc63d6bb693e172a803a2da85dbad2619d4022265cdb2cb0f2f2afb476168`

DeepSeek — Identity & Data-Handling Facts

Tue, 14 Jul 2026 00:00:00 +0000

Disclosures: nature of this page · affiliations · corrections

This page is a factual record — not advice, not a recommendation, not a solicitation, not an endorsement. Inclusion is not approval. Policies change; check the provider's primary documents before you rely on any value.
We currently have no affiliate relationship with any listed service. If that ever changes, we will disclose it inline, it will not affect what is listed or how it is ordered, and the change will be recorded here.
Listed provider and believe a value is wrong? If our review confirms an error, we correct it and record the correction publicly — write to editor@cypherpunkguide.com
How this data is collected and checked (methodology)

Pilot record status

Names: DeepSeek · DeepSeek Chat
Provider: DeepSeek (direct chat provider)
Recorded dimensions: 6 of 17 dimensions have at least one scoped record
Claim sources: 4 provider-stated · 0 interface-observed

No current scoped record in this pilot:

Account required
Sign-in methods (SSO/wallet)
Minimum age
Later identity or phone checks
Payment and billing identity
Inputs sent to downstream providers
Human review of chats
Retention
Optional privacy controls
Third-party site analytics
Metadata collected (including IP)

Signup identifiers

email or phone

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: mandatory
Account verification method: varies by path
Linked to: your account
Received by: DeepSeek (China)
Applies to: Region: global default · Plan: free/paid · Platform: web
First recorded by KYC Drift: 2026-07-14

We collect Personal Data that you provide when you set up an account, such as your date of birth (where applicable), username (where applicable), email address and/or telephone number, and password.

— archived copy · captured 2026-07-14

Continued use

Data controller's stated jurisdiction

China (CN)

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Linked to: your account · parent-company profile
Received by: DeepSeek (China)
Applies to: Region: global default · Plan: free/paid · Platform: web
First recorded by KYC Drift: 2026-07-14

The Services are provided and controlled by Hangzhou DeepSeek Artificial Intelligence Co., Ltd., with its registered address in China (“we” or “us”).

— archived copy · captured 2026-07-14

Inputs used for training

on by default; no stated opt-out

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: mandatory
Linked to: your account
Received by: DeepSeek (China)
Applies to: Region: global default · Plan: free/paid · Platform: web
First recorded by KYC Drift: 2026-07-14

To improve and develop the Services and to train and improve our technology, such as our machine learning models and algorithms.

— archived copy · captured 2026-07-14

Deletion

Deletion and identifier reuse

available

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Linked to: your account
Received by: DeepSeek (China)
Applies to: Region: global default · Plan: free/paid · Platform: web
First recorded by KYC Drift: 2026-07-14

you may also copy or delete your chat history via your settings.

— archived copy · captured 2026-07-14

Evidence

Evidence role	Source	Archive or result	Captured or observed	recorded / content checked	sha256
source capture · latest supporting re-check	https://cdn.deepseek.com/policies/en-US/deepseek-privacy-policy.html	archived copy	2026-07-14	2026-07-14	`339984e36a795843ee2b5b917797072ec249f3c0e9ff7cbbfe754c01caa4f069`

Gemini (Google) — Identity & Data-Handling Facts

Tue, 14 Jul 2026 00:00:00 +0000

Disclosures: nature of this page · affiliations · corrections

This page is a factual record — not advice, not a recommendation, not a solicitation, not an endorsement. Inclusion is not approval. Policies change; check the provider's primary documents before you rely on any value.
We currently have no affiliate relationship with any listed service. If that ever changes, we will disclose it inline, it will not affect what is listed or how it is ordered, and the change will be recorded here.
Listed provider and believe a value is wrong? If our review confirms an error, we correct it and record the correction publicly — write to editor@cypherpunkguide.com
How this data is collected and checked (methodology)

Pilot record status

Names: Gemini · Google Gemini
Provider: Google (direct chat provider)
Recorded dimensions: 6 of 17 dimensions have at least one scoped record
Claim sources: 6 provider-stated · 0 interface-observed

No current scoped record in this pilot:

Phone at signup
Email at signup
Sign-in methods (SSO/wallet)
Minimum age
Later identity or phone checks
Payment and billing identity
Inputs sent to downstream providers
Inputs used for training
Deletion and identifier reuse
Data controller's stated jurisdiction
Third-party site analytics

Account required

conditional

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: mandatory
Account verification method: password
Triggered by: signed-in use
Linked to: your account · parent-company profile
Received by: Google
Applies to: Region: global default · Plan: free/paid · Platform: web/app
Document date: 2026-06-29 (document states last updated)
First recorded by KYC Drift: 2026-07-13

When you're signed in, we also collect information that we store with your Google Account, which we treat as personal information.

— archived copy · captured 2026-07-13

When you use Gemini Apps while signed out, Google processes your data (like your IP address and browser type) per the Google Privacy Policy .

— archived copy · captured 2026-07-13

Signup identifiers

required

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: mandatory
Linked to: your account · parent-company profile
Received by: Google
Applies to: Region: global default · Plan: free/paid · Platform: web/app
First recorded by KYC Drift: 2026-07-13

When you create a Google Account, you provide us with personal information that includes your name and a password.

— archived copy · captured 2026-07-13

Continued use

Human review of chats

yes

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: mandatory
Linked to: your account · third party
Received by: Google · service providers
Applies to: Region: global default · Plan: free/paid · Platform: web/app
Document date: 2026-06-29 (document states last updated)
First recorded by KYC Drift: 2026-07-13

Human reviewers (including trained reviewers from our service providers) review some of the data we collect for these purposes.

— archived copy · captured 2026-07-13

Optional privacy controls

available

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Linked to: your account
Received by: Google
Applies to: Region: global default · Plan: free/paid · Platform: web/app
Document date: 2026-06-29 (document states last updated)
First recorded by KYC Drift: 2026-07-13

You can also use temporary chats, which are not used to improve Google AI with help from human reviewers.

— archived copy · captured 2026-07-13

Metadata collected (including IP)

collected

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: collected automatically
Linked to: your account · device
Received by: Google
Applies to: Region: global default · Plan: free/paid · Platform: web/app
Document date: 2026-06-29 (document states last updated)
First recorded by KYC Drift: 2026-07-13

Location information: the general area from your device, IP address, or Home or Work addresses in your Google Account.

— archived copy · captured 2026-07-13

Deletion

Retention

up to 3 years

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Triggered by: conversation picked for human review
Linked to: your account
Received by: Google
Applies to: Region: global default · Plan: free/paid · Platform: web/app
Document date: 2026-06-29 (document states last updated)
First recorded by KYC Drift: 2026-07-13

Instead, they are retained for up to three years.

— archived copy · captured 2026-07-13

Evidence

Evidence role	Source	Archive or result	Captured or observed	recorded / content checked	sha256
source capture · latest supporting re-check	https://policies.google.com/privacy	archived copy	2026-07-13	2026-07-13	`35a5f8416bb2ab8ddfe15523696989dc57cb1763050e00d3df2cb4c822da262f`
source capture · latest supporting re-check	https://support.google.com/gemini/answer/13594961	archived copy	2026-07-13	2026-07-13	`df5172a0969cda86258428f0bc7b82af2ba267ca1b895225185a03616e592b9a`

Le Chat (Mistral AI) — Identity & Data-Handling Facts

Tue, 14 Jul 2026 00:00:00 +0000

Disclosures: nature of this page · affiliations · corrections

This page is a factual record — not advice, not a recommendation, not a solicitation, not an endorsement. Inclusion is not approval. Policies change; check the provider's primary documents before you rely on any value.
We currently have no affiliate relationship with any listed service. If that ever changes, we will disclose it inline, it will not affect what is listed or how it is ordered, and the change will be recorded here.
Listed provider and believe a value is wrong? If our review confirms an error, we correct it and record the correction publicly — write to editor@cypherpunkguide.com
How this data is collected and checked (methodology)

Pilot record status

Names: Le Chat · Mistral
Provider: Mistral AI (direct chat provider)
Recorded dimensions: 9 of 17 dimensions have at least one scoped record
Claim sources: 9 provider-stated · 0 interface-observed

No current scoped record in this pilot:

Signup identifiers
Sign-in methods (SSO/wallet)
Later identity or phone checks
Payment and billing identity
Inputs sent to downstream providers
Human review of chats
Third-party site analytics
Metadata collected (including IP)

Account required

conditional

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: mandatory
Triggered by: varies by product (some products require an account)
Linked to: your account
Received by: Mistral AI (France)
Applies to: Region: global default · Plan: free/paid · Platform: web/app
Effective date: 2026-05-28 (document states effective)
First recorded by KYC Drift: 2026-07-14

Some Mistral AI Products require a Mistral AI account.

— archived copy · captured 2026-07-14

Email at signup

collected

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: collected
Linked to: your account
Received by: Mistral AI (France)
Applies to: Region: global default · Plan: free/paid · Platform: web/app
Effective date: 2026-04-08 (document states effective)
First recorded by KYC Drift: 2026-07-14

Contact Data, such as your email address.

— archived copy · captured 2026-07-14

When you create your Mistral AI Account and subscribe to a Mistral AI Product.

— archived copy · captured 2026-07-14

Phone at signup

collected if you provide it

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: may collect (policy wording)
Linked to: your account
Received by: Mistral AI (France)
Applies to: Region: global default · Plan: free/paid · Platform: web/app
Effective date: 2026-04-08 (document states effective)
First recorded by KYC Drift: 2026-07-14

Account Data (such as the phone number or email address you provided to verify or change your account password, etc.):

— archived copy · captured 2026-07-14

Minimum age

13+

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Linked to: your account
Received by: Mistral AI (France)
Applies to: Region: global default · Plan: free/paid · Platform: web/app
Effective date: 2026-05-28 (document states effective)
First recorded by KYC Drift: 2026-07-14

You must be at least thirteen (13) years old to use the Mistral AI Products

— archived copy · captured 2026-07-14

Continued use

Data controller's stated jurisdiction

France (FR)

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Linked to: your account · parent-company profile
Received by: Mistral AI (France)
Applies to: Region: global default · Plan: free/paid · Platform: web/app
Effective date: 2026-04-08 (document states effective)
First recorded by KYC Drift: 2026-07-14

Mistral AI is a French company incorporated in Paris, under number 952 418 325, having its registered offices at 15 rue des Halles, 75001 Paris

— archived copy · captured 2026-07-14

Mistral AI is the data controller.

— archived copy · captured 2026-07-14

Inputs used for training

on by default; opt-out available

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: mandatory
Linked to: your account
Received by: Mistral AI (France)
Applies to: Region: global default · Plan: free · Platform: web/app
Effective date: 2026-05-28 (document states effective)
First recorded by KYC Drift: 2026-07-14

We do not use Your Data to train our artificial intelligence models except (a) when you (i) use Mistral AI Products under a free subscription, or are subscribed to Vibe Pro or Vibe Student, and (ii) you have not opted-out of training,

— archived copy · captured 2026-07-14

We’ve introduced a user control which allows you to object to the use of your input and output data for model training directly from your account.

— archived copy · captured 2026-07-14

Please note that we do not use your Input and Output to train our artificial intelligence models when you use Le Chat Enterprise or the paid version of our APIs.

— archived copy · captured 2026-07-14

Retention

until you delete it

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Linked to: your account
Received by: Mistral AI (France)
Applies to: Region: global default · Plan: free/paid · Platform: web/app
Effective date: 2026-04-08 (document states effective)
First recorded by KYC Drift: 2026-07-14

we keep your Input and Output until you delete your account or until you delete the conversation from Le Chat.

— archived copy · captured 2026-07-14

Optional privacy controls

available

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Linked to: your account
Received by: Mistral AI (France)
Applies to: Region: global default · Plan: free/paid · Platform: web/app
Effective date: 2026-04-08 (document states effective)
First recorded by KYC Drift: 2026-07-14

Turn off Memories at all times through your settings.

— archived copy · captured 2026-07-14

Deletion

Deletion and identifier reuse

available

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Linked to: your account
Received by: Mistral AI (France)
Applies to: Region: global default · Plan: free/paid · Platform: web/app
Effective date: 2026-04-08 (document states effective)
First recorded by KYC Drift: 2026-07-14

for 1 year after you delete your account.

— archived copy · captured 2026-07-14

Your Civil Identity Data (your first and last name, etc.): for 5 years after the termination of your Mistral AI account.

— archived copy · captured 2026-07-14

Evidence

Evidence role	Source	Archive or result	Captured or observed	recorded / content checked	sha256
source capture · latest supporting re-check	https://legal.mistral.ai/terms/privacy-policy	archived copy	2026-07-14	2026-07-14	`a8406676deefa30f582c624c559d97645502eca7f1d9b4ac6d0db755510a55ab`
source capture · latest supporting re-check	https://legal.mistral.ai/terms/eu-consumers-terms-of-service	archived copy	2026-07-14	2026-07-14	`b01bd5bb70e7199f54dc6f6f9365b3bef8c26b55f4e1d2355e1de1dc87d336a9`

ChatGPT (OpenAI) — Identity & Data-Handling Facts

Tue, 14 Jul 2026 00:00:00 +0000

Disclosures: nature of this page · affiliations · corrections

This page is a factual record — not advice, not a recommendation, not a solicitation, not an endorsement. Inclusion is not approval. Policies change; check the provider's primary documents before you rely on any value.
We currently have no affiliate relationship with any listed service. If that ever changes, we will disclose it inline, it will not affect what is listed or how it is ordered, and the change will be recorded here.
Listed provider and believe a value is wrong? If our review confirms an error, we correct it and record the correction publicly — write to editor@cypherpunkguide.com
How this data is collected and checked (methodology)

Pilot record status

Names: ChatGPT
Provider: OpenAI (direct chat provider)
Recorded dimensions: 3 of 17 dimensions have at least one scoped record
Claim sources: 4 provider-stated · 0 interface-observed

No current scoped record in this pilot:

Account required
Signup identifiers
Phone at signup
Email at signup
Sign-in methods (SSO/wallet)
Minimum age
Later identity or phone checks
Inputs sent to downstream providers
Human review of chats
Retention
Optional privacy controls
Data controller's stated jurisdiction
Third-party site analytics
Metadata collected (including IP)

Continued use

Inputs used for training

on by default; opt-out available

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: mandatory
Linked to: your account
Received by: OpenAI (ChatGPT)
Applies to: Region: global default · Plan: free/paid · Platform: web
First recorded by KYC Drift: 2026-07-13

we may use Content you provide us to improve our Services, for example to train the models that power ChatGPT.

— archived copy · captured 2026-07-11

Read our instructions on how you can opt out of our use of your Content to train our models.

— archived copy · captured 2026-07-11

Payment

Payment and billing identity

required

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: mandatory
Account verification method: email confirmation
Triggered by: upgrading to a paid plan
Linked to: your account · billing identity
Received by: OpenAI (ChatGPT)
Applies to: Region: global default · Plan: paid · Platform: web
First recorded by KYC Drift: 2026-07-13

To upgrade to Plus/Pro/Teams, a user will still be required to verify an email.

— archived copy · captured 2026-07-13

Deletion

Deletion and identifier reuse

reusable after deletion

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Linked to: your account
Received by: OpenAI (ChatGPT)
Applies to: Region: global default · Plan: free/paid · Platform: web
First recorded by KYC Drift: 2026-07-13

With some exceptions, we do allow consumers who have deleted their ChatGPT account to re-register using the same phone number.

— archived copy · captured 2026-07-13

Deletion and identifier reuse

available

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Linked to: your account
Received by: OpenAI (ChatGPT)
Applies to: Region: global default · Plan: free/paid · Platform: web
First recorded by KYC Drift: 2026-07-13

Once you choose to delete Personal Data, we will remove it from our systems within 30 days

— archived copy · captured 2026-07-11

Evidence

Evidence role	Source	Archive or result	Captured or observed	recorded / content checked	sha256
source capture · latest supporting re-check	https://help.openai.com/en/articles/10388702-phone-only-signups	archived copy	2026-07-13	2026-07-13	`cd6eac339eb7e485a952b5c50c5c63209b6f440c12ff0ed24e1cb48b24862ceb`
source capture · latest supporting re-check	https://openai.com/policies/row-privacy-policy/	archived copy	2026-07-11	2026-07-13	`8f30b38251d856ce871031eb507aaa551f632c47ee1579c773a1ca50505721ca`

OpenRouter — Identity & Data-Handling Facts

Tue, 14 Jul 2026 00:00:00 +0000

Disclosures: nature of this page · affiliations · corrections

This page is a factual record — not advice, not a recommendation, not a solicitation, not an endorsement. Inclusion is not approval. Policies change; check the provider's primary documents before you rely on any value.
We currently have no affiliate relationship with any listed service. If that ever changes, we will disclose it inline, it will not affect what is listed or how it is ordered, and the change will be recorded here.
Listed provider and believe a value is wrong? If our review confirms an error, we correct it and record the correction publicly — write to editor@cypherpunkguide.com
How this data is collected and checked (methodology)

Pilot record status

Names: OpenRouter
Provider: OpenRouter (router / aggregator)
Recorded dimensions: 6 of 17 dimensions have at least one scoped record
Claim sources: 6 provider-stated · 0 interface-observed

No current scoped record in this pilot:

Signup identifiers
Phone at signup
Sign-in methods (SSO/wallet)
Minimum age
Later identity or phone checks
Human review of chats
Retention
Deletion and identifier reuse
Optional privacy controls
Data controller's stated jurisdiction
Metadata collected (including IP)

Account required

required

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: mandatory
Account verification method: password
Linked to: your account · third-party auth platform
Received by: OpenRouter · authentication platform
Applies to: Region: global default · Plan: free/paid · Platform: web/API
First recorded by KYC Drift: 2026-07-13

To access most features of the Service, you must register for an account.

— archived copy · captured 2026-07-13

Email at signup

conditional

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: may collect (policy wording)
Linked to: your account · third-party auth platform
Received by: OpenRouter · authentication platform
Applies to: Region: global default · Plan: free/paid · Platform: web/API
First recorded by KYC Drift: 2026-07-13

you may be required to provide us or our authentication platform with some information about yourself, such as your email address or other contact information.

— archived copy · captured 2026-07-13

Continued use

Inputs sent to downstream providers

sent to downstream provider

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: mandatory
Linked to: downstream model provider
Received by: selected model provider
Applies to: Region: global default · Plan: free/paid · Platform: web/API
First recorded by KYC Drift: 2026-07-13

When you submit Inputs through the Service, those Inputs are transmitted to the Model Provider you select, or that is selected through automatic routing, as applicable.

— archived copy · captured 2026-07-13

Third-party site analytics

present

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: collected automatically
Linked to: third party
Received by: Google Analytics
Applies to: Region: global default · Plan: free/paid · Platform: web
First recorded by KYC Drift: 2026-07-13

Presently, we use Google Analytics.

— archived copy · captured 2026-07-13

Inputs used for training

varies by downstream provider — selectable

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Linked to: downstream model provider
Received by: selected model provider
Applies to: Region: global default · Plan: free/paid · Platform: web/API
First recorded by KYC Drift: 2026-07-14

Different Model Providers have different data practices, including with respect to whether they retain or use your Inputs and Outputs to train, fine-tune, evaluate, or improve their Models.

— archived copy · captured 2026-07-13

If you do not want your Inputs used for model training, select a Model or Model Provider that commits to not using your data for that purpose.

— archived copy · captured 2026-07-13

Payment

Payment and billing identity

cryptocurrency accepted

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-13 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Linked to: billing identity
Received by: OpenRouter
Applies to: Region: global default · Plan: paid · Platform: web/API
First recorded by KYC Drift: 2026-07-13

Cryptocurrency payments are never refundable.

— archived copy · captured 2026-07-13

Evidence

Evidence role	Source	Archive or result	Captured or observed	recorded / content checked	sha256
source capture · latest supporting re-check	https://openrouter.ai/terms	archived copy	2026-07-13	2026-07-13	`d264e051a102a9671dab6759d6235011403a199d9a33f494e5d4592698756dd8`
source capture · latest supporting re-check	https://openrouter.ai/privacy	archived copy	2026-07-13	2026-07-13	`2b67c33c413db66aa2b4fc37b1cf13d021496acc0716cc3a89bd397163b17d67`

Perplexity — Identity & Data-Handling Facts

Tue, 14 Jul 2026 00:00:00 +0000

Disclosures: nature of this page · affiliations · corrections

This page is a factual record — not advice, not a recommendation, not a solicitation, not an endorsement. Inclusion is not approval. Policies change; check the provider's primary documents before you rely on any value.
We currently have no affiliate relationship with any listed service. If that ever changes, we will disclose it inline, it will not affect what is listed or how it is ordered, and the change will be recorded here.
Listed provider and believe a value is wrong? If our review confirms an error, we correct it and record the correction publicly — write to editor@cypherpunkguide.com
How this data is collected and checked (methodology)

Pilot record status

Names: Perplexity · Perplexity AI
Provider: Perplexity (search AI)
Recorded dimensions: 2 of 17 dimensions have at least one scoped record
Claim sources: 2 provider-stated · 0 interface-observed

No current scoped record in this pilot:

Account required
Phone at signup
Email at signup
Sign-in methods (SSO/wallet)
Minimum age
Later identity or phone checks
Payment and billing identity
Inputs sent to downstream providers
Human review of chats
Retention
Deletion and identifier reuse
Optional privacy controls
Data controller's stated jurisdiction
Third-party site analytics
Metadata collected (including IP)

Signup identifiers

required

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: mandatory
Linked to: your account · device
Received by: Perplexity
Applies to: Region: global default · Plan: free/paid · Platform: web
First recorded by KYC Drift: 2026-07-14

Account Registration When you make an account, we collect your name, contact information, username and password, and, in some instances, device and network identifiers

— archived copy · captured 2026-07-06

Continued use

Inputs used for training

email content excluded

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Linked to: your account
Received by: Perplexity
Applies to: Region: global default · Plan: free/paid · Platform: web
First recorded by KYC Drift: 2026-07-14

We do not use the content of emails to create, train, improve, or fine-tune AI models.

— archived copy · captured 2026-07-06

Evidence

Evidence role	Source	Archive or result	Captured or observed	recorded / content checked	sha256
source capture · latest supporting re-check	https://www.perplexity.ai/hub/legal/privacy-policy	archived copy	2026-07-06	2026-07-14	`3a3038bcfab1f5536754352156df2ae1dadf135b276afa31995003c573b241ee`

Venice — Identity & Data-Handling Facts

Tue, 14 Jul 2026 00:00:00 +0000

Disclosures: nature of this page · affiliations · corrections

This page is a factual record — not advice, not a recommendation, not a solicitation, not an endorsement. Inclusion is not approval. Policies change; check the provider's primary documents before you rely on any value.
We currently have no affiliate relationship with any listed service. If that ever changes, we will disclose it inline, it will not affect what is listed or how it is ordered, and the change will be recorded here.
Listed provider and believe a value is wrong? If our review confirms an error, we correct it and record the correction publicly — write to editor@cypherpunkguide.com
How this data is collected and checked (methodology)

Pilot record status

Names: Venice · Venice.ai
Provider: Venice (router / aggregator)
Recorded dimensions: 5 of 17 dimensions have at least one scoped record
Claim sources: 5 provider-stated · 0 interface-observed

No current scoped record in this pilot:

Signup identifiers
Phone at signup
Email at signup
Minimum age
Later identity or phone checks
Payment and billing identity
Inputs used for training
Human review of chats
Deletion and identifier reuse
Optional privacy controls
Data controller's stated jurisdiction
Third-party site analytics

Account required

optional

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: not collected
Linked to: session only
Received by: Venice
Applies to: Region: global default · Plan: demo · Platform: web
First recorded by KYC Drift: 2026-07-14

The Venice.ai Website features a chat demonstration interface which is accessible to anyone without an account.

— archived copy · captured 2026-07-14

Sign-in methods (SSO/wallet)

email, social login, or Web3 wallet

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: mandatory
Account verification method: varies by path
Triggered by: creating an account (the demo needs none)
Linked to: your account
Received by: Venice
Applies to: Region: global default · Plan: free/paid · Platform: web
First recorded by KYC Drift: 2026-07-14

registering for an Account using a social login feature such as Google, Facebook, Apple, Discord, Coinbase, or a Web3 wallet

— archived copy · captured 2026-07-14

You must provide an email address to register for an account (“Account”) (either Free or Pro, as further described below) to use our Services.

— archived copy · captured 2026-07-14

Continued use

Inputs sent to downstream providers

zero data retention (imposed downstream)

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Linked to: downstream model provider
Received by: model providers
Applies to: Region: global default · Plan: free/paid/demo · Platform: web
First recorded by KYC Drift: 2026-07-14

We operate a zero data retention policy with our model providers in which our model providers are prohibited from storing, retaining, or using any of your Prompts or Outputs beyond the time strictly necessary to process and return a response.

— archived copy · captured 2026-07-14

Metadata collected (including IP)

collected

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: collected automatically
Linked to: session only · device
Received by: Venice
Applies to: Region: global default · Plan: demo · Platform: web
First recorded by KYC Drift: 2026-07-14

Without an account, we collect basic metadata on you, such as time zone, browser type, and IP address.

— archived copy · captured 2026-07-14

Retention

not retained

Claim source: provider-stated
Archive integrity: archived & content checked
Enforcement: untested — a published policy is not proof of system behavior
claim checked through: 2026-07-14 · monthly re-check target; monitoring pipeline not yet operating
Source conflict: no conflict recorded in the current evidence set
Collection: not collected
Linked to: session only
Received by: Venice
Applies to: Region: global default · Plan: free/paid/demo · Platform: web
First recorded by KYC Drift: 2026-07-14

We do not collect or retain your Prompts or Outputs (other than as described in the Prompts and Outputs section above).

— archived copy · captured 2026-07-14

Evidence

Evidence role	Source	Archive or result	Captured or observed	recorded / content checked	sha256
source capture · latest supporting re-check	https://venice.ai/legal/tos	archived copy	2026-07-14	2026-07-14	`a23fcfd349c1e26ce53bd2f017eb6f8fcbb6f65bbbd5d88ffcd5d54426df7e98`
source capture · latest supporting re-check	https://venice.ai/legal/privacy-policy	archived copy	2026-07-14	2026-07-14	`b4ee97bcc08f31b872ef5ac40dec1eef70f83cc34ea12827728f3771f8a33b90`

Hal Finney: PGP, RPOW, and Early Bitcoin (2026)

Tue, 18 Aug 2026 00:00:00 +0000

A note on funding: CypherpunkGuide carries no surveillance advertising—no ad networks, tracking pixels, or sponsored content. It is funded by transparent streams: reader donations now; subscription and editorially-aligned affiliate later. We answer to our readers, not to advertisers.

Hal Finney is often compressed into two lines: the man who received the first Bitcoin transaction, and perhaps the man behind Satoshi Nakamoto. Both frames hide the work that can actually be documented. The first is imprecise unless we define which kind of transaction we mean. The second is speculation, not an explanation of Finney’s contribution.

Pretty Good Privacy (PGP) was encryption software for protecting messages. An anonymous remailer was a forwarding service designed to obscure who sent a message or where it went. Reusable Proofs of Work (RPOW) was Finney’s server-based experiment for transferring tokens backed by computational work.

I mapped 12 pivotal primary records spanning 1992 to 2013: a PGP 2.0 manual, Cypherpunks posts, RPOW documentation, pre-release Bitcoin discussion, a public run statement, block 170, and Finney’s own retrospective. I classified what each record proves and cannot prove. The source-bound evidence map is schema-validated by a deterministic checker; the References add four contextual documents outside that mapped set.

The result is neither a saint’s life nor a Satoshi hunt. It is a narrower and more useful account of how one programmer repeatedly moved from an abstract privacy problem to a running system—and where each system still required trust.

What Did Hal Finney Actually Build Before Bitcoin?
#

Before Bitcoin, Hal Finney helped program PGP 2.0, operated anonymous remailers, and built RPOW, a working proof-of-work token system with an attested central server. In 2008–2009, he became an early Bitcoin reviewer and tester.

Proof of work is a computational cost that others can cheaply verify. An attested server uses a signed hardware report to show which software it is running. The documented bridge is a continuity of practice across encrypted communication, anonymous communication, private payments, reusable work, and decentralized transaction history.

The wording matters. Finney did not create PGP; Philip Zimmermann did, and the PGP 2.6.2 User’s Guide credits Finney among several contributors for PGP 2.0 work. RPOW did not achieve Bitcoin’s decentralized consensus; it depended on a dedicated server and IBM hardware. Finney did not claim certainty that he was the first person after Satoshi to run Bitcoin; four years later he wrote, “I think I was.”

The evidence supports a builder who tested the boundary between trust and verification. It does not support a lone-inventor myth.

The Evidence Ladder: What Each Record Can Prove
#

Finney’s record is strongest when dated documents, operational notes, public chain data, and later testimony remain separate evidence classes. One record can establish an event without proving every identity or cause later attached to it.

I used four levels rather than treating every link as equivalent:

Contemporaneous artifact: a dated manual, mailing-list post, release message, or public statement created near the event.
Operational documentation: source and security notes explaining how a system was meant to work and fail.
Public system record: chain data that can be independently re-read, while recognizing that a public key is not a human name.
Firsthand retrospective: Finney’s own later account, valuable but not interchangeable with a live log.

Record	What it proves	What it cannot prove
PGP 2.0 manual	Finney was a credited programmer	He created PGP or wrote it alone
1992 remailer post	He participated early and framed a practical privacy layer	He founded Cypherpunks
RPOW announcement and code	A transferable proof-of-work experiment ran	Decentralized consensus or direct influence on Bitcoin
2008 Bitcoin replies	He engaged the design before release	Bitcoin co-authorship
“Running bitcoin”	He publicly said he was running the client	A complete census showing exactly two nodes
Block 170	The earliest recorded non-coinbase (non-reward) spend produced 10 BTC and 40 BTC outputs	The human owner of either output by chain data alone
“Bitcoin and Me”	Finney’s firsthand account of the test payment and bug reports	Contemporaneous certainty that he was the unique first runner

The usual biography turns all seven rows into one smooth legend. The primary record instead preserves the different evidence levels and the uncertainty between them.

PGP 2.0: Contributor Not Creator
#

Finney was one of the programmers credited on PGP 2.0 and later worked at PGP Corporation. Philip Zimmermann remained PGP’s creator; the surviving record does not support calling Finney its sole author.

Calling Finney “the creator of PGP” erases both Zimmermann and the collaborative implementation record.

On his archived homepage, Finney described himself as one of the original PGP 2.0 programmers, working directly with Zimmermann. The contemporary user guide credits a wider team. These sources do not reveal a neat percentage of code ownership, so I did not manufacture one.

What they do show is the first recurring pattern: Finney joined an ambitious cryptographic proposal at the implementation layer. PGP turned public-key cryptography into software ordinary computer users could run. His later post on PGP web-of-trust misconceptions also shows the less glamorous half of releasing cryptographic software—correcting what people thought the trust model guaranteed.

That distinction still matters. A privacy tool is not defined only by its primitive; it is defined by key distribution, interfaces, failure modes, and what users mistakenly infer. Our practical Cypherpunk Manifesto primer calls this the gap between a promise and a mechanism. Finney kept working inside that gap.

Remailers Made Metadata Part of the Privacy Problem
#

Finney’s remailer writing extended the problem from hiding message content to hiding communication relationships. Encryption could protect what a message said; remailers were meant to obscure who was communicating with whom.

In his November 1992 post Why Remailers I, Finney called private anonymous communication the ground floor for later credentials and transactions. A 1993 article, Protecting Privacy with Electronic Cash, organized the larger project into three layers: public-key encryption, anonymous messaging, and private electronic money.

This sequence is more useful than the vague label “privacy pioneer.” It identifies separate records and observers:

Layer	Record being protected	Unfinished problem
PGP	Message content	Sender-recipient relationship and endpoint data
Remailers	Communication path and identity linkage	Reliability, abuse resistance, traffic analysis, endpoint compromise
Electronic cash	Payment relationship and transaction history	Double spending, issuance, acceptance, and institutional pressure

Finney later wrote that he ran the first cryptographically based anonymous remailer. That is a firsthand claim, not a complete census of every early service. The stronger point does not depend on the superlative: in 1992 he was explaining operational infrastructure, and he later wrote that he had operated remailers.

RPOW Worked and Still Had a Server in the Middle
#

RPOW made proof-of-work tokens reusable through a dedicated server on an IBM 4758 security processor. Published code and remote attestation reduced trust in its operator; they did not remove the server or decentralize double-spend prevention.

Finney had explained the double-spending problem in 1993. His August 2004 RPOW announcement then described a running experiment: a client submitted a Hashcash anti-abuse stamp, and the server returned a token signed with public-key cryptography. A recipient could exchange that token for a fresh one, making the work transferable while accepting each specific token only once.

The server was the double-spend boundary. Remote attestation—a signed check of the loaded software—was meant to expose a modified server, while the IBM card protected signing keys from the machine’s owner. Finney’s RPOW security model treats the owner, operator, and developer as adversaries and trusts the attested software. That is trust reduction, not an absence of trust.

Question	RPOW	Bitcoin v0.1
Who rejects a second spend?	A dedicated server with persistent state	Nodes validating a shared proof-of-work history
What can a user verify?	Published code plus IBM 4758 attestation	Public rules, transactions, and accumulated chain work
Central dependency	Server availability, hardware, attestation chain	No mint or central server; network and software risks remain
Explicit early failure warning	Reloading the beta server could invalidate tokens	Alpha state might need restarting; consensus was still experimental
What proof of work does	Creates scarce input exchanged for signed tokens	Orders and protects transaction history while issuing coins

I traced this distinction because popular histories often call RPOW “Bitcoin before Bitcoin.” The Bitcoin white paper does not cite Finney or RPOW, and the surviving record does not prove a direct line of inheritance. RPOW belongs in the pre-Bitcoin proof-of-work lineage. Saying Bitcoin was built from it goes beyond the evidence.

Finney Did Not Believe Code Made Politics Disappear
#

Finney rejected a pure “write code and ignore politics” doctrine. In 1994 he argued that technical privacy protections still depended on political victories, public persuasion, and the legal environment in which people used the code.

This is the largest omission in the standard builder narrative. In Politics vs Technology, Finney answered a claim that technological gains were permanent and protest was secondary. His response was direct:

“There are no shortcuts. Withdrawing into technology is like pulling the blankets over your head.” — Hal Finney, 1994

He pointed to encryption controls, the investigation of PGP’s export, and the need for legal protections around compelled key disclosure. The lesson was not that code was useless. It was that deployment lives inside institutions, law, and public consent.

That makes his work more relevant to current privacy debates, not less. A protocol can narrow who must be trusted, but laws can criminalize its use, endpoints can betray it, and platforms can close access around it. The same tension appears in today’s enclosure of the open web: architecture and politics constrain each other.

Before Release Finney Was Already Asking Hard Questions
#

In November 2008, Finney called Bitcoin promising while questioning transaction propagation, competing chains, and double-spend checks. In January 2009, he moved from public review to testing the released client.

His 7 November reply to the Bitcoin paper praised the idea and immediately moved into failure analysis. That mix of optimism and interrogation matches the earlier record: understand the mechanism, locate the trust boundary, then run it.

When Satoshi announced Bitcoin v0.1 in January 2009, the message called the software alpha and experimental. Finney’s public reply said he was looking forward to trying it. His 11 January post reduced the next step to two words: “Running bitcoin”.

Four years later, Finney wrote that he thought he was the first person besides Satoshi to run Bitcoin, had mined a block in the seventies, and had reported bugs that Satoshi fixed. I preserve the phrase “he thought” because no public record lists every person who briefly launched the client. “One of the first known non-Satoshi runners” is supported; “definitively the second node” is not.

Finney published that retrospective after amyotrophic lateral sclerosis (ALS) had left him largely paralyzed and using an eye-tracking interface. He described continuing to write code, but the illness is context for how the account was produced—not evidence that any technical claim is more credible or that disability should be turned into an inspirational device.

Block 170 Proves a Spend Not a Human Name
#

Block 170 contains the earliest recorded non-coinbase Bitcoin spend: a 50 BTC input became 10 BTC and 40 BTC outputs. The chain proves those amounts and timing; Finney’s later testimony attributes the 10 BTC test payment to himself and Satoshi.

The transaction record is independently readable: txid f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16, block height 170, timestamp 12 January 2009 at 03:30:25 UTC, with 10 BTC and 40 BTC outputs. Earlier blocks still contain coinbase transactions that create block rewards, so calling this “the first Bitcoin transaction ever” without a qualifier is technically wrong.

The chain does not label the 10 BTC public key “Hal Finney.” That identity comes from Finney’s 2013 Bitcoin and Me post, where he said Satoshi sent him ten coins as a test. The historical claim therefore has two components:

On-chain fact: block 170 contains the earliest recorded non-coinbase spend and a 10 BTC output.
Off-chain attribution: Finney identified himself as the recipient and described the sender as Satoshi.

This separation is also the right habit for modern chain analysis. A graph shows transactions and scripts; attaching a human identity requires outside evidence and can be wrong. Our guide to Bitcoin on-chain privacy explains why address clustering should be treated as inference, not ground truth.

What the Finney “Bridge” Means—and What It Does Not
#

Finney’s career spans PGP 2.0, remailers, electronic-cash analysis, RPOW, and Bitcoin’s first public test. That makes “bridge” a useful career description—not proof of sole authorship, direct inheritance, or Satoshi’s identity.

The bridge is methodological:

Turn the privacy claim into a mechanism. PGP protected content; remailers addressed relationship metadata.
Name the remaining trust. RPOW published its code and attested its server, while retaining a server.
Test before mythologizing. Finney asked how Bitcoin failed, ran the alpha, reported bugs, and qualified his own recollection.
Keep politics in the threat model. He did not pretend cryptography made legal and institutional power vanish.

This is why the Satoshi question is a distraction here. No primary record in this audit proves Finney created Bitcoin, and the Bitcoin white paper does not cite him or RPOW. Speculation about authorship replaces a documented contribution with an unresolvable identity game.

Finney’s more durable legacy is a standard of practice: build the smallest working system that tests the claim, publish enough for others to inspect the trust boundary, and state uncertainty when the record cannot close it. That approach travels from PGP to RPOW to the first Bitcoin test more cleanly than any hero narrative.

Bottom Line
#

Hal Finney links cypherpunk practice to Bitcoin without proving a chain of invention. He helped implement PGP 2.0, operated remailers, built server-dependent RPOW, tested Bitcoin, and received its first known test transfer between people.

The evidence levels should remain visible. PGP had collaborators. RPOW had a server. Block 170 has public outputs but no names. Bitcoin and Me is firsthand testimony written four years later. Each limit tells us exactly what remains known.

Frequently Asked Questions
#

Each common Hal Finney claim depends on its evidence class. Dated posts establish public activity, chain data establishes a spend without naming people, and Finney’s later testimony supplies firsthand attribution with explicit uncertainty.

Was Hal Finney the first person besides Satoshi to run Bitcoin?
#

Possibly, but the record does not prove uniqueness. Finney wrote in 2013, “I think I was the first person besides Satoshi to run bitcoin.” His public “Running bitcoin” post confirms early use, not a complete census. “One of the first known non-Satoshi runners” is the evidence-safe formulation.

Why is block 170 called the first Bitcoin transaction?
#

It contains the earliest recorded non-coinbase transaction: previously mined 50 BTC were spent into 10 BTC and 40 BTC outputs. Earlier blocks contain coinbase transactions that create mining rewards. The 10 BTC output is identified as Finney’s test payment through his own later testimony, not a human-readable name on the chain.

Did Hal Finney invent Bitcoin or act as Satoshi Nakamoto?
#

The primary sources audited here do not establish either claim. They show Finney reviewing the design, running the released software, reporting bugs, and receiving a test payment from the person he described as Satoshi. Those interactions are evidence of collaboration and testing, not proof of shared identity or authorship.

Was RPOW an early version of Bitcoin?
#

It was a working pre-Bitcoin proof-of-work token experiment, but its architecture was different. RPOW used a dedicated server and IBM 4758 attestation to prevent unauthorized issuance and double spending. Bitcoin used a peer-to-peer proof-of-work chain to avoid a mint or central server. Direct RPOW-to-Bitcoin influence is not documented in the white paper.

What did Finney contribute to PGP 2.0?
#

The contemporary manual and Finney’s own account identify him as one of the programmers who worked on PGP 2.0 with Philip Zimmermann. The available records do not justify a precise percentage of the codebase, and they do not make Finney PGP’s creator or sole author.

References
#

The 12-record evidence map is supplemented by four contextual documents below. Each live source is paired with an exact Wayback replay selected from the archive’s CDX record rather than a guessed capture timestamp.

Cora Aegis

Cora Aegis writes privacy-first OPSEC guidance at CypherpunkGuide. For this article, she audited 12 primary records from 1992–2013, separated direct evidence from retrospective attribution, and prepared the evidence map and deterministic validator.

More about Cora Aegis ->

License Plate Readers: What Defense Actually Works (2026)

Fri, 10 Jul 2026 00:00:00 +0000

A license plate is the one identifier the state requires you to display in public, bolt to your car, and drive past every camera on every road you use. For most of their history, the automated cameras that photographed those plates — automated license plate readers, or ALPRs: roadside and patrol-car cameras that photograph every passing plate, stamp it with a time and place, and store it in a searchable database — were a niche police tool. They are now a dragnet — a net that catches every car that passes, not just the ones under suspicion. Flock Safety, the fastest-growing vendor, crossed 100,000 cameras in 2026; layered over Motorola’s older Vigilant network and thousands of local systems, the result is a country where — wherever a reader is deployed — your car’s movements are recorded, timestamped, and retained by default, and where most states still have no law that specifically governs any of it.

The abuse is not hypothetical, and it is not rare. Officers keep getting arrested for using these systems to hunt the people they used to date. A Pennsylvania officer tracked his estranged wife more than 250 times. A Kansas police chief, according to the department audit that exposed him, ran an ex-girlfriend and her new partner through the cameras 228 times. A Milwaukee officer logged 179 searches on a girlfriend and her ex. Flock’s own chief legal officer, asked about misuse, told the surveillance-industry outlet IPVM that using the system to “figure out where an ex-girlfriend is” was “actually the most common thing.” The company selling the dragnet knows precisely what its most common abuse looks like.

So what can one person do about a camera they do not own, on a road they do not control? Most of the answers you will find are worse than useless. Plate covers, reflective sprays, and tilt brackets are illegal in much of the country and, independent testing shows, do essentially nothing against a modern reader. We pulled the affidavits, indictments, and prosecutors’ press releases behind more than a dozen of these cases and cross-checked each against a disconfirming search — dropping two widely-cited “ALPR” stories that turned out to be a covert GPS tracker and a camera misreading an innocent driver’s plate, not plate-reader abuse at all. What the verified record shows is that the defenses that actually lower your risk are almost the inverse of what the how-to articles rank first.

The table below is our own synthesis: not a vendor’s talking points and not a rehash of a single advocacy tally, but the cases we could tie to primary court records, read for the pattern the coverage skips.

Officer / location	What the records show	Status
McSherry — Frazer Township, PA	Tracked his estranged wife 250+ times with police plate-reader gear	Pleaded guilty; jailed (2021)
Heiar — Kechi, KS	Followed his estranged wife via Flock, then texted her where she had been	Pleaded guilty to computer crime and stalking (2023)
Nygaard — Sedgwick, KS	228 Flock searches on an ex-girlfriend and her new partner, logged under false pretexts	Resigned; barred from policing (2023)
Josett — Costa Mesa, CA	Ran his wife, a mistress, and a romantic rival through law-enforcement databases	Pleaded guilty to three counts (2026)
Ayala — Milwaukee, WI	179 Flock searches on a girlfriend and her ex; victim reported fear	Pleaded guilty; resigned (2026)

Read across them and the controls reorder themselves. None of these women were reached because a clever disguise failed. They were reached because the person watching had a badge, a database, and no one reviewing the log — and that is a different problem than “how do I hide my plate” sets out to solve.

What an ALPR Network Actually Is
#

An ALPR network is not a camera; it is a searchable history of where your car has been. Each device is a passive sensor: it reads every plate in view, whether or not anyone is suspected of anything, and writes a row — plate, timestamp, GPS coordinate, often a photo of the vehicle and its surroundings — into a database that can be queried in seconds. String enough of them together and a single query returns a journey map: the route you drove, the times you left and returned, the church, clinic, union hall, or lover’s house you parked outside. The Electronic Frontier Foundation’s technical overview describes the core property plainly — ALPRs collect data on everyone, not just people under investigation.

Two features make this different from a beat cop noticing your car. The first is retention: readings are kept, so the surveillance is retroactive. A search run today can reconstruct where you were last month. Retention limits, where they exist at all, run from three minutes in New Hampshire to 21 days in Washington to 60 days or more elsewhere, and in most states there is no cap. The second is networking: one town’s cameras are routinely searchable by agencies in other states. In 2025, EFF and the ACLU documented San Francisco police running more than 1.6 million searches shared out of state, some tied to immigration enforcement — searches the department’s own policy did not authorize. Congress’s research service has catalogued the resulting legal gaps; the short version is that the technology outran the law by about a decade.

Retention is where that gap is widest, and it is worth seeing how little of the country caps it at all:

State	ALPR data retention limit
New Hampshire	~3 minutes unless flagged — strictest in the US
Washington	21 days (2026 Driver Privacy Act)
California	60 days (SB 34)
Most states	No ALPR-specific limit — kept indefinitely

The Abuse Is the Pattern, Not the Exception
#

The single most important fact about license-plate surveillance is that its most common documented misuse is not catching criminals — it is officers tracking women. That is not an activist’s framing; it is the vendor’s. When we set the court records side by side, the same story repeats across states: a current or former officer uses a system built for public safety to follow an intimate partner, an ex, or a woman he has fixated on.

Prosecutors say Ayala ran 179 Flock searches on a woman he had dated and her former partner. The abuse surfaced only because the victim grew suspicious and asked the department to check who had been searching her plate — and the internal review that followed exposed a second Milwaukee detective — one of the investigators assigned to Ayala’s own case — accused of doing the same thing to another woman. The audit log did not catch either man. A frightened victim did.

— Milwaukee, WI — Officer Josue Ayala, pleaded guilty 2026

That detail — the log did not catch him, the victim did — recurs almost everywhere. In Georgia, a chain of departments only surfaced misuse after adopting Flock’s audit tooling and actually looking: Braselton in November 2025, then Coffee County, Cherokee County, and Albany by July 2026 — four agencies in eight months, once someone finally reviewed the records. Not every one of these was ex-partner tracking; what they share is that an audit, not the system itself, is what caught them. The lesson is not “audit logs make you safe.” It is the opposite: a log that no one reads is a record of the crime, not a defense against it. Anyone who tells you the system is safe because it is “fully audited” is describing a smoke detector with the battery removed.

The scale is genuinely uncertain because the tally keeps climbing. The Institute for Justice’s Plate Privacy Project has been logging these police-stalking cases for years, and the count has only grown as more departments audit and more victims ask. Our own floor — the officers we could tie to guilty pleas, convictions, or active criminal charges — runs to a dozen, across seven states, and it is only a floor: new cases surfaced almost every month through 2026. Treat every specific number as a snapshot that will be out of date by the time you read it, and the pattern as permanent.

A caution that cuts the other way, because credibility requires it: not every dramatic “plate reader” story is one. A widely-shared California stalking case involved a covert GPS tracker, not ALPRs; another viral “Flock” incident was the system misreading an innocent woman’s plate and nearly getting her wrongly charged — a real harm, but a different one. Precision here is not pedantry. If you defend against the wrong mechanism, you spend your effort in the wrong place — the same failure the surveillance sells you when it promises a plate cover will help. For how scattered records get fused into a single profile in the first place, see our guide to AI-scale deanonymization.

The Gendered Layer: When the Watcher Knows Where She Sleeps
#

A license-plate dragnet is not experienced equally, because being findable is not equally dangerous for everyone. For a woman leaving an abuser, a person seeking reproductive care in a hostile state, or an activist a government dislikes, a system that turns a plate into a location is not an abstract privacy concern — it is the exact capability their threat model is built to deny. And it is precisely these people the record shows getting tracked.

The reproductive-care case is now documented in detail. In 2025, EFF revealed that a Texas sheriff searched more than 83,000 cameras nationwide to find a woman who had a self-managed abortion, using a “missing person” pretext. Washington’s response was to write the harm directly into law: the state’s 2026 Driver Privacy Act (SB 6002) bans using ALPR data for immigration enforcement and for tracking people seeking reproductive health care. When a legislature has to specifically prohibit using plate cameras to hunt abortion patients and immigrants, it is telling you what the cameras were already being used for.

This is why the intimate-partner cases are the center of the story rather than a lurid sidebar. The officers who tracked their exes were not exploiting an obscure flaw or writing custom code; they were using the system’s ordinary search box — no technical exploit required — for exactly the misuse its own vendor calls most common. For a survivor, the relevant fact is brutal in its simplicity: if your abuser has a badge, or a friend with one, the dragnet already knows your new commute. No plate cover changes that. What changes it is severing the link between the car and you, and using the legal machinery that lets you find out who has been searching — both covered in the defense section below, and both boring, which is why almost no one sells them to you.

What Actually Works: A Defense Matrix by Effectiveness
#

The honest ranking of individual defenses is close to the reverse of what most guides publish. The measures that get top billing — physical gadgets that “block” the camera — are the least effective and the most likely to be illegal. The measures that actually move your risk are legal, structural, and collective, and they are boring enough that the affiliate-driven listicles skip them. Here is the ranking the evidence supports, worst to best:

Defense	Does it work?	Legal?	Best for
Plate covers / reflective sprays / IR film	No — independent testing shows ~zero effect on modern readers	Illegal in CA, NY, FL, and many states (a California violation runs to roughly $2,000 with assessments)	No one — avoid
Varying routes and times	No — a 24/7 passive dragnet records you wherever you go	Legal	Peace of mind only; not a real control
Community camera maps (DeFlock)	Marginal — awareness and route-planning where coverage is thin (~partial)	Legal	Understanding your exposure, organizing locally
Legal data rights (public-records & deletion requests)	Partial — you can learn who searched you and request deletion, but vendors deflect	Legal	Survivors, anyone who suspects targeting
Structural: don’t tie a car to your name (car-share, rental)	High — a plate that is not yours defeats plate-based tracking	Legal	High-risk trips, sensitive destinations
Political: local contracts and state law	Highest — removes the cameras or caps their use for everyone	Legal	Everyone; the only durable fix

Start at the bottom, because that is where the leverage is. Political action is not the consolation prize; it is the highest-yield defense. Communities are canceling ALPR contracts in real numbers — by mid-2026, dozens of cities had dropped Flock over unauthorized federal and out-of-state data sharing, many after residents showed up to a council meeting with the audit records in hand. The ACLU’s “Get the Flock Out” toolkit exists precisely because this is the intervention that scales: one persuaded city council protects every driver in town in a way no personal gadget can — though never quite permanently. A later council can switch the cameras back on, as Richmond did in 2026 after a pause, which is why a cancellation is a fight you win and then keep.

Next, your legal rights, which are real but need managing expectations. In California and a growing list of states you can file a public-records request for a department’s ALPR policy and usage audits, and — where the law provides it — request the deletion of data about you. The catch, documented in ongoing litigation, is that Flock often characterizes itself as a mere “service provider” and routes individual requests back to the city, which may or may not act. Use the right; do not assume it is self-executing. California’s attorney general has sued at least one city over illegal data sharing, which is a reminder that enforcement, when it comes, tends to come from officials and courts rather than from individual opt-outs.

The one structural move an individual fully controls is the most effective personal defense on the list: break the link between the car and your identity for the trips that matter. A car-share vehicle, a rental, or a ride you do not own produces a plate that leads somewhere other than you. It will not hide your daily commute, but for the sensitive trip — the clinic, the shelter, the meeting — it is the difference between a plate that names you and one that does not. It is the vehicular version of the same principle that runs through the whole Sovereignty pillar: change the infrastructure, not just the behavior.

What is left is the row everyone starts with and should end with: physical obfuscation does not work and can get you fined. RadarTest’s independent review of reflective plate products found no measurable effect against modern readers, which combine infrared and visible-light capture with automatic exposure; meanwhile plate covers and sprays are explicitly illegal in California, New York, Florida, and elsewhere. You would be paying to break the law in exchange for nothing.

The Limits of Individual Defense
#

Against a passive, networked, retroactive dragnet, individual technique is necessary and insufficient at once. This is the limit the affiliate guides never state plainly, and stating it is the whole point of this article. You can rent a car for the clinic run and file your deletion requests, and you should. You cannot, alone, un-network a hundred thousand cameras, revoke another state’s access to your city’s data, or make a system that already recorded last month’s movements forget them. The reader that photographed your plate this morning did not care who you are, and no amount of personal cleverness reaches back to unmake the record.

The cases say so when you read them as a set. The victims who were tracked did not make an OPSEC mistake; a person with authorized access simply pointed the system at them. What actually moved those situations was not a gadget but the audit that got read, the reporter who published, the council that canceled the contract, the legislature that wrote a retention limit — the lever cypherpunks have always named, where personal defense meets institutional power and hands the rest to collective action. The Supreme Court has begun to signal that long-term, aggregated location tracking raises constitutional questions the dragnet’s operators would rather avoid; that pressure is built by lawsuits and legislation, not by tilting your plate. This is the same conclusion our study of state-mandated identity systems reached from the other direction: the durable fix is upstream, in the rules, not downstream, in the individual’s toolkit.

“Privacy is the power to selectively reveal oneself to the world.” — Eric Hughes, A Cypherpunk’s Manifesto, 1993

A license plate is the precise inverse of that power: an identifier you are forced to reveal to every camera, whether you consent or not. Defend the individual trip where you can — and then push on the conditions, because the vendor that calls stalking its “most common” use will not cap its own retention out of beneficence.

Bottom Line — Which Defense Matches Your Risk
#

There is no single answer, because the right defense depends entirely on who might point the system at you and how much it would cost you if they did.

If you are an ordinary driver who dislikes being tracked: skip the gadgets entirely, and spend the same energy on the one thing that scales — a records request to see your local department’s ALPR policy, and a message to your city council. Your leverage is political, not technical, and it protects your neighbors too.
If you are leaving an abusive partner — especially one with law-enforcement access: assume the dragnet already knows your routine, and defend the sensitive trips by not driving a car registered to you. In parallel, use your state’s data-access rights to find out who has been searching your plate; in the documented cases, that request is what exposed the officer.
If you are an activist, journalist, or organizer: treat your vehicle as a beacon and plan around it — car-share to sensitive meetings, and pair this with the identity and infrastructure discipline in our activist doxxing defense guide, because the plate is only one of the signals that places you.
If you are seeking reproductive or immigration-sensitive care in a hostile state: the threat is documented and specific. Do not drive your own car to the appointment, know your state’s retention and sharing rules before you go, and support the legislation — like Washington’s — that bans these searches outright.

Across all four, the same truth holds that held in every surveillance failure before it: you cannot out-gadget a dragnet. You can lower your exposure on the trips that matter, exercise the legal rights that force the system into the light, and — past the limit of what one person can do — act with others to take the cameras down.

Key Takeaways

The most common abuse is stalking, by the vendor’s own admission: Flock’s chief legal officer called using the system to locate “an ex-girlfriend” the “most common” misuse — a pattern confirmed by a dozen officers, in seven states, tied to guilty pleas, convictions, or criminal charges.
Physical blockers are the worst option: plate covers, sprays, and IR film show ~zero effect against modern readers in independent testing and are illegal in California, New York, Florida, and more, where a violation runs to roughly $2,000.
Audit logs do not protect you — reviewed logs do: in the documented cases, abuse was caught by suspicious victims and coworkers, not by the system; a log no one reads is evidence, not defense.
The effective personal move is structural: for sensitive trips, a car not registered to you defeats plate-based tracking in a way no accessory can.
The durable fix is political: dozens of cities canceled ALPR contracts by mid-2026, and states like Washington capped retention at 21 days and banned reproductive- and immigration-related searches — leverage no individual gadget can match.

Frequently Asked Questions
#

How do I defend against license plate readers?
#

Not with gadgets. Plate covers, reflective sprays, and tilt brackets are illegal in many states and do essentially nothing against modern readers. The defenses that work, in order of effectiveness, are political (push your city to cancel or cap its ALPR contract), legal (file public-records and data-deletion requests under your state’s law), and structural (for sensitive trips, drive a car that is not registered to you, such as a car-share or rental). Against a passive, always-on dragnet, lowering your exposure on the trips that matter and changing the rules through collective action beat any personal device.

Are license plate covers or reflective sprays legal — and do they work?
#

Generally no on both counts. Products marketed to “block” ALPR cameras — covers, reflective sprays like PhotoBlocker, infrared film — are explicitly illegal in California, New York, Florida, and other states, where a violation can run to roughly $2,000 once state assessments are added. Independent testing, such as RadarTest’s, found no measurable effect against modern readers, which use combined infrared and visible-light capture with automatic exposure. You would be paying to break the law in exchange for no real protection.

Can I get my license plate data deleted or find out who searched it?
#

Sometimes, depending on your state. In California and a growing number of states, you can file a public-records request for a department’s ALPR policy and usage audits, and where the law allows it, request deletion of data about you. In several documented stalking cases, a victim’s request to see who had searched their plate is exactly what exposed the officer. The limitation is that vendors like Flock often call themselves a “service provider” and route individual requests back to the city, which may not act — so treat the right as real but not self-executing.

How long do police keep license plate reader data?
#

It varies enormously and is usually uncapped. Among states with limits, retention runs from three minutes in New Hampshire to 21 days in Washington to 60 days or more elsewhere, but most states have no ALPR-specific retention law at all, meaning data can be kept and searched retroactively for months or years. Because the records are retained and networked across jurisdictions, a search run today can reconstruct where a car was weeks ago — the property that makes the technology a surveillance tool rather than a real-time alert.

Is Flock Safety legal?
#

Operating ALPR cameras is legal in most of the United States, but specific uses and data-sharing arrangements are increasingly being challenged as unlawful. By mid-2026, Flock faced class-action lawsuits, a state attorney general’s suit over illegal out-of-state data sharing, congressional scrutiny, and dozens of canceled city contracts after audits revealed unauthorized federal and cross-state searches. “Legal to deploy” and “legal in how it is actually used” have turned out to be very different questions.

Cora Aegis

Cora Aegis writes privacy-first OPSEC guidance at CypherpunkGuide, reading the primary records for the mechanism most coverage skips — here, how a plate you are required to display becomes a searchable map of your life, and which defenses against it are real.

More about Cora →

How Slack Monitoring Gets Employees Fired (2026)

Tue, 16 Jun 2026 00:00:00 +0000

Start from the part that is already settled, because there is no use pretending otherwise: your employer can read your Slack, including the messages marked private, and can export the entire history on a plan tier you will never see the admin panel for. If you take one thing from the search box that brought you here — can my employer read my Slack — take this: assume it is not private, and stop there. That answer is now everywhere, including in the AI summary you probably read on the way to this page, and we are not going to spend an article re-confirming it.

The question that page does not answer is the one that actually decides whether you keep your job: what gets flagged, and what gets you fired? Those are not the same as can it be read, and the gap between them is where careers are lost. We built this case study because the existing guidance stops at hygiene — use a personal device, avoid the DMs — and leaves the mechanism unwritten: how a chat log becomes a termination, who decides, and what changed in 2024 when the reader stopped being a human administrator and became an algorithm scoring your tone in real time. We watch the AI crawlers that index this site arrive on their own schedule, with no human in the loop; the same shift has now reached the inside of your workplace.

So this is a threat model for the chat window you are typing into right now. Below are three documented cases — all reported, all historical, named only where the naming is already public — and from them, the part the hygiene lists skip: the taxonomy of what gets people fired, the 2024 move to automated scoring that makes keyword-dodging useless, and an honest account of where individual defense ends and collective action begins.

The table below is our own synthesis: three reported cases mapped along one axis the hygiene lists skip — the monitoring method, what it flags, and what actually ends the job.

Monitoring method	What it flags	What actually gets you fired	Your real lever
Admin export & search (human-reviewed)	Keywords, named individuals, message history on request	Public or logged criticism of leadership; a message someone screenshots upward	Move the sensitive conversation off the employer’s platform
Pretext / targeted audit	Activity around an organizer or a leak investigation	Organizing and pay-equity work, reframed as a policy violation	Document the timeline; know your concerted-activity protections
Automated sentiment / toxicity scoring (AI, real-time)	Tone and pattern across all messages — no keyword needed	A low “sentiment” or risk score you never see, surfaced to the employer	Assume tone is scored; there is no phrasing that reliably evades it

How Corporate Slack Monitoring Actually Works
#

Corporate Slack monitoring is built into the product’s enterprise tiers, not bolted on: administrators on paid plans can export, search, and retain message history — including direct messages and channels you believe are private — and the distinction the platform invites you to miss is that private is a visibility setting, not a legal or technical wall. On a work-administered workspace, the operator of the system can reach what the system holds. That is the floor.

What matters for your threat model is the kind of reading, because the kinds differ in what they catch. The oldest and most common is administrator export and search: a human with the right role pulls history — often during an investigation, a dispute, or a departure — and reads or keyword-searches it. This is reactive and event-triggered; it usually needs a reason to look at you specifically. A second kind is the targeted audit, where a specific person’s activity is examined because they have drawn attention — as an organizer, a suspected leaker, a flight risk. The third kind is new, and it is the reason this article exists: automated, continuous scoring by third-party AI tools that read every message as it is sent and assign a tone, sentiment, or risk signal with no human in the loop until something is flagged. The first two ask what did this person say; the third asks what is the pattern across everything everyone says, all the time.

The legal frame, in the United States and many comparable jurisdictions, is unforgiving: on employer-owned systems, on company accounts, communications are generally the employer’s to monitor, and “I marked it private” carries little weight against the system’s operator. There are real limits — protected categories of speech, which we come to below — but the default is exposure. None of this is hidden; it is in the plan documentation. The error most people make is not ignorance of whether they can be read. It is misjudging which reading they are exposed to, and defending against the wrong one.

Three Cases: From What Was Watched to Who Was Fired
#

The fastest way to see the gap between can be read and gets you fired is to lay three reported cases beside one another and trace the same path through each: what was monitored, what triggered the firing, and what — if anything — would have changed the outcome. These are closed, documented episodes, drawn entirely from contemporaneous reporting; the message contents are attributed to those reports, not reconstructed here.

The mechanism: public correction of leadership. Days after Elon Musk’s acquisition of Twitter, the company dismissed a wave of employees who had criticized the new ownership in internal Slack channels and in public. Among those reported terminated was engineer Eric Frohnhoefer, who, according to NBC News, had publicly contradicted Musk’s technical claims about the platform’s performance and was let go shortly after.

The lesson is not the content of any one message. It is that criticizing leadership in a logged, employer-controlled channel — or in public under your work identity — is the single most reliable path from monitored to fired, and it requires no sophisticated tooling at all.

— Twitter, post-acquisition layoffs, November 2022

The mechanism: organizing, with a device-policy pretext. Apple dismissed Janneke Parrish, a program manager and co-organizer of the #AppleToo movement, which collected employee accounts of pay inequity and workplace treatment. The stated reason was the deletion of files from a work device during a leak investigation. Parrish and her supporters characterized the firing as retaliation for her organizing.

In January 2023, as reported by TechCrunch, an NLRB regional office found merit in complaints that Apple had infringed on workers’ rights. That was a preliminary step, not a final ruling, and the regulatory thread did not hold: in September 2025, as reported by Reuters, the labor board’s prosecutors withdrew that set of allegations — including the one over Parrish’s firing — amid a change in the Board’s leadership, with no final adjudication that Apple broke the law. The pattern to carry forward does not depend on the verdict: organizing work is rarely cited as the reason; a separate, defensible-sounding policy violation is, and the regulatory remedy, even when it begins, can take years and then evaporate.

— Apple, #AppleToo organizing, October 2021

The mechanism: no firing named — and that is the point. Aware, a company that sells AI monitoring of workplace chat across Slack, Microsoft Teams, and similar tools, scores messages for sentiment and “toxicity” at scale. As reported by CNBC in 2024, its systems had analyzed on the order of 20 billion interactions across more than 3 million employees, and its named clients included Walmart, Delta, T-Mobile, Chevron, and Starbucks.

There is no public termination attached to a single Aware score, and there does not need to be. Aware flags; the client company decides what to do with the flag. The threat is structural, not anecdotal — which is exactly why it does not produce a headline-grade firing the way the first two cases did, and why it is the harder one to defend against.

— Aware AI workplace monitoring, reported 2024

Read across the three and the synthesis is sharper than any single case. The Twitter episode shows that the oldest monitoring method — a human reading logged criticism — still produces the fastest firings. The Apple episode shows that monitoring is often the pretext’s evidence, not the stated cause: the firing is dressed in a policy violation while the real trigger is protected activity. And Aware shows the trajectory: away from a human deciding what a message says and toward a machine scoring what a pattern implies. The first two are about content you can choose. The third is about tone you cannot fully control — and that distinction is the whole 2024 update to this threat model.

The Threat Model: What Actually Gets You Fired
#

The terminations that flow from workplace chat monitoring cluster into a small number of triggers, and they are not evenly risky: criticism of leadership and organizing activity account for most reported cases, sentiment flags are the emerging third, and the legal protection that should cover the middle category is real but enforced slowly and unevenly. Knowing the taxonomy lets you defend the specific risk you carry rather than diffusing your caution across everything.

Four triggers do most of the work, and they are not evenly risky:

Firing trigger	Anchor case	How it usually appears	Relative risk
Leadership criticism in logged or public channels	Twitter, 2022	Cited directly, or a screenshot forwarded upward — no special tooling needed	Highest base rate
Organizing and pay-equity work	Apple, 2021	Almost never attributed to organizing; dressed as a contemporaneous policy issue (a deleted file, a device rule)	High, usually disguised
Sentiment and risk flags	Aware, 2024	An opaque score with no single message as the cause — nothing clean to point to or appeal	Emerging, hard to contest
Leak and confidentiality investigations	Vehicle for the others	The stated reason that licenses a targeted audit of someone inconvenient for a different reason	Amplifies the other three

Read top to bottom, the table also ranks your exposure: the first two triggers account for most documented firings, the third is the rising one, and the fourth is how the others are usually carried out.

Here is the legal nuance the hygiene lists flatten, and it matters enough to state precisely. In the United States, the National Labor Relations Act protects concerted activity — employees acting together over wages, hours, and working conditions, which includes much organizing and pay-equity discussion, and which applies to most private-sector workers regardless of whether a union is involved. That protection is genuine. It is also not a shield that operates in the moment: it is enforced after the fact, through a complaint to the National Labor Relations Board or litigation, with the burden on the employee to establish that the protected activity was the real reason for an adverse action. Outcomes vary, timelines run to months or years, and coverage differs by jurisdiction and worker category. The Apple matter is illustrative on both sides at once: organizers had a protected-activity claim, and the NLRB’s preliminary finding of merit came more than a year after the firing, only to be withdrawn in 2025 without a final ruling. Treat the NLRA as a reason to document carefully and act collectively — not as real-time immunity. This is general information drawn from public reporting and the statute, not legal advice; for your situation, consult an employment lawyer.

The 2024 Shift: When the Reader Became an Algorithm
#

The most important update to this threat model is that the reader of your workplace chat is no longer reliably a human administrator who needs a reason to look at you — it is, increasingly, an always-on AI system scoring every message for sentiment and risk, and that single change makes the standard advice about avoiding certain words largely useless. The Aware reporting marks the inflection point: monitoring at the scale of billions of interactions, applied continuously, to everyone, without an investigation as the precondition.

Understand why this defeats the old playbook. Keyword-based monitoring — the human export, the search for a specific term — can be evaded by not using the term. You can avoid naming the executive, avoid the word union, route around the trigger. Sentiment scoring has no keyword to avoid. It reads tone, frustration, the trajectory of your mood across weeks; it builds a pattern from how you write, not merely what you write. There is no phrasing that reliably reads as “neutral” to a model you cannot inspect, tuned to thresholds you are never shown, by a vendor whose scoring logic is a trade secret. The conversation does not need to contain a forbidden word to be flagged as a problem.

Three consequences reorder the defense. First, the human-judgment buffer is thinning. A human reviewer brings context — sarcasm, a bad week, an inside joke — that an automated score discards by design; the flag arrives stripped of the very nuance that might have excused the message. Second, there is nothing clean to appeal. A firing that traces to a content keyword gives you a specific message to contest; a firing downstream of an aggregate “risk score” gives you a number with no sentence attached. Third, and most usefully, it collapses the distinction between channels. If tone is scored everywhere, all the time, then channel discipline is your only real control — not word choice within the employer’s platform, but moving the conversations that carry real risk off that platform entirely. Which is the playbook.

The Defensive Playbook
#

Defending against workplace chat monitoring means matching your control to the specific trigger you carry, and the controls fall into three tiers: separate your accounts and devices so work surveillance cannot reach your personal life, practice channel discipline inside the workplace, and — if you are doing anything organizing-adjacent — move the high-risk conversation off the employer’s platform before it begins. You do not need all of it. You need the layer that fits your threat.

Separate the surfaces. Keep work and personal on different devices and different accounts, with no overlap — no personal logins on the work laptop, no work chat on your personal phone beyond what is strictly required. This is the baseline the AI summaries already give you, and it is correct: it prevents the monitoring of one context from reaching the other, and it is the cheapest control to adopt. It is also necessary but not sufficient, because it does nothing about what you say inside the work surface.

Practice channel discipline. On any employer-administered workspace, write every message — including direct messages, including the channels marked private — as though it will be exported and read by someone unsympathetic, because the operator of the system can do exactly that. This is not about self-censoring your competence into silence; it is about never putting the sentence that ends your career into a system its target controls.

Move the high-risk conversation off-platform — early. If you are organizing, raising pay equity, or planning anything that an employer would have an incentive to surveil, the single highest-leverage move is to hold that conversation somewhere your employer does not operate, before it is well underway rather than after it is discovered. On a personal device, on your own time, an end-to-end encrypted channel such as Signal or SimpleX keeps the substance out of the export entirely — the metadata-minimizing design of these tools is the relevant property, not any single feature. This is the structural fix the Apple case points to: the organizing conversation that lives on the employer’s platform is evidence; the one that never touched it is not. Pair this with the broader principle that what you publish is hard to unpublish — the permanence of a digital footprint applies inside a workplace log as much as on social media.

Know your concerted-activity protections — and document. If your activity is concerted — collective action on wages, hours, or working conditions — it likely falls within NLRA protection, which is worth knowing precisely because it shapes what you record. Keep a contemporaneous, dated timeline of the protected activity and of any adverse treatment that follows it, stored on a personal device. You are not building immunity; you are building the evidentiary record that an after-the-fact complaint or an employment lawyer will need, given that the burden of showing the real reason will fall on you.

Why Individual Defense Isn’t Enough
#

Here is the honest limit, and an OPSEC failure case study that hid it would be doing the same thing the hygiene lists do. Channel discipline and device separation protect the individual; they do not change the conditions that produced the surveillance, and against opaque automated scoring applied to everyone at once, individual technique runs out. You can keep the firing sentence off the employer’s platform. You cannot, alone, opt out of a sentiment score running across the whole workspace, nor restore the human-judgment buffer that automated monitoring removes, nor shift a burden of proof that the law places on you.

The cases say as much when you read them as a set. The Twitter firings were a power asymmetry, not a phrasing problem. Apple’s organizers needed collective weight and a regulator’s attention — the NLRB, not better OPSEC — to put the claim on the record at all, and even then the finding was preliminary, arrived long after the jobs were gone, and was later withdrawn without a final ruling. Aware’s model is structural by construction: it is sold as monitoring everyone, which is precisely what no individual can route around. The lever that actually moves these conditions is the one cypherpunks have always named when individual cryptography meets institutional power — collective action and changed rules. Stronger enforcement of concerted-activity protections, transparency requirements for automated workplace scoring, organizing that has the numbers to make retaliation costly. Individual defense buys you safety and time; it does not, by itself, fix the asymmetry.

That is the through-line across this site’s Privacy work. The surveillance you face from your employer is the same shape as the surveillance you face from a breaching government database — you cannot delete yourself from a system you are required to participate in, so the defense lives in the layers you control and, beyond them, in collective pressure. And the deeper engine under all of it is the one we map in OPSEC in the AI Age: once the reader is a machine that scores tone continuously, the old rule of avoiding the wrong word stops working, and the threat model has to be rebuilt around the pattern, not the statement. Keep the rest of the Privacy pillar close — workplace monitoring is one face of a single problem.

“Privacy is necessary for an open society in the electronic age. … We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy out of their beneficence.” — Eric Hughes, A Cypherpunk’s Manifesto, 1993

The corporation is the faceless organization here, and the chat log is the electronic age. Defend the individual case, and then push on the conditions — because no monitoring vendor, and no employer who buys one, will grant you privacy out of its beneficence.

Bottom Line — Which Defense Matches Your Situation
#

The right level of caution depends entirely on what you are doing in that chat window and who has reason to watch you.

If you are a general employee with no specific exposure: treat the workspace as exported-by-default, separate your work and personal devices and accounts, and keep the career-ending sentence out of any employer-controlled system. That is most of your risk handled at low cost.
If you are organizing, raising pay equity, or anything an employer would want to surveil: your front line is off-platform. Move the substantive conversation to a personal device on an encrypted channel before it is underway, document a dated timeline of protected activity and any retaliation, and learn your concerted-activity protections as evidence-shaping, not as real-time immunity.
If you run a privacy or security team: the 2024 shift is your planning input. Assume employees are subject to automated sentiment scoring whose logic you cannot see, design policy on the understanding that tone is now monitored and there is no safe keyword set, and weigh the structural cost of concentrating chat surveillance under a third-party vendor against its sold efficiency.

Across all three, the same truth holds that held in every OPSEC failure before it: you cannot reliably un-send your way to safety after a message is logged. You can only decide, before you type, which system is allowed to hold the sentence — and, past the limit of what one person can do, act with others to change the conditions that made the system watch you in the first place.

Key Takeaways

Whether your employer can read your Slack is settled — yes, including “private” DMs. The decisive question is what gets you fired, and that is a different threat model the hygiene lists skip.
Monitoring & firing — Twitter, 2022: criticizing leadership in logged or public channels is the fastest documented path from monitored to fired, and needs no special tooling.
Monitoring & firing — Apple, 2021: organizing is rarely the stated reason; a contemporaneous policy violation (a deleted file, a device rule) is the pretext. An NLRB regional office found merit in the workers’ rights claim more than a year later — a preliminary step the agency withdrew in 2025 without a final ruling.
The 2024 shift — Aware AI: continuous automated sentiment scoring of billions of messages means there is no keyword to avoid; tone itself is scored, so word-dodging no longer works and channel discipline is the only real control.
Legal reality — the NLRA: it protects concerted activity over wages and conditions, but enforces after the fact with the burden on you; treat it as a reason to document and organize, not as real-time immunity.
The limit: individual defense buys safety and time but cannot opt you out of workspace-wide scoring or fix the power asymmetry — collective action and changed rules do that.

Frequently Asked Questions
#

Can my employer read my Slack direct messages?
#

On a work-administered Slack workspace, generally yes. Administrators on paid plans can export and search message history, including direct messages and channels marked private. Private is a visibility setting between users, not a barrier against the operator of the system. Treat any message on an employer-controlled workspace — including DMs — as readable and exportable by the employer.

Is workplace chat monitoring legal?
#

In the United States and many comparable jurisdictions, monitoring of communications on employer-owned systems and company accounts is generally permitted, and the default on a work workspace is that your messages are the employer’s to monitor. Specific rules vary by jurisdiction and by what is being monitored, and there are protected categories of activity (see the NLRA below). This is general information, not legal advice — consult an employment lawyer for your situation.

Does the NLRA protect me if I criticize my employer on Slack?
#

Partly, and conditionally. The National Labor Relations Act protects concerted activity — employees acting together over wages, hours, and working conditions, which covers much organizing and pay-equity discussion for most private-sector workers. But it is enforced after the fact, through an NLRB complaint or litigation, with the burden on you to show the protected activity was the real reason for an adverse action; outcomes and timelines vary. Individual venting that is not collective and not about working conditions is generally not covered.

Can I avoid being flagged by AI sentiment monitoring?
#

Not reliably by changing your words. Tools like those reported in 2024 score tone and patterns across all your messages rather than searching for specific keywords, so there is no phrase that dependably reads as neutral to a model you cannot inspect. The realistic control is not phrasing inside the employer’s platform — it is keeping high-risk conversations off that platform entirely.

What tools actually help against workplace monitoring?
#

For the conversations that carry real risk — organizing, pay equity, anything an employer would want to surveil — moving them off the employer’s platform onto a personal device using an end-to-end encrypted, metadata-minimizing channel such as Signal or SimpleX keeps the substance out of any export. Inside work, the controls are separating work and personal devices and accounts, and disciplined channel use. No tool inside an employer-administered workspace makes your messages unreadable to its administrator.

#	Source	URL	Archive
1	NBC News — Twitter post-acquisition layoffs and Eric Frohnhoefer (Nov 2022)	https://www.nbcnews.com/news/amp/rcna57250	https://web.archive.org/web/*/https://www.nbcnews.com/news/amp/rcna57250
2	CNN Business — Apple fires #AppleToo organizer Janneke Parrish (Oct 2021)	https://www.cnn.com/2021/10/15/tech/apple-appletoo-organizer-janneke-parish/index.html	https://web.archive.org/web/*/https://www.cnn.com/2021/10/15/tech/apple-appletoo-organizer-janneke-parish/index.html
3	TechCrunch — NLRB found Apple execs infringed on workers’ rights (Jan 2023)	https://techcrunch.com/2023/01/30/labor-officials-found-that-apple-execs-infringed-on-workers-rights/	https://web.archive.org/web/*/https://techcrunch.com/2023/01/30/labor-officials-found-that-apple-execs-infringed-on-workers-rights/
4	CNBC — AI may be reading your Slack and Teams messages, via Aware (Feb 2024)	https://www.cnbc.com/2024/02/09/ai-might-be-reading-your-slack-teams-messages-using-tech-from-aware.html	https://web.archive.org/web/*/https://www.cnbc.com/2024/02/09/ai-might-be-reading-your-slack-teams-messages-using-tech-from-aware.html
5	National Labor Relations Board — Concerted activity (Section 7 rights)	https://www.nlrb.gov/about-nlrb/rights-we-protect/the-law/employees/concerted-activity	https://web.archive.org/web/*/https://www.nlrb.gov/about-nlrb/rights-we-protect/the-law/employees/concerted-activity
6	Reuters — US labor board withdraws claims Apple CEO violated employee rights (Sep 2025)	https://www.reuters.com/sustainability/sustainable-finance-reporting/us-labor-board-withdraws-claims-apple-ceo-violated-employee-rights-bloomberg-2025-09-26/	https://web.archive.org/web/*/https://www.reuters.com/sustainability/sustainable-finance-reporting/us-labor-board-withdraws-claims-apple-ceo-violated-employee-rights-bloomberg-2025-09-26/

Cora Aegis

Cora Aegis writes privacy-first OPSEC guidance at CypherpunkGuide, reading closed surveillance cases for the mechanism most coverage skips — here, how a workplace chat log becomes a termination.

More about Cora →

Phone Number Privacy: What Still Works in 2026

Tue, 14 Jul 2026 00:00:00 +0000

Every signup form asks for it. Your bank, your dentist, your grocery loyalty card, and — as I found while pulling the signup requirements of six major hosted AI services this month — your chatbot. A user on r/privacy put it better than most security vendors manage: the phone number is the new SSN. It is the one identifier most people never change, carry across every service, and hand out dozens of times a year, which makes it the cheapest join key an adversary or a data broker could ask for.

The complication is that 2026 is squeezing the escape routes from two directions at once. From above, the US FCC is proposing that every phone provider collect “the name, physical address, government issued identification number, and an alternate telephone number” of each new and renewing customer — the model that 157 countries already enforced in some form as of Privacy International’s 2021 global tally. From below, services are quietly refusing the workaround every guide recommends first — VoIP numbers, the internet-based phone numbers apps like Google Voice or Hushed hand out, tied to no SIM card. Anthropic’s help center now states you “cannot use VoIP numbers, Google Voice, phone numbers created using apps, landlines” to open a Claude account, and Google Voice itself started requiring government ID from new users in January 2026. Meanwhile the number you already have keeps leaking: the FBI logged 982 SIM-swap complaints and $26 million in losses in 2024, and a surveillance vendor was caught exploiting SS7 — the 1970s-era routing protocol between carriers — to locate phones by number through 2024 and 2025.

So the honest question is not “how do I hide my phone number” — you cannot fully, and pretending otherwise is how people get hurt. The question is which number does which job. This article maps what a number reveals, documents the squeeze with primary sources and a country-by-country table, shows — from my own review of each service’s signup requirements — which services actually reject alternative numbers, and then lays out the four-number strategy that still works, matched to four concrete threat models.

Your Phone Number Is an Identity Document Now
#

Phone number identity binding is the practice of using your phone number as a proof of who you are — not just a way to reach you. That is what changed. A contact detail can be swapped; an identity anchor is what accounts, brokers, and governments use to link everything else together. Three mechanics make the number uniquely dangerous in that role.

It unlocks accounts that were never yours to lose. A SIM swap is an attack where someone convinces your carrier to move your number onto their SIM card; every text message — including login codes — then goes to them. This is not exotic. When Princeton researchers tested five major US prepaid carriers in 2020, their SIM-swap attempts succeeded in 39 of 50 tries (78%), and of 140+ popular websites they audited, 17 could be taken over with the phone number alone — no password needed. The FBI’s Internet Crime Complaint Center recorded 982 SIM-swap complaints with $25.98 million lost in 2024; down from $72.7 million in 2022, though some losses may now be logged under adjacent fraud categories.

It broadcasts your location to anyone who can rent the access. SS7, the signaling network carriers use to route calls between each other, lets whoever gains entry ask “where is this number right now.” In 2025, researchers at telecom-security firm Enea documented a surveillance vendor using a malformed-command trick to bypass carrier defenses and pull phone locations on demand — an attack class Enea has tracked in active use since late 2024. You do not need to click anything. Knowing your number is enough.

It resolves to your name. In the US, CNAM — the caller-name database carriers maintain — maps numbers to registered names, and commercial people-search sites cross-reference numbers against breach data, voter rolls, and property records to return a name and home address for a few dollars. A “private” number that has ever been tied to your identity is an index entry, permanently. That permanence is the same dynamic I documented for social media history: deleting the visible copy does not delete the join key.

The Squeeze: ID From Above, Rejection From Below
#

Here is the structural shift most guides have not caught up with: the two escape routes people relied on — buy a prepaid SIM with cash, or use an internet number — are being closed from opposite ends at the same time. Understanding both jaws of the squeeze is what makes the strategy in the next sections realistic instead of nostalgic.

From above: registration mandates. As of Privacy International’s 2021 global review, 157 countries required identity registration for SIM cards; only 34 did not; and 14 demanded biometrics such as face scans. The no-mandate list keeps shrinking: Mexico’s Supreme Court struck down a biometric SIM registry in 2022 — and in January 2026 a CURP-based ID registration requirement arrived anyway, with unregistered lines being suspended from July 2026. The United States has been the notable holdout — no federal registration mandate — which is exactly what the FCC’s April 2026 proposal (docket CG 17-59, published in the Federal Register on May 26) would end with a know-your-customer (KYC) mandate: name, residential address, government-issued ID number, an alternate phone number, retained for four years after the customer relationship ends. It is a proposal, not law — reply comments run through July 27, 2026 — but the direction of travel is unambiguous. Japan moved the same direction one month earlier: a May 2026 amendment to its mobile-phone anti-fraud law extends identity checks to data-only SIMs, the last ID-free niche in that market, with enforcement due by May 2027.

The people this squeezes first are not criminals. The National Network to End Domestic Violence told the FCC that the “suspicious” behaviors the proposal targets — paying cash, using a PO box or a mail-forwarding address — “are, for survivors, well-established and often life-preserving safety practices.” A survivor fleeing an abuser may have no safe address to give and no documents she can retrieve. Journalists and their sources have the same problem with different stakes. This is the pattern I keep returning to on this site: identity checkpoints built for fraud land hardest on the people with the most to lose.

Where your country stands. I built this table from primary legal sources and Privacy International’s survey; each row carries its own source and check date. It is a snapshot of representative regimes, not a complete list.

Country	ID required for prepaid SIM?	What is checked	Data-only SIM	Source
United States	No legal mandate — FCC proposal pending (2026) would add ID collection	—	—	source · 2026-07-14
United Kingdom	No legal mandate	—	—	source · 2026-07-14
Portugal	No legal mandate	—	—	source · 2026-07-14
Germany	Required by law (2017)	Government ID	Same rule	source · 2026-07-14
Spain	Required by law (2007)	Government ID	Same rule	source · 2026-07-14
Mexico	Required by law (2026) — biometric registry struck down 2022; CURP-based ID registration in force since Jan 2026	Government ID	Same rule	source · 2026-07-14
Brazil	Required by law	Government ID	Same rule	source · 2026-07-14
Japan	Required by law (2006) — 2026 amendment extends ID checks to data-only SIMs by May 2027	Government ID	Exempt today	source · 2026-07-14
China	Required by law (2019)	Government ID + face scan	Same rule	source · 2026-07-14

Snapshot of representative regimes, not a complete list — rules change; every row carries its source and last-checked date. "No legal mandate" does not mean carriers collect nothing: payment records, store cameras, and carrier policies still exist.

Before acting on anything later in this article, find the row for the country you live in in the table above: in a no-mandate country the prepaid layer of the strategy below is available to you today; in a mandate country that layer is identity-linked at purchase, and the other three layers have to carry the separation.

From below: the services themselves. Even where the law is silent, platforms increasingly refuse numbers that are not tied to a carrier account — and they can tell the difference. Twilio’s Line Type Intelligence API, one of several commercial lookups, classifies any number into twelve types — mobile, landline, fixedVoip, nonFixedVoip, and so on — and Twilio openly markets filtering “nonFixedVoip” numbers out of verification flows to fraud teams. Google Voice, once the default privacy recommendation, now requires government ID verification for new numbers (January 30, 2026). The workaround economy is being priced and permissioned out.

I Checked Which AI Services Reject Alternative Numbers
#

Abstract warnings are less useful than a tested list. In July 2026 I pulled the current signup requirements of six major hosted AI services from their own help centers, terms, and privacy policies, archiving each source as part of a larger requirements dataset I am building — treat the table as a dated snapshot and verify against each provider’s current pages before relying on it. AI assistants are a fair test bed: they are the fastest-growing account category, and as I showed in the AI-assistant audit, what you tell them is a record.

Service	Phone at signup (as of 2026-07)	Number-free path	Detail that matters
Claude (Anthropic)	Required — all new accounts, SMS only	None	VoIP, Google Voice, app numbers, landlines rejected; one account per number
ChatGPT (OpenAI)	Not required via email/SSO	Email or Google/Microsoft/Apple SSO	Phone-only signup exists but is limited to 13 listed regions
Gemini (Google)	Follows Google Account rules	Google Account	Binding is to your entire Google identity, not just a number
DeepSeek	Email or phone	Email path	Either identifier accepted at registration
OpenRouter	Not required	Email/SSO	A router: your identity exposure shifts to whichever provider serves the model
Venice	Not required	Email, social, or crypto wallet	Demo works with no account at all — the lowest-binding path we found

The Claude row deserves the verbatim quote, because it is the clearest statement of the new normal from any major service: “We require phone verification for all new users, and there isn’t a way to skip this step… you cannot use VoIP numbers, Google Voice, phone numbers created using apps, landlines, or other numbers that can’t receive texts to verify your account.” One real mobile number, one account. The spread in that table is the practical point: the same product category ranges from “carrier-verified phone, no exceptions” to “no account needed.” Which number — if any — a service deserves is a choice you still get to make, but only if you check before you type your real one.

The Four-Number Strategy That Still Works
#

A single phone number doing every job is the vulnerability. The durable fix is role separation — the same compartmentation logic that runs through threat modeling in the AI age — applied to the one identifier people forget to compartment. Phone numbers are cheap; being findable by one join key is expensive. Four layers, from most protected to most disposable:

Layer	The number	Give it to	Never use it for
1 — Vault	Your real carrier number	Carrier, banks that force SMS, government	Any website signup, messaging apps, directories
2 — Identity	Secure messenger behind a username	People you actually talk to	Public posting; discovery left open
3 — Account	One or two VoIP numbers	Shops, newsletters, apps that accept VoIP	Anything that can drain money
4 — Edge	Prepaid SIM (where lawful) or no number	One-off verifications, classifieds, travel	Logging into Layer-1/2 accounts

Setting it up in order:

Harden the vault before anything else. Call your carrier and set a port-out PIN or number lock — the Princeton results show why carrier authentication is the weakest wall. Then remove the real number from every account that lets you swap in an authenticator app or passkey; SMS should be your second factor only where nothing else is offered.
Turn your messenger number into a username. Signal has let you hide your number behind a username since February 2024 — a phone number is still required to register, but with “Who can find me by my number” set to Nobody, contacts see cora.01, not digits. Layer 2 exists because reachability and identity were never the same thing.
Buy the account layer. A VoIP service — internet telephony, numbers not tied to a SIM — like MySudo or Hushed gives you compartment numbers for a few dollars a month; JMP.chat runs over XMPP and is popular in privacy communities. Expect exactly what the table above showed: some services will reject these numbers, and that rejection is itself information about how much identity that service demands.
Keep an edge layer where your row allows it. In no-mandate countries, a cash-bought prepaid SIM is still legal and still the cleanest one-off verifier — the FCC proposal has not passed. In mandate countries, the honest version of this layer is no number: prefer the email path, the wallet path, or walking away. What I do not recommend is lying to a carrier or evading a legal ID requirement — in registration countries that can be an offense in itself, and this site does not do legal-risk roulette.

Two payments notes, briefly: pay for VoIP layers with a masked or prepaid card where you can, because a privacy number billed to your real card is a paperwork detour, not a wall; and if you already keep KYC-free bitcoin for principle’s sake, JMP.chat is one of the few number services that accepts it.

Match the Numbers to Your Threat Model
#

Strategy only means something against a named adversary. Four that cover most readers — pick yours and the table above collapses to two or three concrete moves.

Threat	What they exploit	Your moves
Data brokers / marketers	Number as join key across services	Layer 3 everywhere; never the vault number on forms
Breach + credential attackers	SMS codes, reused identifiers	Authenticator/passkeys on vault accounts; carrier PIN
A person — stalker, ex, harasser	People-search, CNAM, shared history	New Layer 2 with hidden number; broker opt-outs; Layer 1 known to almost no one
Well-resourced / state-level	SS7 location, carrier records, registration data	No number you carry is location-safe; separate devices — see the activist safe-publishing protocol

The stalker row is the one I write for. The FCC filing record says the quiet part: the survivors’ network describes cash-paid phones and confidential addresses as “life-preserving safety practices,” and those are precisely the behaviors a KYC regime flags as suspicious. If your threat is a person who knows your name, the vault number they already have is the risk — a number they have never seen, on a messenger that will not confirm it, is worth more than any amount of blocking.

What Does Not Work
#

Debunking is a defense layer of its own; these four failures cost real money and real safety.

“A burner app makes me anonymous.” A VoIP number hides your carrier number from the person you call — it does not hide you from the app, which knows your payment method, IP address, and often your contact list, and it fails carrier lookups the moment a service checks line type. Useful compartment, not an invisibility cloak.
“I’ll just change my number.” The old number stays in every broker database, breach dump, and CNAM record you ever touched, and the new one starts accumulating the moment you hand it out the same way. Rotation without role separation resets nothing.
“Prepaid is anonymous.” In 157 countries it is registered to your ID at the counter. Even in no-mandate countries, the purchase leaves payment records and store footage, and the FCC is proposing to close the gap entirely. Treat cash prepaid as unlinked at purchase, not untraceable in use — the SS7 findings above apply to every SIM equally.
“SMS two-factor is better than nothing.” True, and it is also the mechanism that made 17 of 140+ audited sites takeover-able by number alone. Where an authenticator app or passkey exists, SMS is not your backup — it is your attack surface.

Bottom Line — Which Setup Is Right for You?
#

If you do one thing today: set a carrier port-out PIN and remove your real number from every account that accepts an authenticator app instead. That single hour closes the SIM-swap path that produced $26 million in reported US losses last year.

If you do the full setup: vault number for banks and government, Signal username for humans, one VoIP number for accounts, and — where your country’s row permits — a cash prepaid for the edge. Check the service before you spend the number: the difference between Claude (carrier-verified phone, no exceptions) and a wallet-auth service like Venice is the difference between permanent identity binding and none, in the same product category.

And keep one eye on the calendar: the FCC’s reply-comment window closes July 27, 2026, Japan’s data-SIM rule lands by May 2027, and each row of the table above carries its check date. Number privacy in 2026 is not a purchase; it is a structure you maintain.

Key Takeaways

The number is an identity anchor: 982 SIM-swap complaints and $25.98M in losses (FBI IC3, 2024); Princeton found 78% SIM-swap success (39 of 50 tries) and 17 of 140+ sites takeover-able by number alone (2020).
The squeeze is real and two-sided: 157 countries mandate SIM registration, 14 with biometrics (Privacy International, 2021); the 2026 FCC proposal (CG 17-59) would add US KYC with 4-year retention, while Claude rejects VoIP numbers outright and Google Voice now demands government ID (Jan 2026).
Four numbers, four jobs: vault (carrier + port-out PIN), identity (Signal username, number hidden since Feb 2024), account (VoIP: MySudo/Hushed/JMP.chat), edge (cash prepaid where lawful — or no number at all).
Check the row, then the service: SIM law varies by country (see table, per-row sources); services range from phone-mandatory (Claude) to wallet-auth (Venice) in the same category — verify before you hand over digits.
What fails: burner-app “anonymity,” number rotation without role separation, “prepaid = untraceable” (SS7 tracks every SIM), and SMS 2FA wherever a passkey exists.

Frequently Asked Questions
#

Is a VoIP number enough to keep my identity private?
#

It compartments — it does not anonymize. A VoIP number stops shops and apps from learning your carrier number, but the VoIP provider knows your payment method and IP address, and services can detect the line type via lookup APIs like Twilio’s and refuse it, as Claude does. Use VoIP for the account layer, never as your only wall.

Are burner phones illegal in 2026?
#

In the US, no — there is currently no federal ID requirement for prepaid SIMs, though the FCC’s 2026 proposal (reply comments through July 27, 2026) would change that. In the 157 countries with registration mandates, prepaid SIMs are legal but identity-linked at purchase; buying one under a false identity can be an offense. Check your country’s row in the table above and its source.

Does Signal still require my phone number?
#

Yes — a phone number is required to register, unchanged since the February 2024 username launch. What changed is exposure: with a username and “Who can find me by my number” set to Nobody, other users never see the number. Register with your vault or VoIP number once, then hand out only the username.

What happens if the FCC proposal becomes law?
#

Every US provider — including prepaid — would collect your name, residential address, government-issued ID number, and an alternate phone number, and keep those records four years after you leave. Domestic-violence advocates told the FCC this converts survivors’ safety practices into red flags. If it passes, the US leaves the shrinking no-mandate club — 34 countries as of 2021, minus Mexico since January 2026 — and the edge layer of the strategy shifts from prepaid to no-number paths.

Should I just get a new number and start over?
#

Only as part of role separation, and only if your threat is a specific person who has the old one. The old number remains in broker databases and breach dumps permanently, and a new number used the old way — one number for everything — rebuilds the same profile within months. Structure beats rotation.

Sources
#

#	Source	URL	Archived
1	FCC — Enhancing Know-Your-Customer Requirements, FNPRM CG 17-59 (Federal Register, 2026-05-26)	https://www.federalregister.gov/documents/2026/05/26/2026-10407/enhancing-know-your-customer-requirements	https://web.archive.org/web/*/https://www.federalregister.gov/documents/2026/05/26/2026-10407/enhancing-know-your-customer-requirements
2	Ars Technica — FCC plans ID mandate that could block anonymous prepaid phones (NNEDV filing quotes, 2026-06-24)	https://arstechnica.com/tech-policy/2026/06/fcc-plans-id-mandate-that-could-block-anonymous-use-of-prepaid-burner-phones/	https://web.archive.org/web/*/https://arstechnica.com/tech-policy/2026/06/fcc-plans-id-mandate-that-could-block-anonymous-use-of-prepaid-burner-phones/
3	Privacy International — Timeline of SIM card registration laws (2021 survey)	https://privacyinternational.org/long-read/3018/timeline-sim-card-registration-laws	https://web.archive.org/web/*/https://privacyinternational.org/long-read/3018/timeline-sim-card-registration-laws
4	FBI IC3 — 2024 Internet Crime Report (SIM swap: 982 complaints, $25,983,946)	https://www.ic3.gov/AnnualReport/Reports/2024_IC3Report.pdf	https://web.archive.org/web/*/https://www.ic3.gov/AnnualReport/Reports/2024_IC3Report.pdf
5	Lee et al., Princeton — An Empirical Study of Wireless Carrier Authentication for SIM Swaps (2020)	https://collaborate.princeton.edu/en/publications/an-empirical-study-of-wireless-carrier-authentication-for-sim-swa	https://web.archive.org/web/*/https://collaborate.princeton.edu/en/publications/an-empirical-study-of-wireless-carrier-authentication-for-sim-swa
6	Signal — Keep your phone number private with Signal usernames (2024-02-20)	https://signal.org/blog/phone-number-privacy-usernames/	https://web.archive.org/web/*/https://signal.org/blog/phone-number-privacy-usernames/
7	Anthropic — How to verify your phone number (help center, checked 2026-07)	https://support.claude.com/en/articles/8287232-verify-your-phone-number	https://web.archive.org/web/*/https://support.claude.com/en/articles/8287232-verify-your-phone-number
8	Google Voice — Identity verification required to claim a number (effective 2026-01-30)	https://support.google.com/voice/community-guide/405972015/identity-verification-now-required-before-you-can-claim-a-google-voice-number	https://web.archive.org/web/*/https://support.google.com/voice/community-guide/405972015/identity-verification-now-required-before-you-can-claim-a-google-voice-number
9	Twilio — Lookup v2: Line Type Intelligence (12 line types)	https://www.twilio.com/docs/lookup/v2-api/line-type-intelligence	https://web.archive.org/web/*/https://www.twilio.com/docs/lookup/v2-api/line-type-intelligence
10	TechCrunch — Surveillance vendor caught exploiting new SS7 attack to track phone locations (2025-07-18)	https://techcrunch.com/2025/07/18/a-surveillance-vendor-was-caught-exploiting-a-new-ss7-attack-to-track-peoples-phone-locations/	https://web.archive.org/web/*/https://techcrunch.com/2025/07/18/a-surveillance-vendor-was-caught-exploiting-a-new-ss7-attack-to-track-peoples-phone-locations/
11	Bundesnetzagentur — Identification requirements for prepaid SIM (TKG, since 2017)	https://www.bundesnetzagentur.de/DE/Fachthemen/Telekommunikation/OeffentlicheSicherheit/IdentverfahrenPrepaid/start.html	https://web.archive.org/web/*/https://www.bundesnetzagentur.de/DE/Fachthemen/Telekommunikation/OeffentlicheSicherheit/IdentverfahrenPrepaid/start.html
12	BOE — Ley 25/2007 de conservación de datos (Spain, SIM registration)	https://www.boe.es/buscar/act.php?id=BOE-A-2007-18243	https://web.archive.org/web/*/https://www.boe.es/buscar/act.php?id=BOE-A-2007-18243
13	e-Gov 法令検索 — 携帯電話不正利用防止法 (Japan, 2026 amendment context)	https://elaws.e-gov.go.jp/document?lawid=417AC0000000031	https://web.archive.org/web/*/https://elaws.e-gov.go.jp/document?lawid=417AC0000000031
14	Infobae — Registro de celular con CURP: deadline and line suspension (Mexico, 2026-06)	https://www.infobae.com/mexico/2026/06/15/registro-de-celular-con-curp-gobierno-aclara-que-no-existe-padron-nacional-de-telefonia-movil/	https://web.archive.org/web/*/https://www.infobae.com/mexico/2026/06/15/registro-de-celular-con-curp-gobierno-aclara-que-no-existe-padron-nacional-de-telefonia-movil/

Cora Aegis writes about Bitcoin privacy, self-custody, and digital sovereignty under a pseudonym — an arrangement this article should make self-explanatory. Sources for every statistic are listed above; the country table carries its own per-row sources and check dates. Corrections: cora@cypherpunkguide.com.

Passkey Recovery in 2026: 4 Platforms Compared

Sat, 01 Aug 2026 00:00:00 +0000

Passkeys are winning the ordinary login test. The FIDO Alliance’s 2025 Passkey Index reports a 93% sign-in success rate, compared with 63% for other methods, and an average login time of 8.5 seconds instead of 31.2. They are also resistant to phishing: a fake site cannot ask you to type a reusable passkey secret because there is no secret for you to type.

Recovery is the complication. A credential that is excellent during normal sign-in can still leave you dependent on the phone number, email account, cloud provider, trusted device, or paper code behind it. On August 1, 2026, I reviewed 25 official or primary documents across Google, Apple, Microsoft, GitHub, FIDO, and NIST, then applied one failure scenario to each ecosystem: your daily phone, computer, and carried hardware key are gone; only recovery assets stored elsewhere remain. The result was not one passkey-recovery process. It was a chain of two or three different recoveries, with different hard-lock conditions.

The useful question, then, is not simply whether passkeys are safer than SMS two-factor authentication (2FA, a second proof used after a password). They are safer against phishing. The useful question is whether you can recover the passkey provider and the account that accepted the passkey without circling back to the same lost device. This guide maps that dependency, corrects a Microsoft consumer-versus-enterprise mix-up already appearing in search results, and gives you a recovery-first migration drill. Do not remove your last working sign-in method while reading it.

Passkey Recovery Is Two Different Recoveries
#

Passkey recovery means either restoring a credential from its provider or regaining the target account and registering a new one. Different companies control those operations, and success in one does not guarantee the other.

A passkey is a cryptographic credential for one website or app. The website keeps a public key; your device or credential manager keeps the private key. WebAuthn, the web standard used by passkeys, binds that key to the real website domain. NIST SP 800-63B-4 therefore treats properly configured WebAuthn as phishing-resistant while manually entered one-time codes are not.

Two actors sit behind that simple login:

The credential provider stores or syncs the passkey. Apple Passwords with iCloud Keychain, Google Password Manager, Microsoft Password Manager, a third-party password manager, Windows Hello, and a hardware security key can all play this role.
The relying party is the website that accepts the passkey. GitHub is a relying party. Google and Microsoft can be both provider and relying party when you store a passkey with them for their own account.

That role split is the first finding of this audit. Popular comparisons put Apple, Google, Microsoft, and GitHub in four equal columns. They are not equal columns: Apple is mainly a provider in this question; GitHub is mainly a relying party. The mismatch matters most after loss.

Credential or path	Where the secret lives	Survives loss of one device?	If every device is gone	Main risk
Synced passkey	End-to-end encrypted credential manager	Usually, if another device is already signed in	Restore the provider account and satisfy its key-recovery check	Provider account becomes the recovery root
Device-bound passkey	One phone, computer, or hardware key	The passkey does not; account access may survive through another authenticator	Recover the target account by another path, then enroll a new passkey	Permanent credential loss
Recovery code	Paper or offline secure storage	Yes	Enter the one-use or long recovery code	Theft, loss, or storage beside the device
Email or phone recovery	Another account or carrier	Sometimes	Recover that channel first	Phishing, SIM swap, shared failure

FIDO’s synced-passkey deployment paper is careful on this point: sync improves the chance of surviving device loss, but users can still lose access to the provider or fail its restore process. “Synced” means a protected copy exists. It does not mean the provider will always be able to hand it back to you.

What Happens If Every Daily Device Is Gone?
#

If every daily device is gone, a synced passkey returns only through its credential provider, while a device-bound passkey is lost. The target account survives only if a recovery method stored elsewhere remains usable.

I applied that exact scenario to four ecosystems and recorded the evidence in the downloadable passkey recovery audit. The matrix is a documentation audit, not a staged lockout experiment: I did not remove authenticators from live accounts, and you should not either merely to reproduce it.

The recovery rows are limited to self-managed personal accounts. Administrator- or identity-provider-managed accounts—including Google Workspace, Managed Apple Accounts, GitHub Enterprise Managed Users, and Microsoft Entra identities—follow organization-specific policies outside this matrix. The Entra dates discussed later appear only to correct a consumer-versus-enterprise search-result mix-up.

Ecosystem	Role in this audit	Synced-passkey restore	Documented provider/account recovery controls	Survives daily-device loss if…	Failure / hard-lock boundary
Google personal account	Provider and relying party	Google Password Manager through Google Account plus its PIN or an eligible previously used device	Provider / Google Account: recovery information; eligible accounts may add a recovery contact	At least one recovery channel or contact remains accessible independently of the lost hardware	The Password Manager PIN cannot be recovered and all passkeys in that collection are reset; target sites then need separate recovery
Apple personal account	Primarily provider	iCloud Keychain secure recovery through Apple Account controls	Provider / Apple Account: standard account recovery, an accepted recovery contact, or the optional recovery-key path	The trusted number is recoverable, or a pre-registered contact or 28-character key is available outside the lost devices	Recovery-key path enabled, but no trusted device, no 28-character key, and—where Advanced Data Protection permits both—no usable recovery contact
Microsoft personal account	Provider and relying party	Synced manager by signing into its provider; Windows Hello or a security key may be device-bound	Provider / Microsoft Account: alternate security information or a 25-digit recovery code	An alternate channel remains accessible or the 25-digit code was stored offline	Two-step verification enabled and no alternate method; Microsoft says support cannot bypass it
GitHub personal account	Primarily relying party	The passkey provider restores a synced credential; GitHub does not hold that private key	Target personal account: 16 one-use codes, another passkey/security key, SSH key, personal access token (PAT), or verified device	An offline code or separately stored authenticator survives; SSH, PAT, and verified-device paths count only if they survived and GitHub accepts them for recovery	No passkey and no accepted recovery method; GitHub Support cannot restore access

The table exposes a second problem: “I use a passkey” does not tell you where it is stored. A Windows prompt may save one credential to Windows Hello on one machine and another to a synced password manager. A QR-code flow may use a phone only for that session or save the credential on it. Before planning recovery, open the passkey list at the website and the credential list in your provider. Record the provider and device, not just the website name.

The Four Recovery Paths, Platform by Platform
#

These four ecosystems can all support safe passkeys, but their recovery paths differ. Storage location, provider-account recovery, and an off-device backup decide whether loss becomes lockout.

Google personal accounts: the Password Manager PIN matters
#

Google Password Manager can sync passkeys across Android, Chrome, iPhone, and iPad. When a user first creates a passkey on a computer, iPhone, or iPad, Google may create a separate Password Manager PIN. Google’s PIN documentation says that PIN helps unlock passkeys on a new device and keeps the encrypted data unreadable to Google.

Adding a passkey to a personal Google Account does not automatically delete the existing password, recovery information, or other authentication factors. Google’s account-passkey guide also says a passkey can satisfy the second step during sign-in. Those facts belong together: one passkey sign-in may replace password-plus-code at login, while the older factors remain available for recovery unless you deliberately remove them.

The hard edge appears when the PIN is forgotten. Google says a user can reset it from a non-Android device where Google Password Manager passkeys were previously used. If every eligible device has been tried and the PIN still cannot be recovered, the documented fallback is Reset your passkeys. That action deletes all passkeys in Google Password Manager; it does not magically reissue them at each website. You must recover each relying-party account and create new credentials.

This is where I separated two rows that most summaries collapse. Google Account recovery can restore access to Gmail and the account itself through Google’s recovery process. Password Manager recovery restores the encrypted passkey collection. Recovering the account does not, by itself, prove you can decrypt that collection. For some 2-Step Verification lockouts, Google says review can take three to five business days in its troubleshooting guide. Google introduced Recovery Contacts for eligible personal accounts in 2025, but eligibility and rollout mean it should be treated as an optional extra, not a universal promise.

Apple personal accounts: iCloud Keychain recovery has conditions
#

Apple designed iCloud Keychain to sync passwords and passkeys end to end, meaning Apple servers transfer encrypted records without holding readable copies. Its Platform Security guide explicitly says keychain recovery is intended to work even when all of a user’s devices are inaccessible. That is a stronger and more precise statement than “your passkeys are in iCloud.”

It is also conditional. Apple’s passkey-security page says an all-devices-lost recovery can require the Apple Account password, a text message to the registered phone number, and the device passcode. The encrypted-recovery escrow service allows 10 authentication attempts; after the tenth failure, the escrow record is destroyed. “Recoverable after every device is lost” is therefore a designed path, not an unlimited guarantee.

The recovery still rests on the Apple Account. Apple’s standard process can use account credentials, a trusted phone number, device passcodes, and time-based account recovery. An account recovery contact can provide a six-digit code, and Apple allows up to five contacts. The contact cannot read the account; they only help with identity recovery.

Apple also says account recovery can take several days or longer, and that Support cannot shorten the wait. Treat it as a last-resort path, not same-day emergency access.

The optional recovery key deserves a red warning label. Apple’s recovery-key documentation says the 28-character key turns off standard account recovery. With Advanced Data Protection, Apple allows a recovery key and recovery contact together and says either may regain access. If you no longer know the account password, have no trusted device, cannot provide the key, and have no usable configured contact, Apple says you can be locked out permanently. A recovery key is a sovereignty tool only if it is stored outside the account it protects. Putting it in Apple Notes, iCloud Drive, or the Passwords app creates a closed loop; Apple explicitly warns against those locations.

Apple Account security keys are a separate feature from iCloud Keychain passkeys. Apple requires at least two physical keys and allows up to six; its security-key guide warns that losing every trusted device and every registered key can permanently lock the account. A spare key helps only when it is registered, tested, and stored apart from the daily devices.

Microsoft: personal accounts are not the Entra retirement story
#

Microsoft supports both synced and device-bound passkeys. Its consumer passkey guide defines a synced passkey as one restored through a credential manager and a device-bound passkey as one that is lost with the device unless another method exists. Microsoft Password Manager is rolling out for personal Edge profiles, while Windows Hello and physical security keys can remain local.

I checked the headline “Microsoft retires SMS in September 2026” against Microsoft’s source because it changes the advice. The September 1, 2026 rollout is an Entra ID tenant policy for organization-managed directories: users already enabled for SMS or voice are auto-enabled and nudged to register a passkey. Tenants can temporarily opt out until February 1, 2027, when Microsoft-provided Entra SMS and voice delivery retires. Microsoft separately says it is phasing out SMS codes for personal accounts, but that consumer page gives no September 2026 universal cutoff. Treating the two scopes as one would push consumer readers to remove a method on a false deadline.

Personal-account recovery has its own hard boundary. Microsoft says that if two-step verification is enabled and none of the alternate methods is accessible, support cannot help through the normal account-recovery form. Microsoft separately offers a 25-digit recovery code; its recovery-code guide says security changes under two-step verification can take 30 days. Generate and store the code before a crisis, not after the passkey device is gone.

GitHub personal accounts: many methods, no support override
#

This section covers personal account owners who manage their own credentials; GitHub’s passkey documentation does not extend this recovery model to enterprise-managed accounts. For personal accounts, GitHub accepts a passkey as both the password and 2FA proof for a browser sign-in. Synced-passkey recovery belongs to Apple, Google, Microsoft, or whichever provider stored the private key; GitHub’s passkey-management page tells users to recover synced credentials through that provider. A device-bound security key does not become recoverable merely because GitHub still lists it.

GitHub is unusually explicit about the other side of the chain. I counted 16 one-use recovery codes in its recovery-method documentation, plus SSH keys, personal access tokens, and verified devices as possible proofs. GitHub warns that a method may be ineligible even if it was used before—for example, an inactive SSH key—so availability must be checked rather than assumed. A recovery request using an accepted verified device or SSH key can take up to three business days.

The final line matters for these personal accounts: GitHub says Support cannot restore a 2FA account if every credential and recovery method is gone. Its lost-credentials guide calls the loss permanent. Save the codes offline and register more than one method before making the passkey your daily login.

The Recovery Paradox: Strong Login, Weaker Fallback
#

The recovery paradox is phishing-resistant sign-in backed by a weaker fallback. Attackers may target the email, phone, support process, or cloud account allowed to replace the passkey.

This does not make passkeys a mistake. It means the recovery system is part of authentication, not paperwork behind it. NIST’s recovery guidance treats account recovery as an authenticator-management event and requires recovery mechanisms appropriate to the account’s assurance level. A one-time recovery code is useful because it can be independent; it is not phishing-resistant if you type it into a fake site.

Recovery path	Independent of lost devices?	Phishing-resistant?	Best use	Hardening move
Offline recovery code	Yes, if stored off-device	No	Emergency access	Paper or encrypted offline copy; never cloud-only
Second hardware key	Yes, if stored elsewhere	Yes	High-value accounts	Register two; test both; keep one offsite
Synced passkey in the same provider	Partly	Yes for login	Daily convenience and single-device loss	Harden provider recovery and keep an outside method
Recovery email	Only if it is a separate account	No by itself	Broad account recovery	Different provider, passkey, and independent recovery
Recovery phone / SMS	Only if phone service survives	No	Last-resort compatibility	Set an account PIN with the mobile carrier; reduce exposure using a phone-number threat model
Recovery contact	Yes, if the person and their device remain available	No by itself	Apple/eligible Google account restoration	Choose deliberately; rehearse contact and identity checks

Portability is improving, but do not design around a future promise. FIDO published a Credential Exchange Format Proposed Standard in March 2026 for secure credential import and export. A standard on paper does not prove that your current providers can transfer every passkey today. Verify the export and import controls in both products before relying on a cross-provider move.

The privacy trade-off is equally plain. Sync protects against losing one device but concentrates recovery in a cloud account. Device-bound keys reduce that provider dependency but raise the cost of physical loss. This is the same distinction between operating something yourself and merely moving trust to a dashboard that I use in the five-layer sovereignty audit. Choose with a named adversary and a named failure, not with a slogan.

Run This Recovery-First Migration Drill
#

A safe migration starts with recovery. Inventory credential storage, add an off-provider method, test it safely, and only then demote SMS or a password.

List the account and the provider separately. Write GitHub — Google Password Manager, not merely GitHub — passkey. Mark each passkey as synced, device-bound, or unknown. Unknown means do not remove anything yet.
Protect the provider account first. A synced passkey is only as recoverable as Apple, Google, Microsoft, or your third-party manager. Update its recovery email, trusted phone, recovery contact, and independent authenticator. Apply the same adversary-first method used in our AI-age threat model.
Create one recovery path outside that provider. Depending on the service, use printed recovery codes, a second hardware key stored elsewhere, or an SSH key whose private key or tested backup is on a separate device and that the service still accepts for recovery. Do not store the only copy inside the same cloud account.
Test without destroying anything. Open a private browser window or a different browser profile, start a sign-in, and confirm that the spare method is offered. Use a non-destructive status check where available. If a test consumes a one-use code, mark it used and immediately replace it or regenerate the stored set. Do not trigger a full account-recovery flow, delete the primary passkey, wipe a device, or sign out of every trusted session merely as a drill.
Record the restore instructions offline. Include the provider name, the target account, where the spare is stored, and the official recovery URL. The discipline is similar to the recovery rehearsal in the first-Bitcoin custody drill: a backup you have never tested is a belief, not a control.
Demote the old method one account at a time. Prefer the passkey for daily sign-in. Remove SMS only after the independent path succeeds and only if the service does not require the number for recovery. Recheck after changing phones, password managers, Apple/Google/Microsoft accounts, or security keys.

The order matters. Removing SMS first and “adding a spare later” creates a period in which a dropped phone, broken screen, lost key, or mistaken provider choice can become a permanent lockout. Security work should reduce simultaneous failure modes, not manufacture one.

Bottom Line — Should You Replace SMS Now?
#

Use passkeys for daily sign-in, but demote SMS only after another path passes a safe fresh-browser check. Aim for phishing-resistant login plus recovery independent of one device or cloud account.

The normal-login evidence is strong: the FIDO data above and Google’s 2024 report of more than 1 billion authentications across 400 million accounts and 50% faster sign-ins measure normal use, not recovery after device loss.

The loss case is not one product feature. Google Password Manager may require its PIN; Apple may require account recovery, a contact, or a recovery key; Microsoft personal accounts have alternate security information and a 25-digit code; GitHub depends on its recovery codes or another pre-registered proof. One phrase — “backed up to the cloud” — hides all of those conditions.

Start with the account whose loss would hurt most. Map provider and relying party, store one recovery method outside both, test it, then move to the next account. That is slower than pressing “use a passkey” everywhere in one afternoon. It is also how you get the phishing protection without turning a lost bag into an identity crisis.

Key Takeaways

Passkey recovery is two recoveries: restore the credential provider or recover the target account and register a new passkey; they are not the same process.
Normal sign-in is better: the FIDO Alliance reported 93% passkey success versus 63% for other methods and 8.5-second versus 31.2-second average login in 2025.
Sync is conditional durability: it survives device loss only if you can recover the provider account and its encrypted-key control; device-bound passkeys need a separate spare.
Platform traps differ: Google can delete all passkeys in its Password Manager collection on a reset; Apple’s 28-character recovery key disables standard recovery while Advanced Data Protection can preserve a configured contact; Microsoft 2SV has no support override; GitHub issues 16 one-use codes.
Migration order is the control: inventory, harden the provider, create an outside recovery path, test it, document it, and only then demote SMS one account at a time.

Frequently Asked Questions
#

Are passkeys safer than SMS two-factor authentication?
#

For phishing, yes. A WebAuthn passkey is bound to the real website domain, so a fake site cannot collect a reusable login secret. An SMS code can be typed into a fake site or intercepted after a SIM swap. Recovery remains separate: if the service still accepts SMS to replace a lost passkey, that recovery path retains SMS risk.

What happens to my passkeys if I lose my phone?
#

Synced passkeys may return after you recover and unlock their credential manager on another device. A device-bound passkey stored only on the phone is lost. In either case, a second authenticator or the website’s account-recovery method determines whether you can regain access without that phone.

Can Apple, Google, or Microsoft read my synced passkeys?
#

Their platform documents describe the passkey collections as end-to-end encrypted or protected so the provider does not receive the private key in readable form. That does not remove provider dependence: the provider still operates the account, synchronization service, recovery rules, and software that controls access to the encrypted collection.

Should I delete my password and SMS number after adding a passkey?
#

Not immediately. First add an independent recovery method and test it from a fresh browser without deleting anything. Then remove or demote weaker methods one account at a time if the service allows it and your recovery path does not depend on the same device or provider.

Can support restore my account if every passkey and recovery code is lost?
#

Do not assume so. GitHub says Support cannot restore a 2FA account with no accepted recovery method. Microsoft says its personal-account recovery form cannot help when two-step verification is on and no alternate method is accessible. Prepare the independent factor before the loss.

References
#

Cora Aegis

Cora Aegis writes privacy-first OPSEC guidance at CypherpunkGuide. For this article, she applied one daily-devices-lost scenario with offsite recovery assets preserved to four ecosystems, checked 25 official and primary references, and published the resulting recovery-dependency matrix as a downloadable audit.

More about Cora Aegis ->

Password Manager Migration: Bitwarden vs KeePassXC (2026)

Mon, 03 Aug 2026 00:00:00 +0000

A note on funding: CypherpunkGuide carries no surveillance advertising—no ad networks, tracking pixels, or sponsored content. It is funded by transparent streams: reader donations now; subscription and editorially-aligned affiliate later. We answer to our readers, not to advertisers.

Browser password managers are not automatically unsafe. NIST SP 800-63B-4 directs conforming verifiers to allow password managers and autofill because they help people use stronger, distinct passwords. The reason to move is narrower: your threat model—what you need to protect, from whom, and which failure could lock you out—may call for a vault that is independent of one browser account, works across browsers, gives you a different recovery model, or lets you control the encrypted database.

Migration creates the sharper risk. On August 3, 2026, I reviewed the top 5 Google results, four readable competitor pages averaging 2,512 words, and official migration, authentication, and credential-exchange documentation from Chrome, Edge, Firefox, Bitwarden, KeePassXC, NIST, and FIDO. Google AI Mode already produced a complete-looking three-step answer: export a CSV, import it, compare the row count, delete the file. That answer misses the failure that matters.

I tested two synthetic 12-record vault exports with our password-redacting audit tool. Both files had 12 rows, yet only 11 records matched: one source credential was gone and another had been duplicated. The audit returned 91.7% coverage and HOLD without printing a URL, username, password, or secret-derived fingerprint. This guide turns that result into a seven-step migration protocol. Use fake data when learning the tools, keep the source vault intact during the changeover, and never upload a real password export to an online converter or AI assistant.

A Browser Password Manager Is Not the Real Problem
#

A password manager is software that stores and fills account secrets. The meaningful choice is not “browser equals unsafe, dedicated app equals safe”; it is which trust, synchronization, recovery, and lockout risks fit the failures you actually face.

Browser managers place saved passwords behind documented device and account controls, whose exact recovery and local-access behavior differs by browser. A dedicated manager changes who operates sync, how recovery works, how many browsers and platforms share the vault, and whether you manage the encrypted file yourself. It does not make a compromised, unlocked computer harmless. Any manager must make a credential usable when you sign in.

Move for a named reason:

Browser independence: you use several browsers or want changing browsers to stop being a credential migration.
Recovery separation: you do not want the same Google, Microsoft, or Mozilla account to control both browsing data and password recovery.
Local custody: you want the encrypted database file, backups, and sync choice under your control.
Family or team workflows: you need managed sharing instead of copying passwords through chat or email.
Auditability: you want a clearer inventory, health report, or migration export for a tested recovery plan.

Do not move merely because a headline says browser passwords sit in “plaintext RAM.” A usable password is necessarily decrypted somewhere on an unlocked computer or phone, and changing vault brands does not remove malware, screen capture, malicious extensions, or physical access from the risks you must plan for. The migration should reduce a specific dependency rather than promise immunity.

This is also why passkeys belong in a separate inventory. A passkey is a site-bound cryptographic credential, not another password row. Before changing managers, use the passkey recovery drill to record which passkeys are synced, device-bound, or recoverable through the website.

Bitwarden vs KeePassXC: Choose by Failure Mode
#

Bitwarden favors automatic multi-device sync and official mobile clients. KeePassXC favors a local KDBX encrypted database file, but makes synchronization, backups, conflict handling, and recovery your responsibility.

Bitwarden imports browser data through its web, extension, desktop, mobile, or command-line clients. Its Chrome and Edge import guide says imported data is encrypted locally before it is sent to the server. That reduces server-side visibility, but your Bitwarden account, devices, master-password practice, second factor, and service availability remain part of the recovery chain.

On supported desktop installations, the same guide offers direct import from a compatible Chromium browser without asking you to create an export file. The official-download Windows and macOS apps and the Linux AppImage support it; app-store builds do not. On Windows, the documented bitwarden_chromium_import_helper.exe may trigger User Account Control (UAC, the operating-system approval prompt) or security-monitoring warnings. Verify the installer and signature first, start the import yourself, and cancel an unexpected prompt rather than trusting a process name alone.

KeePassXC stores credentials in an encrypted KDBX database and does not include its own cloud synchronization service. Its official documentation describes storing the file locally or placing it in a sync location you choose. This removes a mandatory vendor sync account, but it makes file conflicts, backups, off-device copies, and database-key recovery your job.

Decision	Bitwarden	KeePassXC	Failure to plan for
Sync model	Managed encrypted sync	User-managed KDBX file and optional third-party sync	Service/account recovery vs file loss or sync conflict
Best fit	Several devices, mobile access, sharing, low maintenance	Desktop-first use, local control, custom backup design	Choosing convenience or custody without accepting its operations
Migration import	Browser-specific CSV import; direct paths on supported platforms	CSV wizard with column preview and mapping	Duplicate creation vs wrong column mapping
Recovery root	Account credentials, second factor, and recovery plan	Database file, master key, optional key file/hardware challenge, and backups	Keeping every recovery component on one device
Passkeys and time-based one-time passwords (TOTP)	Inventory support and plan limits separately; a browser CSV proves neither	Inventory support and site compatibility separately; a browser CSV proves neither	Assuming password rows prove non-password credential transfer
Operational burden	Provider operates sync infrastructure	You operate storage, sync, backups, and conflict handling	Treating “local” as “automatically backed up”

I also downloaded the official KeePassXC 2.7.12 portable release dated March 10, 2026 before designing the audit. Its ZIP matched the publisher-listed SHA-256 86718f7f47d7ca7f287de0260c567644c846e2a3e51ad2f93a76605178be9850, and Windows Authenticode code-signature validation reported DroidMonkey Apps, LLC as a valid signer for the extracted KeePassXC.exe. That verifies the files I examined; it does not certify every mirror, future build, or configuration. The same 2.7.12 release notes warn that a passkey flag correction can make some existing passkeys unacceptable to a relying site. If passkeys are in scope, test them individually while the source login path remains available.

The decision is reversible before the changeover. Install the destination from its official source, create only a synthetic entry, practice locking and recovery, and confirm that your other devices behave as expected. Do not delete browser credentials to create a dramatic test.

What a Browser CSV Carries—and What It Cannot Prove
#

A browser password CSV is an unencrypted transfer file. It can carry login fields, but by itself it cannot prove that passkeys, TOTP seeds, attachments, cards, identities, custom fields, history, or recovery material moved.

Google documents url, username, and password as the minimum Chrome CSV fields, then warns that anyone with the undeleted file can read the passwords. Those are password-row fields, not a guarantee about passkeys or another manager’s import behavior. Microsoft gives the same plaintext warning for Edge exports, and Mozilla says a Firefox export must not be uploaded, emailed, or shared.

The transport limits differ from the destination’s limits. Bitwarden’s own CSV schema can contain login_totp, but its custom-import documentation says CSV covers logins and secure notes; identities and cards require JSON, while attachments must be handled separately. KeePassXC warns that its CSV exports cannot represent attachments, advanced attributes, Auto-Type settings, or custom icons. A browser export cannot carry data that the browser never placed in the file.

Layer to inventory	Password CSV can establish	What must be checked separately	Safe evidence
Password logins	URL, username, password, sometimes name/note	duplicates, blank values, changed URLs, source-specific fields	secret-redacting content comparison
Passkeys	Do not infer coverage from password rows	provider, website, synced/device-bound state, portability	provider and relying-party credential lists
TOTP seeds	Only if the source format exports them and the destination maps them	code generation after import, clock, recovery codes	non-destructive test on a low-risk account
Attachments / custom fields	Often absent or limited	count, type, and manual transfer	destination item inspection
Cards / identities / secure notes	Browser export may not contain them	product-specific JSON or direct transfer support	separate type-by-type count
Recovery material	Should not be assumed part of the vault	second factor, recovery code, emergency access, database backup	fresh-browser recovery check with source intact

Credential Exchange Protocol (CXP) can remove the plaintext-file step when both products support it. Bitwarden’s current guide documents FIDO CXP paths on supported mobile platforms, including password and passkey transfer from compatible apps. That is a welcome improvement, not a universal instruction for desktop Chrome, Edge, Firefox, Bitwarden, and KeePassXC. Check both the source and destination apps and the platform you are actually using.

If CXP is available, use it and still perform a type-by-type inventory. “No CSV” removes one exposure window; it does not prove that every credential type or recovery path arrived.

The 12-to-12 Row-Count Trap
#

Equal row counts can hide unequal vaults. A destination with one missing credential and one duplicate still reports the same total as the source, so migration proof must compare content and credential types—not totals alone.

The bundled experiment uses only reserved domains and obviously fake passwords. The synthetic browser source contains 12 unique login records. The synthetic Bitwarden-shaped destination also contains 12 rows, but it deliberately omits the admin login and duplicates a different record.

I ran migration-audit.py against both files. The script normalizes supported browser, Bitwarden, and KeePassXC CSV headers, compares URL/username/password tuples as in-memory SHA-256 fingerprints, and does not write or emit those fingerprints. It does not provide secure-memory zeroization; process memory is reclaimed when the tool exits. The published audit result contains aggregate data only.

For this tool, PASS means only that the URL/username/password tuples match. It is not a certificate that notes, folders, custom fields, passkeys, TOTP, attachments, identities, cards, or recovery material moved.

Audit check	Result	What a row-count-only check would say
Source rows	12	looks complete
Destination rows	12	looks complete
Exact credential matches	11/12 (91.7%)	invisible
Missing source credentials	1	invisible
Unexpected destination credentials	1	invisible
Destination exact duplicates	1	invisible
Audit decision	HOLD	false PASS

The test does not claim to reproduce every vendor importer. It demonstrates a logical failure in the verification method: equal totals are compatible with loss. Bitwarden makes the duplicate side especially relevant because its official import FAQ says every import creates new records even when matching items already exist.

Use the script locally only. A real CSV contains the keys to your accounts. Do not attach it to a support ticket, paste it into an AI chat, place it in this repository, or use a web-based “migration checker.” If you do not trust a comparison script with live secrets, compare small samples manually on the offline device and keep the source intact longer.

A Seven-Step Password Manager Migration
#

A safe password manager migration is a controlled changeover: inventory credential types, prepare recovery, verify the destination, transfer once, compare contents, test ordinary use and recovery, then remove plaintext and retire the old manager.

Inventory by type, not one grand total. Record password logins, passkeys, TOTP entries, secure notes, attachments, identities, cards, and recovery codes separately. Start with high-consequence accounts: primary email, password-manager account, mobile carrier, finance, domain registrar, and cloud storage. Use the same identity-separation logic as the social media self-audit.
Identify what recovery ultimately depends on before choosing the product. For Bitwarden, document the account email, master password, working second factor, and two-step login recovery code. That code disables two-step login only; using it still requires the master password. Bitwarden’s forgotten-master-password guidance says its team cannot retrieve an individual vault when no preconfigured alternative remains, so test any documented alternative access before relying on it. For KeePassXC, document the KDBX location, master key, optional second component, at least one off-device backup, and conflict procedure. Do not keep every component on the laptop you carry.
Verify the destination installer and practice with fake data. Download from the official domain or signed release, validate the checksum or signature the publisher provides, and create a synthetic vault. Confirm lock, unlock, browser integration, and backup restoration before real export.
Choose the least-exposing documented transfer. Prefer a verified direct import or CXP when the source, destination, installer channel, credential type, and active platform all support it. Bitwarden’s supported desktop direct import avoids a manually exported browser CSV; it does not prove that passkeys or every other type moved. If a file is required, create it once on a trusted device in encrypted local storage that is not automatically synchronized. Close chat, cloud-drive, backup, indexing, and editor workflows that might copy it. Note the exact path. Never use real secrets in the Cora browser, an AI prompt, or an online converter.
Transfer once and inspect the result. Select the exact source or direct-import path. In KeePassXC, review the CSV column preview and mapping before committing. In Bitwarden, direct and file imports do not check for duplicates. Stop on errors; do not repeatedly run the import to see whether it “takes.”
Prove content and types. Compare credential contents without printing them, inspect every high-consequence account manually, and count passkeys/TOTP/attachments separately. Equal row counts are only one signal. The decision is HOLD if any source credential is missing, any unexpected duplicate appears, or any non-password type lacks a documented transfer path.
Test, observe, then retire. Sign in to several low-risk accounts and every high-consequence account from a fresh browser profile. Exercise every repeatable recovery step without deleting the source. For a one-use code, confirm that both the stored copy and official procedure are accessible; call it functionally tested only if you deliberately use it and then save the regenerated or replacement code. Keep the old vault read-only through a short observation window. Only after success should you disable browser saving, remove the source records, and, if a file transfer was used, delete every plaintext copy you can identify.

The order protects availability. If an import is wrong, the source remains the rollback path. If recovery is wrong, the active sessions remain a repair path. If the CSV was copied into a synced folder, you detect that before treating one local delete as complete.

Do not change recovery phone numbers casually during the same migration. A number can still be an account-recovery dependency even when it is no longer used for daily login; map that relationship with the phone-number privacy model.

Delete the CSV Without Promising Impossible Erasure
#

Deleting a plaintext CSV reduces exposure, but a delete command does not prove every physical, synced, indexed, backed-up, or preview copy is gone. The strongest control is to prevent extra copies before export and minimize the file’s lifetime.

Google, Microsoft, Mozilla, Bitwarden, and KeePassXC all warn that password exports are readable. Microsoft specifically recommends SHIFT+DELETE after Edge migration. That bypasses the Recycle Bin on Windows; it should not be described as a forensic guarantee on solid-state drives, cloud-sync histories, backups, or storage you do not control.

Use this cleanup checklist:

Location	Check	Action
Chosen export path	exact filename and modified time	delete after audit and successful recovery test
Downloads / Desktop / Documents	accidental second export	remove only confirmed copies
Cloud-sync folder and version history	whether the path was synchronized	remove remote versions using that provider’s documented controls
Recycle Bin / Trash	whether normal delete was used	empty the confirmed item; do not assume this erases storage media
Editors, spreadsheets, previews	recent-file list, autosave, temporary copy	close before export; clear confirmed temporary artifacts
Backups and snapshots	whether the file existed during a backup window	follow retention policy; rotate exposed passwords if deletion cannot be established

If a real CSV may have reached email, chat, an AI service, a public repository, or an untrusted converter, treat the passwords as disclosed. Preserve evidence, change high-consequence credentials first, revoke sessions where appropriate, and work down the inventory. The destination vault cannot make an already copied secret private again. Our AI assistant privacy audit explains why a chat box is a record, not a secure transfer channel.

Bottom Line: Which Migration Path Is Right for You?
#

Choose Bitwarden when managed sync and lower daily maintenance outweigh service-account dependence. Choose KeePassXC when local custody outweighs the work of operating backups and sync. Both require content and recovery checks.

Your priority	Better starting point	Required safeguard
Automatic multi-device use	Bitwarden	master-password plan, separate 2FA recovery code, and tested access
Local encrypted database	KeePassXC	off-device KDBX backup and tested restore
Lowest migration exposure	Documented direct import or CXP	verify source, destination, installer channel, platform, and credential-type scope
Browser-only simplicity	Keep the browser manager	strong device/account security and tested recovery; migration is not mandatory
High-risk or complex vault	Staged migration	small batch, manual high-value review, longer read-only rollback window

The defensible move is not “export and hope.” It is: know what exists, know what the file cannot represent, import once, compare contents without disclosing them, test recovery, and then retire the old path. The product choice matters. The changeover method matters more.

Key Takeaways

The choice is conditional: Bitwarden manages encrypted sync; KeePassXC gives you a user-managed KDBX file and the backup burden that comes with it.
Avoid the file when support is explicit; contain it when required: a documented direct import or CXP can remove the manual CSV step, but it does not prove every credential type moved. If a CSV is required, treat it as readable plaintext until every identified copy is removed.
Counts can lie: our synthetic 12-to-12 test matched only 11 credentials, producing 91.7% coverage, one missing record, and one duplicate.
Credential types differ: a password-row count cannot prove migration of passkeys, TOTP, attachments, cards, identities, or recovery material.
Changeover order protects access: inventory, prepare recovery, verify software, transfer once, compare contents, test, and only then disable the old manager and remove any plaintext copies.

Frequently Asked Questions
#

These answers cover the migration boundaries readers most often miss: product choice, row-count verification, passkey coverage, plaintext cleanup, and the limits of deleting a CSV from modern storage.

Is Bitwarden safer than Chrome Password Manager?
#

Not categorically. Bitwarden changes the trust and recovery model by separating the vault from the browser ecosystem and supporting several clients and sharing workflows. Chrome may be simpler for one Google-centered user. Compare risk on unlocked devices, account recovery, sync dependence, and the cost of a failed migration rather than treating the product name as a security score.

Is KeePassXC safer than Bitwarden because it is offline?
#

KeePassXC removes a mandatory cloud-sync account, but its local-file model also makes you responsible for the KDBX file, backups, synchronization, conflicts, and recovery. A single local copy is not sovereignty; it is a single point of failure. Bitwarden’s managed sync has a different risk, not automatically a greater one.

Can I delete the CSV as soon as the import count matches?
#

No. Equal counts can hide one missing item plus one duplicate. Compare credential contents, inspect high-consequence accounts, count passkeys and TOTP separately, and test ordinary login and recovery before deleting the transfer file or source vault.

Will Chrome’s password CSV include my passkeys?
#

Do not use the password-row count as proof. Google’s documented CSV minimum is URL, username, and password, while passkeys have their own provider and portability rules. Inventory passkeys separately and use CXP only when both the source and destination explicitly support the transfer on your platform.

Should I securely overwrite a password CSV on an SSD?
#

Do not promise that one overwrite or delete command erases every SSD, sync, backup, or preview copy. Prevent copies by using controlled encrypted local storage, keep the file for the shortest practical time, delete confirmed instances, inspect sync history, and rotate credentials if exposure cannot be ruled out.

References
#

These twelve primary and official sources support the migration claims as of August 3, 2026. Eleven have exact independent replays; the live Edge source had no exact snapshot as of that date, and the gap is stated instead of hidden behind a wildcard.

#	Source	URL	Archived
1	NIST — SP 800-63B-4	https://pages.nist.gov/800-63-4/sp800-63b.html	https://web.archive.org/web/20260802091116/https://pages.nist.gov/800-63-4/sp800-63b.html
2	Google Chrome Help — Import or export passwords and passkeys	https://support.google.com/chrome/answer/13068232?hl=en-GB	https://web.archive.org/web/20250409111740/https://support.google.com/chrome/answer/13068232?hl=en-GB
3	Microsoft Support — Export passwords in Edge	https://support.microsoft.com/en-us/edge/export-passwords-in-microsoft-edge	No exact snapshot found (checked 2026-08-03)
4	Mozilla Support — Export login data from Firefox	https://support.mozilla.org/en-US/kb/export-login-data-firefox	https://web.archive.org/web/20260621011944/https://support.mozilla.org/en-US/kb/export-login-data-firefox
5	Bitwarden — Import from Chrome, Edge, and Chromium browsers	https://bitwarden.com/help/import-from-chrome/	https://web.archive.org/web/20260713195219/https://bitwarden.com/help/import-from-chrome/
6	Bitwarden — Import and export FAQs	https://bitwarden.com/help/import-faqs/	https://web.archive.org/web/20260622160725/https://bitwarden.com/help/import-faqs/
7	Bitwarden — Import from a custom file	https://bitwarden.com/help/condition-bitwarden-import/	https://web.archive.org/web/20260708232651/https://bitwarden.com/help/condition-bitwarden-import/
8	KeePassXC — User Guide	https://keepassxc.org/docs/KeePassXC_UserGuide	https://web.archive.org/web/20260728213815/https://keepassxc.org/docs/KeePassXC_UserGuide
9	KeePassXC — Releases	https://github.com/keepassxreboot/keepassxc/releases/tag/2.7.12	https://web.archive.org/web/20260728142825/https://github.com/keepassxreboot/keepassxc/releases/tag/2.7.12
10	FIDO Alliance — Credential Exchange Specifications	https://fidoalliance.org/specifications-credential-exchange-specifications/	https://web.archive.org/web/20260711082529/https://fidoalliance.org/specifications-credential-exchange-specifications/
11	Bitwarden — Recovery Code for Two-Step Login	https://bitwarden.com/help/two-step-recovery-code/	https://web.archive.org/web/20260515192732/https://bitwarden.com/help/two-step-recovery-code/
12	Bitwarden — Forgotten Master Password	https://bitwarden.com/help/forgot-master-password/	https://web.archive.org/web/20260729154628/https://bitwarden.com/help/forgot-master-password/

Cora Aegis

Cora Aegis writes privacy-first OPSEC guidance at CypherpunkGuide. For this article, she reviewed five Google competitors and seven primary documentation families, verified a signed KeePassXC release, and built a password-redacting 12-record migration audit.

More about Cora Aegis ->

Chrome AI Model: Audit, Remove, or Keep It (2026)

Thu, 06 Aug 2026 00:00:00 +0000

A note on funding: CypherpunkGuide carries no surveillance advertising—no ad networks, tracking pixels, or sponsored content. It is funded by transparent streams: reader donations now; subscription and editorially-aligned affiliate later. We answer to our readers, not to advertisers.

The “Chrome quietly installed a 4 GB AI model” story contains a real control question wrapped in an unreliable constant. Chrome can download an on-device model: files containing the numerical patterns an AI learned, used to produce a result on your computer instead of a remote server. Google’s documentation describes different eligible variants, including example 2-billion- and 4-billion-parameter models. A parameter count is not a file-size measurement, and the installed size changes with updates.

On August 6, 2026, I checked the top five Google results for remove Chrome on-device AI model 2026, plus Google AI Overview and AI Mode. The generated answers mixed the supported setting with manual deletion, experimental flags, managed policy, and a launch shortcut without separating their scope.

I mapped seven controls across three layers: local storage and compute, cloud or hybrid AI, and browser-vendor trust. I also tested a read-only audit tool against four synthetic model states. It returned 4/4 expected results without reading model contents, discovering profiles, printing the supplied path, deleting files, or changing policy. The control matrix and test output are published here.

The result is not a campaign for or against Chrome. It is a way to choose the smallest control that matches the boundary you actually want.

What Chrome’s “4 GB AI Model” Actually Is
#

Chrome’s local foundational model, a general-purpose base AI model, is a separately managed browser component. “4 GB” is a reported figure, not a permanent size, universal download, or reliable detection rule.

Google’s built-in model lifecycle documentation distinguishes the browser from the model component. Chrome can select a model variant for the device, download it in the background or when a supported feature requests it, update it independently, and remove it when storage pressure or policy requires. Google gives 2B and 4B parameter models as examples of variants; neither label means “2 GB” or “4 GB.”

Eligibility also matters. Google’s developer requirements currently specify at least 22 GB of free space on the volume containing the Chrome profile, an unmetered network, and either a GPU with more than 4 GB of video memory or a CPU path with at least 16 GB of RAM and four cores. These are platform requirements for current built-in AI APIs, not proof that every qualifying installation immediately downloads the same file.

Downloads have several triggers. A consumer feature may start background management; a built-in web API can request the model; and a documented scam-detection condition can make an availability check trigger it. Neither “every machine gets it at installation” nor “nothing downloads until I ask” is reliable.

Common claim	Verified behavior as of August 6, 2026	Practical implication
Every Chrome install gets a 4 GB model	Eligibility, trigger, variant, and exact size vary	Check your own installation instead of hunting for one number
A 4B model occupies 4 GB	“4B” is a parameter count, not a byte count	Measure files; do not convert the name into storage
The model only downloads after an explicit AI prompt	Consumer features and API lifecycle events can initiate management	Treat enabled features and policy as the durable controls
Deleting the weights stops it permanently	A managed component can be downloaded again while it remains allowed	Use the setting or targeted policy, then verify
The local model sends nothing to Google	Local AI processing can stay on-device, but a feature may use cloud or hybrid stages	Audit the complete feature, not only its AI model

This distinction matters for both privacy and security. Chrome 137 added Gemini Nano as an additional on-device signal for some suspected tech-support scams. Google’s security description says a signal produced by the language model is sent to Safe Browsing for a final verdict when the user has opted into Enhanced Protection. Standard Protection users can later benefit when confirmed threats are added to blocklists. The model execution is local; that Enhanced Protection pipeline is hybrid.

Audit the Model Before You Change Anything
#

An audit should answer three separate questions: is the local component present, which Chrome version and feature caused the concern, and are any cloud or hybrid AI paths enabled? One folder answers only the first question.

Start with Chrome’s own internal inventory. Enter chrome://on-device-internals in the address bar. Record the browser version, model status, and reported size or component information visible in your build. Do not paste diagnostic contents into a public forum or AI chat; internal pages can expose environment details that are unnecessary for getting general help.

For a second, read-only desktop measurement, point the bundled script at a user-data root that you explicitly provide. This is Chrome’s top-level local folder containing its profiles:

python chrome-ai-model-audit.py "C:\Path\To\Chrome User Data"

The tool looks only for the OptGuideOnDeviceModel child directory. It skips linked directories, counts regular files and bytes, notes whether weights.bin exists, and prints a fixed label instead of your path. It cannot prove that a feature used the model or assess cloud AI.

You can reproduce the synthetic test without pointing the tool at Chrome:

python chrome-ai-model-audit.py --self-test

Synthetic state	Expected classification	Observed result
Component directory absent	`absent`	PASS
Directory present but empty	`present-empty`	PASS
Metadata present without weights	`present-without-weights`	PASS
Metadata and synthetic weights present	`present-with-weights`	PASS

The script does not enumerate profiles, print Windows usernames, hash model files, or open profile databases. Those actions collect more information than this audit needs.

Name the concern before changing anything. Disk use and local compute point to the On-device AI setting. Page-content disclosure requires feature-by-feature cloud review. Account integration needs separate AI, search, and sync controls. If the concern is Google’s control over browser code and updates, only a browser migration changes that vendor boundary. Deleting the folder alone is not a durable answer to any of them.

Remove It With the Supported Control
#

For personal Chrome, use the On-device AI setting. For organization-managed Chrome, use the targeted local-model policy. Manual deletion, global component blocking, and flags are not equivalent.

Google’s current consumer instructions place the control under Settings > System > On-device AI. A July 2026 Chromium change is moving that control toward Settings > AI in later builds, so search Settings for “On-device AI” if the menu has moved. Turning the switch off prevents the local model from being used and removes an installed model; turning it back on permits a later download. Google does not publish a universal promise that every byte disappears the instant you click, so verify after Chrome has had time to apply the change.

Use this sequence:

Update Chrome first. Keep browser security updates enabled while you make the AI decision. Record the version you tested.
Inspect before removal. Open chrome://on-device-internals and, if useful, run the read-only audit against the Chrome data folder you chose.
Use the consumer switch. Open Chrome Settings and search for On-device AI. In current Help it is under System; future builds may place it under AI. Turn it off.
Use targeted policy only on managed browsers. Administrators can set the browser-level GenAILocalFoundationalModelSettings to 1 to prevent download and delete an existing model. An unset value or 0 permits eligible automatic management. This is not an account-level policy delivered through Google’s cloud management.
Restart and verify. Recheck the internal page and local inventory. Treat a delayed status change as something to observe, not a reason to start deleting arbitrary profile data.
Audit cloud AI separately. Review AI Mode, Gemini in Chrome, writing assistance, extensions, search, sync, and organization policy.

Control	Actual target	Removes local model	Stops cloud AI	Collateral effect	Use
On-device AI setting	local foundational model	Yes	No	model-dependent features become unavailable	supported consumer control
`GenAILocalFoundationalModelSettings=1`	local foundational model	Yes	No	model-dependent features become unavailable	managed browser control
Manual folder deletion	current local files	Not reliably	No	profile damage if the target is wrong	avoid; not a documented control
`ComponentUpdatesEnabled=false`	many components covered by policy	Not guaranteed	No	High	avoid for a single-model decision
AI-related flags	temporary experiments	Not guaranteed	Not guaranteed	Unpredictable	testing only
`AIModeSettings=1`	AI Mode entry points in Chrome	No	No; hides specified entry points only	Low	managed-profile integration control
Switch browser	vendor and service boundary	Not applicable	Depends	High	when Google trust is the concern

Do not disable all component updates to block one model. Google’s ComponentUpdatesEnabled policy covers many components unless the policy excludes them, while some critical data-only security components still update. It is not the Chrome binary updater and is too broad for this task.

Do not depend on a long chrome://flags list. Chromium documents flags as experiments, and Chrome warns they can lose data or compromise security or privacy. Flags can disappear; supported settings have a defined scope.

What Removal Does Not Disable
#

Turning off On-device AI controls the local foundational model. It does not disable cloud writing tools, Gemini integrations, extensions, Safe Browsing data flows, browser sync, search requests, or the Google account relationship.

The phrase “runs locally” describes where one AI task happens, not everything the surrounding feature can do. A browser can run the model locally and still send a derived risk signal to a cloud service. Another feature can send selected text, page context, or a URL to a remote model. A third can be an extension with its own provider and privacy policy.

Layer	Examples	Data/control question	Correct control
Local	base model files, local summarization or classification	Is storage or compute on this device acceptable?	On-device AI setting or targeted policy
Hybrid	local scam classification plus Safe Browsing verdict	What derived signal leaves, under which protection mode?	feature and Safe Browsing review; do not infer from model location
Cloud	Help me write, Gemini in Chrome, AI Mode	Are prompts, page context, URLs, or account data sent to a provider?	feature-specific or managed-profile controls
Extension	third-party assistant or sidebar	Which extension can read the page and where does it send data?	extension removal/permissions and provider policy
Vendor	updates, defaults, sync, service endpoints	Do you accept the browser operator as a trusted party?	browser choice and account/service configuration

Google’s Help me write documentation says entered text, surrounding page content, and the page URL are sent to Google. The separate AI Mode policy covers specified address-bar and New Tab entry points, not the AI Mode website or every Google AI integration. Removing local model files changes neither.

This separation is useful beyond Chrome. The AI assistant privacy audit gives you a repeatable way to test retention, account, and data-flow claims. The AI-age threat model separates an AI model from the applications, agents, and people that can act on its output.

Keep It, Remove It, or Change Browsers?
#

Keep the model when its local features fit what you need to protect and from whom. Remove it for storage or local-compute concerns. Change browsers when the objection is Google’s role.

There is a real trade-off. A local model can reduce cloud exposure for a supported local-processing path and contribute to protections such as scam detection. It also consumes disk, can use local compute, expands browser complexity, and is managed by a vendor whose defaults you may not accept. Removing it is reasonable, but “less code on disk” does not automatically mean “more secure in every situation.”

Your boundary	Sensible starting action	What it does not prove
I value eligible local features and accept the resource cost	Keep On-device AI enabled; review each feature	that every surrounding data flow is local
I reject local model storage or compute	Turn On-device AI off and verify	that Chrome cloud AI is disabled
I accept Chrome but reject specific cloud AI	Disable those integrations separately; use enterprise policies where applicable	that extensions or account services are covered
I reject Google as browser operator	Plan a browser migration	that the replacement has no AI, usage reporting, cloud service, or security trade-off

Firefox provides a useful contrast rather than an automatic winner. Mozilla’s current AI Controls documentation says Firefox 148 and later can block current and future built-in generative AI enhancements from one panel and remove downloaded on-device models. It also states that independent extensions are outside that control. That is a clearer unified preference, not a guarantee that no AI service can ever touch a page.

Check other Chromium browsers individually. One may omit an assistant while retaining Chromium components; another may use a different cloud service. Labels such as “privacy browser” or “AI-free” do not replace checking updates, defaults, extensions, and policy.

If you change browsers, move credentials before deleting the old profile. The password-manager migration protocol shows why equal row counts do not prove that passwords, passkeys, one-time login codes, or recovery paths survived.

De-Google Without Weakening Browser Security
#

Define the Google dependency you want to remove. Replace search, sync, AI services, account identity, and browser-vendor trust one layer at a time while preserving updates and a tested way back.

Use this order:

Write the boundary. Choose search, account linkage, cloud AI, sync, local AI, or the browser itself. One toggle cannot prove all six are gone.
Inventory and move data. Record bookmarks, extensions, passkeys, passwords, second factors, and recovery codes. Use a documented transfer and keep the old profile available.
Test the replacement. Use the official download, verify updates, review default search and usage reporting, inspect AI controls, and test logins, calls, banking, accessibility, and hardware security keys.
Retire one dependency at a time. Sign out or remove data only after the replacement works. Preserve browser updates; broad component policy can withhold many updates without removing cloud AI.

Bottom Line: Choose the Boundary You Mean
#

The supported answer to the local-model question is simple: inspect, turn off On-device AI, restart, and verify. The privacy answer is broader because local, hybrid, cloud, extension, account, and vendor layers remain distinct.

Do not anchor the decision to “4 GB” or treat deletion as policy. If disk or compute is the problem, turn off the model. If cloud disclosure is the problem, audit each feature. If Google is the problem, migrate the browser and account dependencies without weakening updates or losing credentials.

Frequently Asked Questions
#

Model size varies, menu locations change, cloud AI remains separate, manual deletion is unreliable, and another browser still requires product-specific checks.

Does every Chrome installation download a 4 GB AI model?
#

No. Eligibility, feature triggers, hardware, free space, variant, and release all matter. Google documents example 2B- and 4B-parameter variants and changing installed sizes. Inspect your own browser.

Where is the On-device AI setting if I cannot find it under System?
#

Search Chrome Settings for On-device AI. As of August 6, 2026, Google’s Help placed it under Settings > System, while Chromium was moving it toward Settings > AI. Menu placement varies by release channel.

Does turning off On-device AI disable all Chrome AI?
#

No. It controls the local model. AI Mode, Gemini integrations, cloud writing, extensions, Safe Browsing, search, sync, and account services remain separate.

Should I delete `weights.bin` or the model folder manually?
#

No. Manual deletion is not a documented control and cannot set a durable preference, so permitted files may return. Use the supported setting or targeted policy, then verify.

Is Firefox or another privacy browser automatically safer?
#

No. Firefox 148+ has a unified control for built-in generative AI, but extensions and web services remain separate. Other browsers have different assistants, usage reporting, update systems, dependencies, and compatibility costs. Test the current product.

References
#

Exact Wayback snapshots accompany all ten mutable official sources below. The Chromium settings-move source is an immutable commit, so no archive date is invented.

#	Source	URL	Archived / immutable evidence
1	Google Chrome Help — Manage on-device Generative AI models in Chrome	https://support.google.com/chrome/answer/16961953?hl=en	https://web.archive.org/web/20260801170205/https://support.google.com/chrome/answer/16961953?hl=en
2	Chrome for Developers — Understand built-in model management	https://developer.chrome.com/docs/ai/understand-built-in-model-management	https://web.archive.org/web/20260709211120/https://developer.chrome.com/docs/ai/understand-built-in-model-management
3	Chrome for Developers — Get started with built-in AI	https://developer.chrome.com/docs/ai/get-started	https://web.archive.org/web/20260629120921/https://developer.chrome.com/docs/ai/get-started
4	Chrome Enterprise — GenAI local foundational model settings	https://chromeenterprise.google/policies/gen-ai-local-foundational-model-settings/	https://web.archive.org/web/20260308023006/https://chromeenterprise.google/policies/gen-ai-local-foundational-model-settings/
5	Chrome Enterprise — Component updates enabled	https://chromeenterprise.google/policies/component-updates-enabled/	https://web.archive.org/web/20260208072812/https://chromeenterprise.google/policies/component-updates-enabled/
6	Chrome Enterprise — AI Mode settings	https://chromeenterprise.google/policies/ai-mode-settings/	https://web.archive.org/web/20260526191101/https://chromeenterprise.google/policies/ai-mode-settings/
7	Chromium — Experiments and `chrome://flags`	https://www.chromium.org/developers/design-documents/experiments/	https://web.archive.org/web/20260804174840/https://www.chromium.org/developers/design-documents/experiments/
8	Google Security Blog — On-device AI for tech-support scam detection	https://security.googleblog.com/2025/05/using-ai-to-stop-tech-support-scams-in.html	https://web.archive.org/web/20260430082954/https://security.googleblog.com/2025/05/using-ai-to-stop-tech-support-scams-in.html
9	Google Chrome Help — Write with AI in Chrome	https://support.google.com/chrome/answer/14582048	https://web.archive.org/web/20260725211037/https://support.google.com/chrome/answer/14582048
10	Mozilla Support — Firefox AI Controls	https://support.mozilla.org/en-US/kb/firefox-ai-controls	https://web.archive.org/web/20260613231843/https://support.mozilla.org/en-US/kb/firefox-ai-controls
11	Chromium — Move On-device AI settings to the AI page	https://chromium.googlesource.com/chromium/src/+/a4d2410c1ca703aa6c2ed0ec83ff95d0f4205a72	Immutable commit URL

Cora Aegis

Cora Aegis writes privacy-first OPSEC guidance at CypherpunkGuide. For this article, she audited five Google results and two generated-answer modes, verified ten archived official pages plus one immutable Chromium commit, mapped seven Chrome controls, and built a four-state read-only local-model audit.

More about Cora Aegis ->

Privacy Stack: Monero, SimpleX, Cryptomator (2026)

Thu, 13 Aug 2026 00:00:00 +0000

A note on funding: CypherpunkGuide carries no surveillance advertising—no ad networks, tracking pixels, or sponsored content. It is funded by transparent streams: reader donations now; subscription and editorially-aligned affiliate later. We answer to our readers, not to advertisers.

A private payment, an encrypted conversation, and an encrypted cloud folder look like three solved problems. Monero, SimpleX, and Cryptomator can each protect an important boundary. The comforting mistake is to assume that using all three turns those boundaries into one anonymous system.

I audited 18 pieces of data an observer may see across the three tools—six per layer—against current official documentation. The source-bound CSV records four states; a deterministic validator rejects missing scope, source, or as-of data. I excluded a composite privacy score because counts across unrelated fields would manufacture a ranking that the evidence cannot support.

The harder question is composition. The audit found six recurring ways to join layers: alias, device, internet path, counterparty, a timing-and-size pattern, and recovery material. A capable observer with access across records can use those shared clues to connect a payment, message, and file event. This guide maps the documented protections first, then builds around the records that still exist.

A Privacy Stack Is Three Boundaries, Not One Shield
#

A privacy stack is a set of controls with separate scopes, not a combined anonymity guarantee. Monero protects payment fields, SimpleX protects message delivery, and Cryptomator protects cloud-file contents. None protects every observer.

Start with the record, not the product. A blockchain observer, an internet provider, a relay operator, a cloud provider, a counterparty, and malware on your own device see different things. The same field can therefore be protected from one observer and exposed to another.

Layer	What the tool is designed to protect	What remains outside that boundary
Payment — Monero	sender-input ambiguity, recipient address privacy, transaction amount	wallet IP path, merchant records, voluntarily disclosed identity, endpoint keys and plaintext
Messaging — SimpleX	message content in transit, absence of one global user profile ID, destination-relay separation	pairwise queue identifiers, traffic timing, some relay/network metadata, contact knowledge, endpoint history
Storage — Cryptomator	file contents and names before cloud sync; obscured directory structure	timestamps, object counts, stored sizes, recognizable vault format, sync-account identity, unlocked plaintext

“Protected” in this article always means protected from the named observer within the documented scope. It does not mean invisible to a recipient, immune to endpoint compromise, or impossible to correlate. Partial means the cited control reduces what that observer can see without eliminating the field or every way to link it. Exposed means the cited documentation establishes that the observer can see the field or that the tool does not protect it. Unknown means the source establishes neither protection nor exposure.

This is the same discipline used in a real threat model: name the observer, the asset, and the event before selecting a control. If the observer changes, the answer can change with it.

Monero Hides the Transaction Graph, Not the Whole Payment
#

Monero gives senders probabilistic cover, recipients stealth addresses, and amounts RingCT protection. These are transaction-protocol properties. Remote nodes, networks, counterparties, accounts, and compromised wallets remain separate boundaries.

Current Monero technical specifications describe a ring size of 16: the real input appears with 15 decoys. That is plausible deniability, not a justified “one in sixteen” chance that an observer guesses correctly. Monero’s OSPEAD research models nonuniform and timing-related selection risk; the protocol number must not be converted into a personal anonymity probability.

Recipient and amount protection have different mechanics. Stealth addresses prevent the public chain from exposing the recipient’s reusable address, while RingCT hides the transferred amount. This makes “Monero privacy” a three-part statement—sender, recipient, amount—not one blanket property.

Observer	What Monero changes	What the observer can still have
Public blockchain analyst	obscured sender input, recipient link, and amount	the existence and timing of a protocol event; probabilistic inferences
Remote-node operator	cannot read a recipient address or amount from the chain as plaintext	a wallet connection and its source IP unless the network path is separately protected
ISP or VPN provider	transaction-graph privacy remains	a connection path, timing, and destination pattern
Counterparty or exchange	outside observers do not gain the private transaction fields	the identity, order, shipping address, account, amount, or conversation you gave it
Compromised endpoint	protocol privacy still exists for public observers	wallet keys, destination, amount, screen contents, clipboard, and password entry

The official FAQ rejects guaranteed anonymity and warns that endpoint compromise, exposed keys, weak passwords, and identifying details given to another party remain consequential. A unique subaddress per payer or payment can reduce counterparty-side address reuse. It cannot make the same merchant forget your delivery address.

Network privacy is similarly separate. Monero’s documentation warns that a wallet using a remote node has no IP protection by default and describes Tor or I2P as additional routing controls. Dandelion++ changes transaction propagation; it does not hide a full-node connection from an ISP, VPN provider, or first peer. If network origin is in scope, protect it deliberately and verify that the wallet configuration actually uses the intended route.

For a broader payment threat model, see the Bitcoin on-chain privacy guide. The protocol differs, but the operational lesson is the same: chain privacy does not erase purchase records or endpoint evidence.

SimpleX Removes Global User IDs, Not Every Link
#

SimpleX uses no global user profile identifier for message delivery; it uses pairwise queue identifiers and end-to-end encryption. Relays, networks, contacts, notification systems, and endpoints can still observe different metadata.

The SimpleX privacy policy says profiles and delivered history live on user devices rather than in relay accounts. Undelivered encrypted messages can remain on preset relays until delivery or for up to 21 days, and preset file relays retain encrypted files for 48 hours. “Servers store nothing” is therefore inaccurate even though the relay does not hold message plaintext.

Messages are padded to 16 KiB, and files use fixed-size chunks. Padding reduces exact size information; it does not hide that traffic occurred. On iOS, instant notifications can also reveal the number of notification-enabled queues and approximate message volume to the notification server.

Boundary	Default behavior	A harder configuration	Residual exposure
Profile identity	no global user profile ID; pairwise connection data	use incognito profiles where the relationship requires separation	contacts still know the profile they interact with; repeated traits can link contexts
Relay path	private routing inserts a configured forwarding relay before the destination relay; with multiple preset operators, the app prefers a different operator	use Tor or another approved overlay when the chosen relay must not see the source IP	forwarding and destination relays are not guaranteed to have independent operators; local observers can still see traffic
Transport correlation	one profile shares a TCP connection by default	enable per-contact transport isolation after reviewing its BETA status	timing and volume can remain correlated
Contact authenticity	invitation link establishes the connection	compare the in-app security code over an independent channel	the independent channel itself must belong to the intended person
Endpoint history	delivered history is stored locally	use an app database passphrase and an appropriate retention policy	unlocked devices, recipients, screenshots, and malware can retain plaintext

The privacy and security guide warns that an invitation link can be substituted in transit. Compare the in-app security code over a genuinely independent channel before treating a sensitive contact as authenticated. A second message sent through the same unverified account is not independent verification.

The protocol threat model also narrows the phrase “no identifiers.” Peers may be able to test identical non-incognito profile data, while receipts or automated responses can reveal whether and when someone is active. Calls have different exposure from messages: SimpleX’s call guide says relay-assisted calls reveal duration to the TURN relay, while peer-to-peer calls reveal IP addresses to contacts. Audit calls separately if they are part of the workflow.

SimpleX protects a messaging boundary; it does not make every message safe to send. The phone-number privacy guide explains why removing a telephone identifier helps, but contact behavior and endpoint compromise still need their own controls.

Cryptomator Encrypts Files, Not Their Activity Pattern
#

Cryptomator encrypts file contents and names before cloud sync and obscures directory structure. Its security target leaves timestamps, object counts, stored sizes, and the recognizable vault format visible.

The Cryptomator security target is unusually explicit about scope. A cloud provider should not receive readable filenames or file contents, but it can observe when objects change, how many exist, and their stored sizes. Recognizable .c9r or .c9s objects and vault configuration files can reveal that Cryptomator is being used. This is encryption, not steganography.

The endpoint boundary is more important than the cloud boundary once the vault is unlocked. Malware, a hostile device administrator, screenshots, application temporary files, clipboard history, and application-created copies outside Cryptomator’s protection can all bypass the intended workflow. Cryptomator does not protect copies another program creates while working with vault files.

Cryptomator is also not your synchronization or backup policy. Its official best-practices guide calls for regular encrypted-vault backups, while the sync-conflict guide treats synchronization as a separate system that can create conflicts. Keep vault credentials and recovery material separate from the cloud account and device they unlock; vault recovery cannot recreate deleted encrypted files. If several applications can read the unlocked mount, treat each application as part of the trusted endpoint.

Our 18-Field Cross-Layer Leakage Audit
#

The audit maps three tools against six observable fields each. Every row names an observer, official source, date, and limitation. It finds composition failures; it is not a benchmark, review score, or privacy ranking.

I built the 18-row boundary ledger from the official sources cited in this article. I then ran the validator, which confirmed exactly 18 rows, six rows per tool, unique fields, approved source hosts, ISO dates, and nonblank limitation text. The generated summary keeps the four assessment states but warns against comparing their counts.

The method imposes five constraints:

One field, one observer. “Network origin” is assessed against a relay or network observer, not against an undefined attacker.
Default and hardened states stay separate. Hardened records a documented configuration or a separately named control, not a hands-on grade or proof that Cora tested that network path. A Tor-capable workflow is not described as the default unless the documentation says it is.
Every row carries its failure boundary. A protected message in transit can still be plaintext on both endpoints.
Missing evidence stays unknown. Cryptomator’s security target does not promise network anonymity for cloud sync, so that field remains unknown rather than receiving an invented answer.
Counts never become scores. Six fields with different observers and consequences cannot be added into one valid measure of product privacy.

That last row is one of the most useful findings. I deliberately left one Cryptomator field unknown rather than fill it with product reputation. I also fixed every row to a named observer before classifying it. Evidence discipline stops a reader from configuring the wrong layer because a comparison table looked complete.

The Six Joins That Rebuild One Identity
#

The following is a Cora inference from the component evidence, not a claim that one vendor documents the complete three-tool workflow. The official NIST glossary defines disassociability as processing data or events without linking them to people or devices beyond operational need. A layered workflow loses that property when the layers share a durable join.

Cross-layer join	Example	Who may correlate it	Separation control
Alias or account	the same handle appears in a SimpleX profile, exchange record, and cloud account	counterparty, account provider, data broker	distinct purpose-bound identities; no shared recovery email
Endpoint	one infected laptop sees wallet, chat, and unlocked vault plaintext	malware, device administrator, forensic examiner	separate devices or strongly isolated systems where justified; ordinary OS accounts organize access but do not stop administrator/root-level malware
Network path	wallet, relay, and cloud sync connect through one stable household IP	ISP, VPN, relay, cloud provider with auxiliary data	route each sensitive boundary deliberately; do not assume file or protocol encryption hides IP
Counterparty	one person receives the message, payment, and file link	recipient or merchant	reveal only the fields the transaction requires; use purpose-specific subaddresses and links
Timing and size	a message, payment, and cloud upload happen within seconds	a capable observer with access to multiple logs	batch, delay, and avoid narrating exact amounts or filenames in real time
Recovery material	one email, password manager, or photo backup restores every layer	account takeover attacker, cloud provider, coerced holder	separate recovery channels and offline material; test each path independently

Timing deserves restraint. A synchronized event is a clue, not proof that two records belong to one person. But repeating the same sequence—message, payment, upload—can give an observer a stronger pattern than any single occurrence. Do not claim that random delay creates anonymity; use scheduling only to remove unnecessary precision after you have fixed stronger joins such as identity and endpoint sharing.

This composition problem echoes the AI deanonymization guide: inference becomes cheap when many weak signals share a key. Here, the signals are machine-observable events rather than writing style.

Build the Stack Without Building One Master Identifier
#

Build from the threat model outward: separate purposes, verify software and contacts, protect required network paths, encrypt before sync, and rehearse recovery. The stack is ready when one failed account or device does not expose every layer.

Use this order on noncritical data before moving real funds or sensitive records:

Write three observer statements. Example: “The public chain must not expose recipient or amount,” “the messaging relay must not hold plaintext,” and “the cloud provider must not read filenames or file contents.” Add network and endpoint observers only where your risk justifies the cost.
Separate purpose-bound identities. Decide whether the counterparty should be allowed to link the payment, chat, and file. If not, avoid a shared alias, recovery email, profile image, cloud account, and narrative that gives the join away.
Obtain software from official sources and verify it. Check release signatures or reproducible-build guidance where the project publishes it. Test Monero on stagenet and use nonsecret SimpleX and Cryptomator data first. A privacy stack built from an unverified binary has the wrong trust root.
Configure the payment boundary. Use a unique subaddress per payer or purpose. If a remote node must not see the wallet’s source IP, route and test that connection separately. Record which counterparty facts still exist.
Authenticate the messaging boundary. Establish the SimpleX contact, compare the security code over an independent channel, review incognito and transport-isolation settings, and decide whether push notifications or calls fit the threat model.
Configure the storage boundary. Create the vault locally, use a strong unique password, separate its recovery material, then synchronize ciphertext. Confirm that temporary exports and application backups do not leave plaintext elsewhere.
Rehearse failure with noncritical material. Restore a test vault, recover or migrate a noncritical chat profile according to current documentation, and use an empty test wallet or a deliberately isolated test environment for wallet recovery. Never enter a seed that protects real funds into a website, cloud service, unverified device, or unfamiliar recovery tool, and never overwrite the existing wallet during a drill. Do not discover during an emergency that all three paths depend on one phone.
Run a cross-layer join review. Compare alias, device, network path, counterparty, time, size, and recovery channel. Remove joins that provide no operational benefit, and document the ones you accept.

Compartmentation has costs: more recovery material, slower workflows, missed notifications, routing failures, and a greater chance of operator error. The goal is not maximum separation. It is the smallest separation that defeats the observer you actually named. The self-hosting sovereignty guide applies the same principle to infrastructure: moving a service home changes the trust boundary but does not eliminate administration or recovery risk.

Bottom Line: Choose the Boundary You Need
#

Use Monero for transaction-graph privacy, SimpleX for identifier-minimized messaging, and Cryptomator for cloud-file encryption when those records need protection. Then audit identity, endpoint, network, timing, and recovery joins.

If your only concern is a cloud provider reading filenames, Cryptomator may be the complete answer. If a merchant already knows your legal identity and shipping address, Monero cannot erase that business record. If a contact is unverified, SimpleX encryption can securely connect you to the wrong person. More tools do not repair a mismatched threat model.

The stack becomes defensible when every claim has an observer and every recovery path has been tested. Keep one honest unknown, if necessary. It is safer than a clean-looking matrix that promises a property no source establishes.

Frequently Asked Questions
#

The stack protects specific protocol and storage fields, not every identity, network, endpoint, or recovery record around them. Start with the observer, then choose only the layers that change what that observer can see.

Do Monero, SimpleX, and Cryptomator make me anonymous together?
#

No. They protect different records. A counterparty, compromised device, stable IP path, synchronized timing pattern, or shared account-recovery channel can link the workflow. Treat anonymity as a threat-model outcome, not a feature inherited from three product names.

Does Monero hide my IP address from a remote node?
#

Not by default. Monero’s technical documentation treats network privacy as a separate layer and describes Tor or I2P wrapping for that boundary. Verify the wallet’s actual route; do not infer IP protection from on-chain sender, recipient, or amount privacy.

Does SimpleX have no identifiers or metadata?
#

It has no global user profile identifier for message delivery, but it uses pairwise queue identifiers and retains operational metadata within documented limits. Relays, contacts, push systems, network observers, and endpoints each see different fields.

Can my cloud provider tell that I use Cryptomator?
#

Yes. Cryptomator encrypts content and names but does not try to hide its vault format. Recognizable encrypted-object extensions, configuration files, timestamps, counts, and stored sizes can remain visible.

Should I put all recovery material in one password manager?
#

Only if your threat model accepts that manager and its recovery path as a master join. Higher-risk workflows should separate the materials whose combined loss or compromise would expose every layer, then test recovery so separation does not become self-lockout.

References
#

The table pairs each mutable original source with a Wayback index link. Claims use the live official page; the archive column provides a second route for later verification.

#	Source	URL	Archived
1	Monero Docs — Technical Specs	https://docs.getmonero.org/technical-specs/	https://web.archive.org/web/20260808191457/https://docs.getmonero.org/technical-specs/
2	Monero — Frequently Asked Questions	https://www.getmonero.org/get-started/faq/	https://web.archive.org/web/20260730231338/https://www.getmonero.org/get-started/faq/
3	Monero Docs — Subaddress	https://docs.getmonero.org/public-address/subaddress/	https://web.archive.org/web/20260804004416/https://docs.getmonero.org/public-address/subaddress/
4	Monero Research Lab — OSPEAD	https://www.getmonero.org/2025/04/05/ospead-optimal-ring-signature-research.html	https://web.archive.org/web/20260423131819/https://www.getmonero.org/2025/04/05/ospead-optimal-ring-signature-research.html
5	SimpleX Chat — Privacy Policy and Technical Details	https://simplex.chat/privacy/	https://web.archive.org/web/20260725150448/https://simplex.chat/privacy/
6	SimpleX Chat — Privacy and Security	https://simplex.chat/docs/guide/privacy-security.html	https://web.archive.org/web/20260804190527/https://simplex.chat/docs/guide/privacy-security.html
7	SimpleX Chat Protocol — Threat Model	https://simplex.chat/docs/protocol/simplex-chat.html	https://web.archive.org/web/20260731210120/https://simplex.chat/docs/protocol/simplex-chat.html
8	SimpleX Chat — Audio and Video Calls	https://simplex.chat/docs/guide/audio-video-calls.html	https://web.archive.org/web/20260729214320/https://simplex.chat/docs/guide/audio-video-calls.html
9	Cryptomator Docs — Security Target	https://docs.cryptomator.org/security/security-target/	https://web.archive.org/web/20260512122357/https://docs.cryptomator.org/security/security-target/
10	Cryptomator Docs — Best Practices	https://docs.cryptomator.org/security/best-practices/	https://web.archive.org/web/20260722112824/https://docs.cryptomator.org/security/best-practices/
11	Cryptomator Docs — Vault Recovery	https://docs.cryptomator.org/desktop/vault-recovery/	https://web.archive.org/web/20260310220344/https://docs.cryptomator.org/desktop/vault-recovery/
12	Cryptomator Docs — Synchronization Conflicts	https://docs.cryptomator.org/desktop/sync-conflicts/	https://web.archive.org/web/20260706002907/https://docs.cryptomator.org/desktop/sync-conflicts/
13	NIST CSRC — Disassociability	https://csrc.nist.gov/glossary/term/disassociability	https://web.archive.org/web/20260622190616/https://csrc.nist.gov/glossary/term/disassociability

Cora Aegis

Cora Aegis writes privacy-first OPSEC guidance at CypherpunkGuide. For this article, she mapped 18 observable boundaries across Monero, SimpleX, and Cryptomator, bound every row to official documentation, and prepared the non-ranking dataset and validator.

More about Cora Aegis ->

How Streamers Get Doxxed: 5 Cases and the Defense (2026)

Sun, 21 Jun 2026 00:00:00 +0000

Every guide to streamer privacy reads like a pre-flight checklist. Use a VPN. Keep a separate email. Turn on two-factor authentication. Scrub the metadata from your photos. Watch your background. The advice is not wrong, and a creator who follows all of it is genuinely safer than one who does not. (Throughout this article: doxxing means publishing someone’s private information — name, address, identity — without their consent to enable harassment; swatting means making a false emergency report to dispatch armed police to a target’s home.) But read the actual cases — the streamers who were actually found, swatted, stalked, or forced to move — and a different picture emerges. Almost none of them were caught because they skipped the whole checklist. They were caught at one specific point, and the same handful of points recur.

That matters because a checklist treats every item as equally load-bearing, and they are not. A 2021 UNESCO study of women journalists found that 73% of respondents had experienced online violence, and that the abuse routinely escalated from words to the publication of personal information (UNESCO, 2021). For women and LGBTQ+ creators especially, doxxing is rarely the end state — it is the step before the stalker, the swatting call, and the sexualized threat. The gender-neutral guides price none of this in.

We read five documented streamer doxxings the way this series always does — not for the spectacle, but for the mechanism. The table below is our own synthesis: each case mapped not to what the victim should have hidden, but to the single failure point that converted a public identity into a locatable target.

Case	The failure point	How it was operationalized	The control it isolates
Keffals (Clara Sorrenti), 2022	Detail visible in a posted photo	Swatting, then a location matched from an image, then forced relocation	Audit the background, not just the metadata
Valkyrae, Cinna & Emiru, 2025	Real-time location, broadcast live	An in-person stalker used the IRL stream as a tracking beacon	An IRL stream is a location signal
Dream, 2022	A hidden face the brand depended on	Years of crowd-sourced attempts to match leaked photos to a name	Treat the one hidden attribute as a credential
Nadia Amine, 2022	A home address already in circulation	A swatting call that needed no new mistake from her	Address privacy is upstream of everything
Jacksfilms & SSSniperWolf, 2023	A home location a hostile creator could reach	A rival surfacing his location during a public feud	Your threat model includes your own industry

Read across the five, and the defense reorders itself. The work is not to hide more things. It is to know which failure point applies to your format, your face, and your audience — and to close that one first.

What “Getting Doxxed” Actually Means for a Streamer
#

Doxxing is the conversion of a public persona into a physical, reachable person — and for a streamer, the raw material is not a leaked database but the broadcast itself. The classic definition, publishing someone’s private information against their will, undersells how it works against creators. A streamer volunteers an enormous amount of signal by design: hours of voice, a face or a deliberately hidden one, a room, a routine, a real-time presence. The doxxer’s job is rarely to breach a server. It is to correlate what was already shown — a window’s view, a delivery driver’s knock, a reflection, a slip of a street name — into a location and a legal name.

That is why the streamer threat model diverges from the generic one. The AI-scale inference engines that fuse scattered “harmless” signals into an identity are pointed at a uniquely rich feed when the target livestreams. And the single most valuable asset a pseudonymous creator holds — a hidden face, in cases like Dream’s — is exactly the kind of biometric credential we trace in Your Voice and Face Are Credentials Now. The exposure is not a one-time leak to be patched. It is a continuous emission to be managed.

There is a second divergence the mainstream guides omit, and it is the one this article exists to make: the threat is not gender-neutral. For women and LGBTQ+ streamers, doxxing reliably escalates into stalking and sexual threat in a way male targets face less often and less intensely. That asymmetry is structural, it changes which “harmless” data is actually high-risk, and it gets its own section below — because no competing guide gives it one.

Five Cases, Five Failure Points
#

The fastest way to see how a broadcast becomes a location is to lay five documented cases beside one another and trace the same question through each: what was shown, how it was operationalized, and which single control would have broken the chain. These are reported episodes drawn from contemporaneous coverage; specifics are attributed to those sources, not reconstructed here.

The failure point: a detail in a photo, not a hole in a database. Clara Sorrenti, a Canadian streamer and activist known as Keffals, was swatted in August 2022 — armed police raided her home in London, Ontario, over a fake email sent in her name — after the Kiwi Farms forum had compiled and circulated her information. She fled, but the harassment followed: reporting describes forum users scrutinizing the photos and posts she shared and matching details in them to identify where she had gone, forcing repeated moves, at one point out of the country (NBC News; Vice). Cloudflare ultimately cut service to the forum, citing a threat to human life (Fortune). The lesson: the data that exposes you is usually hiding in the background of something you chose to post — a window, a bedspread, a skyline — not in a record you forgot to lock.

— Keffals (Clara Sorrenti) — Kiwi Farms, August 2022

The failure point: real-time location, broadcast by design. In March 2025, streamers Valkyrae, Cinna, and Emiru ended an in-real-life (IRL) streaming marathon early after a man who had located them threatened the group on camera, on stream (Rolling Stone). This was not a swatting and not a database leak. It was an in-person stalker who used the live broadcast itself as a tracking beacon — the stream answered the only question he needed, where are they right now, continuously and in public. The lesson: an IRL stream is a continuous location signal, and the failure point is not something the streamer forgot to hide but the real-time presence the format is built to transmit.

— Valkyrae, Cinna & Emiru — IRL stream, March 2025

The failure point: a single hidden attribute the whole brand depends on. Dream, one of the most-followed Minecraft creators in the world, built a vast audience while keeping his face private — which made the face itself the prize in a sustained deanonymization campaign. Crowd-sourced attempts to match leaked or alleged photos to a real name ran for years before he chose to do a controlled face reveal in October 2022 (Wikipedia). The point is not the reveal; it is the pressure that preceded it. The lesson: when a pseudonym’s entire value rests on one hidden attribute — a face, a real name, a home city — that attribute becomes a high-value credential, and a motivated crowd is patient. Protect it as you would a password, because functionally it is one.

— Dream — the value of a hidden face, 2022

The failure point: an address already in circulation. The streamer Nadia Amine was swatted in 2022, in one of a wider run of swattings against creators that year (Sportskeeda). The decisive failure here predates any individual stream: once a home address has leaked into the data-broker and forum ecosystem, a false emergency call to send armed police needs no further mistake from the victim. The lesson: address privacy is upstream of everything — data-broker removal and keeping a home address unlinked from the public persona are the controls that matter, because you cannot un-leak an address in the middle of a broadcast.

— Nadia Amine — swatting, 2022

The failure point: a hostile peer who already has your location. During a public feud in October 2023, YouTuber Jacksfilms accused fellow creator SSSniperWolf of surfacing his home — she posted from outside what was reported to be his house on Instagram Live — and YouTube responded by temporarily demonetizing one of her videos over off-platform conduct it said put someone’s safety at risk (Tubefilter). The lesson is the one creators least want to hear: your threat model includes your own industry. The control is identical to the one for the stalker and the swatter — keep your home unfindable and unlinked to your public identity — because you cannot build a defense on a rival’s restraint.

— Jacksfilms & SSSniperWolf — October 2023

Read as a set, the five are not five unrelated misfortunes. They are five distinct entry points into the same outcome — a name and a place — and each isolates a control the others do not. Keffals shows the photo background; Valkyrae the real-time signal; Dream the single load-bearing secret; Nadia the address that leaked long ago; Jacksfilms the adversary who is also a colleague. A defense built from the pattern, rather than from a flat checklist, knows to spend its effort where the entry point actually is.

The Failure-Pattern Taxonomy
#

Every streamer doxxing in the record above resolves to one of five failure modes — and naming the mode tells you which control is load-bearing for you, instead of asking you to do all of them equally. This taxonomy is our synthesis of the cases; it is the framework the flat checklists never assemble, because they list defenses without mapping them to the specific way exposure happens.

Failure mode	What actually leaked	The control that breaks it
Visual / metadata exposure	A location embedded in a photo’s background, reflection, or EXIF data (the hidden technical metadata cameras embed in image files)	Strip metadata and audit every frame’s background and reflections before posting
Real-time location (IRL)	Where you are, right now, transmitted live	Delay or obfuscate IRL location; never broadcast a static, returnable “here”
Pseudonym–attribute linkage	The one hidden thing the brand depends on (face, real name, city)	Treat that attribute as a credential; minimize its public surface area relentlessly
Address in circulation	A home address already sitting in broker or forum data	Data-broker removal; keep the home address unlinked from the public persona
Hostile-actor exposure	Your location, weaponized by a rival, troll, or ex	Make the home unfindable; assume zero restraint from adversaries who already know

The taxonomy is diagnostic, not decorative. A face-cam streamer in a fixed home studio lives mostly in rows one and four; an IRL traveler lives in row two; a creator whose entire identity is a hidden face lives or dies in row three. Find your row first. The checklist items that map to it are the ones to get perfect; the rest are good hygiene, not your front line.

The Gendered Layer: When Doxxing Becomes Stalking and Sexual Threat
#

For women and LGBTQ+ streamers, exposure rarely stops at exposure — it converts into stalking, sexual threat, and physical fear as a predictable pattern, not an unlucky escalation. This is the dimension the privacy checklists almost uniformly omit, and omitting it produces defenses calibrated for a threat women do not actually face in the same shape. The leaked address is the same; what arrives at it is not.

The case record makes the asymmetry concrete. Keffals, a trans woman, was not merely doxxed but swatted and hounded across multiple moves; the Valkyrae incident was an in-person threat against three women mid-broadcast. Neither maps to the “embarrassing tweet resurfaces” model the generic guides implicitly assume. The data backs the pattern beyond any single case: UN Women documents that technology-facilitated violence against women — doxxing, stalkerware, and image-based abuse among it — is a distinct and growing category of gender-based violence (UN Women), and Equality Now argues that the near-absence of specific legal protection against doxxing leaves women at heightened risk of stalking and harassment (Equality Now).

For threat modeling, this changes two things in practice. First, the “harmless” data is not harmless symmetrically. A face on camera, a relationship mentioned on stream, a neighborhood glimpsed in a vlog are raw material for a sexualized or stalking attack in a way a gender-neutral guide, written for an abstract target, never prices in. Second, the social graph is a primary vector, not a secondary one — partners, family, and the in-person meetups an audience expects become the path to the target. That is why the defenses below treat home-and-relationship compartmentation as a core control for women and LGBTQ+ creators, not an advanced extra.

The Sovereign Pseudonym Defense
#

A pseudonym is not a disguise you wear until someone guesses your name — it is a structural firewall between the persona that earns and the legal person who lives somewhere, and its job is to make a single leak non-fatal. The streamer guides treat “use a stage name” as one checklist line. It is the architecture everything else hangs on. Done as a firewall rather than a costume, it means the operational identity and the legal person never share an email, a phone number, a payment method, a delivery address, or a reused handle — so that when one signal leaks, it does not pull the rest of the chain with it. The audit playbook for finding what already links the two is the permanent digital footprint — the doxxer’s raw material is exactly the trail it teaches you to prune.

The same compartmentation that protects an activist publishing under a hostile state protects a streamer, because the underlying problem is identical: a determined adversary treats a leaked identity as the opening move, and the durable defense is controlling reachability — which address, which jurisdiction, which name can actually be acted on — rather than betting everything on never being identified. Concretely, for a creator that means a few non-negotiables:

Layer	The exposure	The pseudonymous control
Identity	One leaked field (email, phone, payment) unravels the rest	Hard separation: the persona shares no account, number, or address with the legal person
Home	A returnable physical location tied to the public name	A home address never linked to the persona; a registered agent, PO box, or business address for anything public-facing
The hidden attribute	A face, real name, or city the brand depends on hiding	Minimize its surface area as if it were a password; assume crowds will try indefinitely
Real-time presence	An IRL or “currently live from here” signal	Delay, obfuscate, or geofence; decouple where you are from when you say you are there

Be honest about the limits, though, because a defense that overpromises is its own failure. A pseudonym degrades under sustained correlation — the more you publish, the more an inference engine has to work with — so it buys safety and time, not permanence. And the legal layer is thin: in many jurisdictions there is still no specific anti-doxxing statute, swatting laws vary widely, and the protections that exist are slow, after-the-fact remedies, not a real-time shield. Treat the law as a recourse to document for, not a wall to hide behind.

The Limits of What You Can Do Alone
#

Here is the honest limit, and a guide that hid it would be repeating the omission this series was built to correct. Individual OPSEC protects the individual; it does not dismantle the harassment infrastructure that makes streamer doxxing cheap, and against a forum organized to find you or a swatting call already placed, personal technique is necessary and insufficient at once. You can compartmentalize your identity, scrub your backgrounds, and remove your address from a hundred broker sites. You cannot, alone, shut down the forum that coordinates the harassment, force a platform to act before the damage lands, or write the anti-doxxing law your jurisdiction lacks.

The cases say so when you read them as a set. Keffals did not lack technique; she was hunted by an organized forum until a major infrastructure provider finally cut its service. The swatting calls against creators succeed because the emergency-response system can be weaponized faster than any individual can harden against it. What actually moves these conditions is the lever cypherpunks have always named where personal cryptography meets institutional power: collective response and changed rules — platforms that de-platform coordinated harassment, infrastructure providers that refuse to carry it, anti-swatting registries and laws, and creator communities that share threat intelligence instead of facing it alone. Individual defense buys safety and time. It does not, by itself, raise the cost of running the harassment in the first place.

“Privacy is the power to selectively reveal oneself to the world.” — Eric Hughes, A Cypherpunk’s Manifesto, 1993

A streamer’s whole craft is selective revelation — showing the performance while keeping the person. The doxxer’s project is to strip the selectively out of it. Defend the individual case, and then push on the conditions, because no harassment forum will grant a creator privacy out of its beneficence. The rest of the Privacy pillar maps the same fight on its other fronts.

Bottom Line — Which Defense Matches Your Risk
#

The right front line depends entirely on your format, your hidden attribute, and who has reason to come looking.

If you stream IRL or travel on camera: your failure mode is real-time location. Decouple where you are from when you say so — delay the broadcast, obfuscate the exact spot, and never establish a static, returnable “here.” No amount of metadata hygiene closes a signal the format is built to transmit live.
If your brand depends on a hidden face or name: treat that one attribute as a credential, not a secret you can be casual about. Minimize its public surface relentlessly, assume a patient crowd is correlating every leak, and read Your Voice and Face Are Credentials Now before the next reveal pressures you.
If you are a woman or LGBTQ+ creator: price in the gendered escalation from day one. Exposure is likelier to become stalking and sexual threat and to route through your home and relationships, so home-address compartmentation and social-graph isolation are core controls for you, not advanced ones.

Across all three, the truth that held in every OPSEC failure before it holds here: once your identity is treated as the opening move, you cannot un-leak your way back. You can only decide, before you go live, which failure point your format exposes — and close that one first, then act with other creators to make the harassment itself cost more.

Key Takeaways

People get caught at one point, not the whole checklist: in every documented case, the doxxing succeeded through a single failure mode — a photo’s background, a real-time location, a hidden face, a leaked address, a hostile peer — so find your mode and make that control perfect first.
Keffals, 2022 — the background is the leak: after being swatted, Clara Sorrenti was relocated repeatedly when forum users matched details in the images she posted; Cloudflare eventually cut the harassment forum’s service over a threat to human life.
Valkyrae, Cinna & Emiru, 2025 — an IRL stream is a live location signal: the three ended a marathon early after an in-person stalker who tracked them threatened the group on camera — no database breach required.
A pseudonym is a firewall, not a costume: its value is keeping one leaked field from unraveling the rest, so the persona must share no email, phone, payment, or address with the legal person.
The gendered layer the guides skip: for women and LGBTQ+ creators, exposure reliably becomes stalking and sexual threat — UNESCO found 73% of surveyed women journalists had faced online violence — making home and social-graph isolation core controls, not extras.
The limit: individual OPSEC buys safety and time but cannot shut the harassment forum, force a platform to act in time, or write the anti-doxxing law — that takes platform action, infrastructure refusal, and collective creator defense.

Frequently Asked Questions
#

How do streamers get doxxed?
#

Almost always through correlation of what was already broadcast, not a database breach. The recurring failure points are a location hidden in a photo’s background or metadata, a real-time location transmitted during an IRL stream, a single hidden attribute (a face or real name) the brand depends on, a home address that already leaked into data-broker or forum data, or a hostile peer who surfaces a location during a feud. The doxxer’s work is to fuse scattered “harmless” signals into a name and a place.

Does a VPN protect a streamer from being doxxed?
#

Only against one narrow vector. A VPN hides your IP address, which matters, but it does nothing about the failure modes that actually catch streamers — a landmark visible out a window, a delivery on camera, a face reveal, or an address already circulating on broker sites. Treat a VPN as one necessary item, not the defense. The load-bearing controls are background auditing, address removal, and identity compartmentation.

Why does doxxing target women streamers differently?
#

Because for women and LGBTQ+ creators, exposure reliably escalates into stalking and sexual threat rather than ending at embarrassment. UN Women treats technology-facilitated gender-based violence — doxxing, stalkerware, and image abuse among it — as a distinct category, and Equality Now links the lack of specific anti-doxxing law to heightened stalking risk for women. As the gendered-layer section explains, this makes face, relationship, and neighborhood data higher-risk, and home-and-social-graph isolation core controls.

Does a pseudonym actually protect a streamer?
#

Yes, if it is built as a firewall rather than a costume. A pseudonym’s protection comes from hard separation — the persona and the legal person sharing no email, phone, payment method, or address — so that one leaked field does not unravel the rest. It is a delaying defense that degrades under sustained correlation, not a permanent shield, but it is the architecture every other control depends on. A stage name that shares your real payment details protects nothing.

What should I do first if I have been doxxed?
#

Document everything with dated screenshots stored on a personal device, then report to the platform and, if there is any physical threat, to local police — and pre-register with an anti-swatting program if one operates in your area — some police departments allow at-risk residents to flag their address so dispatchers know a call may be fraudulent. In parallel, assume your home address is compromised: begin data-broker removal, and treat any account or person linked to that address as also exposed. Reactive cleanup is harder than prevention, but a documented timeline is what any later platform or legal response will need.

#	Source	URL	Archive
1	NBC News — Cloudflare, Kiwi Farms, and Keffals (Sep 2022)	https://www.nbcnews.com/tech/internet/cloudflare-kiwi-farms-keffals-anti-trans-rcna44834	https://web.archive.org/web/*/https://www.nbcnews.com/tech/internet/cloudflare-kiwi-farms-keffals-anti-trans-rcna44834
2	Vice — Keffals and Kiwi Farms	https://www.vice.com/en/article/xgyagd/keffals-kiwi-farms	https://web.archive.org/web/*/https://www.vice.com/en/article/xgyagd/keffals-kiwi-farms
3	Fortune — Cloudflare blocks Kiwi Farms over threat to human life (Sep 2022)	https://fortune.com/2022/09/05/kiwi-farms-so-bad-cloudflare-feared-immediate-threat-to-human-life-for-clara-sorrenti-keffals/	https://web.archive.org/web/*/https://fortune.com/2022/09/05/kiwi-farms-so-bad-cloudflare-feared-immediate-threat-to-human-life-for-clara-sorrenti-keffals/
4	Rolling Stone — Women Twitch streamers and harassment (2025)	https://www.rollingstone.com/culture/culture-features/valkyrae-cinna-emiru-women-twitch-streamers-harassment-1235289509/	https://web.archive.org/web/*/https://www.rollingstone.com/culture/culture-features/valkyrae-cinna-emiru-women-twitch-streamers-harassment-1235289509/
5	Wikipedia — Dream (YouTuber), face reveal Oct 2022	https://en.wikipedia.org/wiki/Dream_(YouTuber)	https://web.archive.org/web/*/https://en.wikipedia.org/wiki/Dream_(YouTuber)
6	Sportskeeda — swatting of streamers, Nadia Amine (2022)	https://www.sportskeeda.com/esports/news-swatting-turns-wholesome-cop-asks-chat-start-hype-train-swatted-warzone-streamer	https://web.archive.org/web/*/https://www.sportskeeda.com/esports/news-swatting-turns-wholesome-cop-asks-chat-start-hype-train-swatted-warzone-streamer
7	Tubefilter — Jacksfilms, SSSniperWolf, and YouTube demonetization (Oct 2023)	https://tubefilter.com/2023/10/23/youtube-demonetizes-sssniperwolf-jacksfilms-house/	https://web.archive.org/web/*/https://tubefilter.com/2023/10/23/youtube-demonetizes-sssniperwolf-jacksfilms-house/
8	UNESCO — The Chilling: online violence against women journalists (2021)	https://www.unesco.org/en/articles/global-survey-reveals-rising-violence-against-women-journalists	https://web.archive.org/web/*/https://www.unesco.org/en/articles/global-survey-reveals-rising-violence-against-women-journalists
9	UN Women — FAQ on technology-facilitated gender-based violence	https://www.unwomen.org/en/articles/faqs/digital-abuse-trolling-stalking-and-other-forms-of-technology-facilitated-violence-against-women	https://web.archive.org/web/*/https://www.unwomen.org/en/articles/faqs/digital-abuse-trolling-stalking-and-other-forms-of-technology-facilitated-violence-against-women
10	Equality Now — Lack of legal protections against doxxing and women’s risk	https://equalitynow.org/news/press-releases/lack-of-legal-protections-against-doxing-is-putting-women-at-greater-risk-of-online-stalking-and-harassment/	https://web.archive.org/web/*/https://equalitynow.org/news/press-releases/lack-of-legal-protections-against-doxing-is-putting-women-at-greater-risk-of-online-stalking-and-harassment/
11	PEN America — Online Harassment Field Manual: protecting information from doxing	https://onlineharassmentfieldmanual.pen.org/protecting-information-from-doxing/	https://web.archive.org/web/*/https://onlineharassmentfieldmanual.pen.org/protecting-information-from-doxing/
12	Activist Checklist — Doxxing defense	https://activistchecklist.org/doxxing/	https://web.archive.org/web/*/https://activistchecklist.org/doxxing/

Cora Aegis

Cora Aegis writes privacy-first OPSEC guidance at CypherpunkGuide, reading closed harassment cases for the mechanism most coverage skips — here, the single failure point that converts a streamer's broadcast into a location, and why it lands hardest on women.

More about Cora →

How Activists Are Doxxed in Authoritarian Regimes (2026)

Fri, 19 Jun 2026 00:00:00 +0000

Leaving the country is supposed to be the end of the danger. You cross a border, you claim asylum, you start writing under your own name again — and the threat model you carried at home is supposed to expire at the frontier. That is the promise of exile, and it is the assumption most security advice for activists quietly inherits: get out, go dark for a while, and the state you fled loses its reach.

It does not. In 2023, Hong Kong’s national security police issued arrest warrants and HK$1 million bounties for activists living in Boston, London, and Melbourne, under a law that claims authority over things said on the other side of the planet. Belarus once forced a commercial airliner out of international airspace to seize one dissident journalist on board. Freedom House’s 2025 report documented 1,375 incidents of physical transnational repression since 2014, committed by 54 governments across 107 host countries — and that figure deliberately excludes the digital campaigns that usually arrive first, because those are harder to count and even harder to stop.

We read three of these cases the way this series always does — not for the outrage, but for the mechanism. Reading the bounty notices and the court records beside one another, the pattern that emerges is not the one the safety checklists describe. The doxxing is rarely the work of a lone troll with a grudge; it is an opening move in a state operation, it lands differently on women than the gender-blind guides admit, and the part that actually protects you is not a cleverer pseudonym. It is where your work is published from, and when.

The table below is our own synthesis — three reported cases mapped along the axis the doxxing guides skip: not what was leaked, but how the leak was operationalized into reach across a border.

Case	The doxxing method	How the state operationalized it	The OPSEC lesson it isolates
Belarus — Protasevich, 2021	Travel itinerary and timing, known in advance	A commercial flight forced down to make a physical arrest	Timing and movement metadata, not identity, is the exposure
Hong Kong — HKLeaks & bounties, 2019–2023	~2,800 doxxing “cards” of personal data; later, bounties on named exiles	Crowd-sourced harassment escalating to extraterritorial warrants and pressure on relatives	Your social graph and your family are the attack surface
China — cross-border network	Identity and location compiled, then shared between states	Interpol abuse, proxy harassment, co-option of host-country contacts	Jurisdiction itself is the variable you can change

Read across the three, and the controls reorder themselves. None of these people were caught because their pseudonym was weak. They were reached because a state treated a leaked identity as the first step in an operation that crossed a border — and that is a different problem than the one “how to blog anonymously” sets out to solve.

What Doxxing Means Under an Authoritarian State
#

Doxxing in an authoritarian context is not online cruelty that ends at humiliation — it is the reconnaissance phase of state repression, the step that converts a critic into a locatable, arrestable, pressurable target. The same act — publishing someone’s real name, address, workplace, and family ties — means something different when the entity acting on the leak is not an anonymous mob but a government with warrants, an intelligence service, or a diplomatic apparatus. The academic literature treats doxxing as a spectrum of intent, from “deanonymizing” to “targeting”; under a hostile state, those collapse into one. The leak is the targeting.

That reframing matters because it changes what you are defending. Against harassment, the goal is to deny strangers your information. Against a state, the information is often already held — what you are denying is operational use of it: the moment when a name on a list becomes a knock on a relative’s door. The International Centre for Counter-Terrorism’s literature review on doxing traces how the tactic migrated from personal vendetta to organized political tool; the cases below are that migration in its finished form.

There is a second reframing the standard guides omit entirely, and it is the one this article exists to make: the threat is not gender-neutral. For women activists, doxxing reliably escalates into sexual threat — rape threats, doctored intimate images, and the weaponization of family and relationships in ways male targets rarely face at the same intensity. That asymmetry is not a footnote; it is a structural feature of how repression is gendered, and it changes the defensive calculus. We give it its own section below, because no competing guide does.

Three Cases: Minsk, Hong Kong, and a Network Without Borders
#

The fastest way to see how a leak becomes reach is to lay three documented cases beside one another and trace the same path through each: what was known about the target, how the state acted on it, and what — if anything — the available OPSEC could have changed. These are reported, closed-enough episodes drawn from contemporaneous coverage and primary documents; specifics are attributed to those sources, not reconstructed here.

The mechanism: travel metadata, weaponized in real time. Roman Protasevich, a Belarusian opposition journalist living in exile, boarded Ryanair flight FR4978 from Athens to Vilnius. While the aircraft was over Belarusian airspace, authorities radioed a false bomb threat and scrambled a MiG-29 fighter jet, forcing the plane to land in Minsk. Protasevich and his companion Sofia Sapega were arrested at the gate. The state did not need to find him — it knew his itinerary and acted on it, turning a routine flight into a controlled interception. (GPIL, University of Bonn)

The aftermath corrects a common misreading. Protasevich was sentenced to eight years in May 2023 — and pardoned by Lukashenko nineteen days later, his cooperation extracted and displayed; his actual detention ran closer to two years, not eight (Al Jazeera). Sapega, sentenced separately to six years, was likewise pardoned in 2023 and handed to Russia. The lesson is not the sentence. It is that timing and movement metadata — not the strength of any pseudonym — was the exposure, and that a state will spend an international incident to act on it.

— Belarus — Ryanair Flight FR4978, 23 May 2021

The mechanism: crowd-sourced doxxing escalating into extraterritorial warrants. Beginning in August 2019, the HKLeaks network published “doxxing cards” exposing the personal details of protesters, journalists, and officials — approximately 2,800 individuals, according to Citizen Lab’s forensic study, which found circumstantial evidence that a governmental organization likely conducted or actively supported the campaign rather than attributing it to grassroots actors. The data was the raw material; the National Security Law supplied the reach.

By 2023, that reach had gone fully extraterritorial. Citing Article 38’s claim of jurisdiction over acts committed anywhere, by anyone, Hong Kong police issued arrest warrants and HK$1 million bounties — first for a batch of eight overseas activists in July (Human Rights Watch), then for five more that December, among them Boston-based activist Frances Hui (Hong Kong Free Press). When the named targets could not be reached, the pressure moved to those who could: Hui’s parents in Hong Kong were summoned by national security police, part of a documented escalation against exiled activists’ families (HRW, 2025). The lesson: your social graph and your relatives are the attack surface the moment you personally are out of reach.

— Hong Kong — HKLeaks and the overseas bounties, 2019–2023

The mechanism: jurisdiction-hopping and proxy enforcement. Where Belarus acted directly and Hong Kong acted through bounties, the broader Chinese apparatus acts through other states’ systems — abusing Interpol red notices, leaning on host-country business and diaspora contacts, and prosecuting agents who pose as community members. In the United States, federal cases have convicted operatives running an undeclared overseas “police station” and a long-term agent who spent years posing as a pro-democracy activist while reporting dissidents to Beijing’s Ministry of State Security (NBC News).

This is the case that isolates the most powerful variable. The reason these operations work is that they exploit the seams between legal systems — the gap an extradition request, a visa record, or a registrar’s compliance desk opens up. Which means the one thing an individual can actually move is jurisdiction itself: where the domain is registered, where the server sits, which platform holds the account. That is the thread the final sections pick up.

— China — the transnational repression network

Read as a set, the three cases describe an escalation ladder, not three unrelated events. Belarus shows the state acting on metadata it already had. Hong Kong shows the leak (HKLeaks) and the enforcement (bounties, family pressure) as two halves of one operation that crossed borders when the targets did. China shows the mature form: repression routed through the institutions of the very countries that were supposed to offer refuge. At each rung, the identity was never really the secret — the reachability was.

The Gendered Layer: When Doxxing Becomes Sexual Threat
#

For women activists, a doxxing campaign rarely stops at exposure — it reliably converts into sexual threat, and that conversion is a deliberate repression tactic, not an unfortunate side effect. This is the dimension the doxxing guides and the OPSEC checklists almost uniformly omit, and omitting it produces defenses calibrated for a threat women do not actually face in the same shape. The exposure is the same; what arrives next is not.

The Hong Kong protests made the pattern visible at scale. Alongside the HKLeaks data, women protesters and journalists faced a parallel campaign of gendered harassment: rape and death threats, and photographs doctored to appear sexually explicit and recirculated to humiliate. Reporting from the period documented images of female protesters altered to read as nude, and named journalists targeted with rape threats while they covered the movement (France 24, 2019). The point of the doctored image is not deception — everyone knows it is fake. The point is to attach a sexual humiliation to your name in every future search, and to signal that your body, not just your argument, is a legitimate target.

The tactic has only industrialized since. In 2025, exiled Hong Kong activists reported a new wave: fake sexualized images of named women on the bounty lists, printed and mailed to their neighbors in the UK and Australia, with one prominent activist’s case under investigation by Thames Valley Police, and a male activist’s wife similarly targeted with sexual posters sent to her address (Reuters, via U.S. News). The escalation is precise: from online image to physical mail, from the target herself to the people around her. It fuses three levers — sexual humiliation, family and community exposure, and the implicit message we know where you live — into a single act.

For threat modeling, this changes two things concretely. First, the “harmless” data is not harmless symmetrically: a face photo, a relationship status, a home neighborhood are raw material for a sexualized attack in a way the generic guides, written for a gender-neutral target, never price in. Second, family and intimate ties are a primary vector, not a secondary one — which is why the defensive sections below treat social-graph isolation and a family communication plan as core controls rather than advanced extras. The synthetic-media dimension of this — how cheaply a convincing fake is now produced — is the same machinery we trace in Your Voice and Face Are Credentials Now, and it lands hardest exactly here.

A Threat Model for Publishing Under Repression
#

The defense that survives transnational repression is built on one principle the tool lists invert: moving your infrastructure is more durable than hiding your identity, because jurisdiction is something you can change and a determined state’s ability to deanonymize you eventually is something you cannot. Identity concealment is a delaying tactic — valuable, but degrading over time as a state correlates more data. Infrastructure sovereignty is structural: it determines who can be compelled to act against you, and that is the variable the cases above all turned on. Build the model in layers, matched to the specific reach you are defending against.

Separate the publishing identity from the legal person, early. Before the first post, decide whether you are publishing as a pseudonymous individual, a collective, or a named outlet — because the choice sets your whole liability profile and is painful to change later. A pseudonymous collective diffuses attribution; a named journalist outlet carries publisher liability but can invoke press-freedom protections a lone blogger cannot. There is no universally right answer, only a right answer for your jurisdiction and your tolerance for exposure. What is universal: do not let the operational identity and the legal person share an email, a phone number, a payment method, or a reused handle. The deanonymization machinery that an AI-scale inference engine runs is exactly the correlation of those “harmless” overlaps.

Choose your infrastructure for who can be compelled, not for convenience. This is the layer the mainstream guides reduce to “use a VPN,” and it is far more than that. The domain registrar, the hosting provider, and the distribution channel each represent a compliance desk a state can lean on — so each is a jurisdictional choice, not merely a technical one. Privacy-respecting registrars that do not collect or surrender personal data, hosts located outside the reach of the relevant state, static sites that hold no user database to seize, and decentralized distribution (the Nostr protocol, IPFS, Tor onion services) that no single company can be ordered to delete — these are not paranoia, they are the difference between an outlet that can be removed with one legal letter and one that cannot. The principle is to never concentrate your publishing under a single entity that can be compelled in a single jurisdiction.

Publishing layer	What a hostile state can compel	The sovereign alternative
Domain registrar	Registrant identity; suspension of the domain	A privacy-respecting registrar that collects and surrenders no personal data
Hosting	Server seizure, access logs, takedown orders	A host outside the adversary’s jurisdiction; a static site that holds no user database to seize
Distribution	Account removal, deplatforming, content deletion	Decentralized protocols (Nostr, IPFS, Tor onion services) that no single company can be ordered to erase
Publishing timing	Timezone and activity-pattern correlation	Scheduled posting decoupled from your real schedule; protocols whose timestamps do not betray your location

Treat timing as a fingerprint. Protasevich’s interception turned on movement timing; the same logic applies to publishing. Posting patterns — the hours you are active, the timezone they imply, the rhythm that correlates with one person’s daily life — are metadata that survives even good pseudonymity. Vary them deliberately. Decouple the moment of writing from the moment of publishing through scheduling, and prefer protocols where the published timestamp does not betray your physical timezone. When you publish can deanonymize you as surely as what you publish — and it is the leak almost no one defends.

Plan for the family vector explicitly. Because relatives became the pressure point in Hong Kong the instant the activists themselves were unreachable, a serious threat model includes the people around you: a shared understanding of what is and isn’t safe to discuss, minimized public linkage between your activist identity and your family, and a communication plan that assumes their devices and accounts may be watched. For the practical mechanics of separating identities and auditing what already links you, the audit playbook for a permanent digital footprint is the companion to this section — the doxxer’s raw material is exactly the trail it teaches you to find and prune. Official victim guidance, such as the UK government’s resource on transnational repression, and the practical checklists at Activist Checklist, are worth reading before you need them, not after.

The Limits of Individual Defense
#

Here is the honest limit, and a case study that hid it would be repeating the very omission this series was built to correct. OPSEC protects the individual; it does not change the conditions that produced the repression, and against a state willing to spend a fighter jet, a million-dollar bounty, or another country’s legal system, individual technique is necessary and insufficient at once. You can move your infrastructure, vary your timing, and isolate your social graph. You cannot, alone, revoke a foreign government’s claim of extraterritorial jurisdiction, stop it from pressuring relatives still inside its borders, or prevent it from abusing an Interpol notice.

The cases say so when you read them as a set. Protasevich’s tradecraft did not fail — a state simply forced down his plane. The Hong Kong activists’ anonymity was beside the point once the bounties and the family summons began. China’s network works precisely because it operates through institutions an individual cannot opt out of. What actually moves these conditions is the lever cypherpunks have always named where personal cryptography meets institutional power: collective response and changed rules. Host countries that refuse to extradite on political charges and prosecute proxy agents; platforms and registrars that resist compliance with extraterritorial demands; press-freedom organizations and diaspora networks that make a bounty a diplomatic cost rather than a quiet threat. Individual defense buys safety and time. It does not, by itself, close the seams between jurisdictions that repression is built to exploit.

“Privacy is necessary for an open society in the electronic age. … We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy out of their beneficence.” — Eric Hughes, A Cypherpunk’s Manifesto, 1993

The faceless organization here is a state that followed its critic across a border, and the electronic age is the leaked card, the doctored photo, the bounty posted online. Defend the individual case — and then push on the conditions, because no government that issues a transnational bounty will grant you privacy out of its beneficence. The rest of the Sovereignty pillar maps the same fight on its other fronts — the individual set against a power that answers only to pressure.

Bottom Line — Which Protocol Matches Your Risk
#

The right level of defense depends entirely on who has reason to follow you across a border, and how far they have already shown they will go.

If you are a diaspora activist or exile with a named adversary state: assume your identity is known and defend reachability instead. Your front line is infrastructure jurisdiction — registrar, host, and distribution chosen for who cannot be compelled — plus an explicit family communication plan, because relatives are the documented pressure point the moment you are out of reach.
If you publish investigative or movement journalism from a hostile jurisdiction: decide your liability identity (pseudonymous, collective, or named outlet) before the first post, separate the operational identity from the legal person completely, and treat press-freedom protections as a real but slow, after-the-fact resource — worth invoking, not a real-time shield.
If you are a woman activist or journalist: price in the gendered escalation from the start. Doxxing is likely to arrive as sexual threat and to route through your family and neighbors, so social-graph isolation and minimizing public face-and-relationship data are core controls for you, not advanced ones.

Across all three, the same truth holds that held in every OPSEC failure before it: once a state treats your leaked identity as the opening move, you cannot un-leak your way back to safety. You can only decide, before you publish, which jurisdiction holds your work and which rhythm reveals your day — and, past the limit of what one person can do, act with others to raise the cost of reaching across a border at all.

Key Takeaways

The threat is reachability, not identity: in every case, the activist was caught not because a pseudonym broke but because a state treated a known identity as the first step in a cross-border operation.
Belarus, 2021 — timing is the exposure: Protasevich was seized by forcing down Ryanair flight FR4978 on travel metadata known in advance; he was sentenced to eight years and pardoned nineteen days later, his real detention closer to two years.
Hong Kong, 2019–2023 — the family is the attack surface: ~2,800 HKLeaks doxxing cards escalated into HK$1 million extraterritorial bounties, and when named exiles like Frances Hui were unreachable, the pressure moved to relatives inside Hong Kong.
The gendered layer the guides skip: for women, doxxing reliably becomes sexual threat — from doctored explicit images in 2019 to fake sexualized images mailed to exiles’ neighbors in 2025 — making social-graph and family isolation core controls, not extras.
Move infrastructure, not just identity: jurisdiction — registrar, host, distribution channel — is the variable you can change; a determined state’s eventual deanonymization is not, so choose every layer for who cannot be compelled.
The limit: individual OPSEC buys safety and time but cannot revoke extraterritorial jurisdiction or stop family pressure — that takes host-country refusal to extradite, platform resistance, and collective press-freedom defense.

Frequently Asked Questions
#

How are activists doxxed in authoritarian regimes?
#

Through a combination of crowd-sourced or state-supported data leaks and official records. Personal details — name, address, workplace, family, and social-media history — are compiled into public “doxxing” profiles, sometimes by networks that a forensic study like Citizen Lab’s on HKLeaks found were likely state-supported. The leak is then operationalized: used to issue warrants, post bounties, pressure employers or relatives, or, as in the Belarus case, to act on a known travel itinerary. The doxxing is usually the reconnaissance phase of a larger state operation, not an end in itself.

Can a foreign government really arrest me for what I publish abroad?
#

It can claim the authority to, and it can act on that claim through other means even where it cannot physically reach you. Hong Kong’s National Security Law asserts jurisdiction over acts committed anywhere by anyone, and in 2023 police issued arrest warrants and HK$1 million bounties for activists living in the US, UK, and Australia. Direct arrest abroad is rare, but extradition requests, Interpol notices, pressure on family still inside the country, and proxy harassment in the host country are all documented. Treat the warrant as real in its effects even if you are not physically extraditable.

Is hiding my identity or moving my infrastructure more important?
#

Moving your infrastructure is the more durable defense. Identity concealment is a delaying tactic that degrades as a state correlates more data over time; infrastructure choices — which registrar, host, and distribution channel hold your work — determine who can be legally compelled to act against you, and that is the variable the major cases all turned on. Do both, but if you must prioritize, choose every layer of your publishing stack for which jurisdiction it sits in and who cannot be ordered to remove it.

Why does doxxing target women activists differently?
#

Because for women, exposure reliably escalates into sexual threat as a deliberate tactic — from doctored explicit images in the 2019 Hong Kong campaigns to fake sexualized images mailed to exiled women’s neighbors in 2025. As the gendered-layer section above details, this makes face photos, relationship data, and home-neighborhood information higher-risk for women, and social-graph and family isolation core controls rather than advanced ones.

What should I do first if I think I am being targeted?
#

Document everything with dated records stored on a personal device, and contact a press-freedom or human-rights organization and your local police rather than handling it alone — official guidance, such as the UK government’s resource on transnational repression, exists for exactly this. In parallel, audit what publicly links your activist identity to your legal person and your family, and reduce that linkage. Assume relatives’ devices and accounts may be watched, and agree with them on what is safe to discuss. Reactive cleanup is harder than prevention, but a documented timeline is what any later legal or advocacy response will need.

#	Source	URL	Archive
1	Human Rights Watch — Hong Kong Warrants Aim at Activists Abroad (Jul 2023)	https://www.hrw.org/news/2023/07/04/hong-kong-warrants-aim-activists-abroad	https://web.archive.org/web/*/https://www.hrw.org/news/2023/07/04/hong-kong-warrants-aim-activists-abroad
2	Hong Kong Free Press — Arrest warrants & HK$1M bounties for 5 overseas activists (Dec 2023)	https://hongkongfp.com/2023/12/14/breaking-hong-kong-national-security-police-issue-arrest-warrants-hk1-million-bounties-for-5-overseas-activists/	https://web.archive.org/web/*/https://hongkongfp.com/2023/12/14/breaking-hong-kong-national-security-police-issue-arrest-warrants-hk1-million-bounties-for-5-overseas-activists/
3	Citizen Lab — HKLeaks: covert and overt online harassment tactics (Jul 2023)	https://citizenlab.ca/research/hkleaks-covert-and-overt-online-harassment-tactics-to-repress-the-2019-hong-kong-protests/	https://web.archive.org/web/*/https://citizenlab.ca/research/hkleaks-covert-and-overt-online-harassment-tactics-to-repress-the-2019-hong-kong-protests/
4	Human Rights Watch — Hong Kong: Targeting of Exiled Activists’ Families Escalates (May 2025)	https://www.hrw.org/news/2025/05/04/hong-kong-targeting-exiled-activists-families-escalates/	https://web.archive.org/web/*/https://www.hrw.org/news/2025/05/04/hong-kong-targeting-exiled-activists-families-escalates/
5	Al Jazeera — Belarusian activist Protasevich pardoned (May 2023)	https://www.aljazeera.com/news/2023/5/22/belarusian-activist-pardoned-by-minsk	https://web.archive.org/web/*/https://www.aljazeera.com/news/2023/5/22/belarusian-activist-pardoned-by-minsk
6	GPIL, University of Bonn — Banning Belarusian airlines after the FR4978 diversion	https://gpil.jura.uni-bonn.de/2023/10/banning-belarusian-airlines-in-response-to-belarus-diversion-of-ryanair-flight-fr4978-as-a-third-party-countermeasure/	https://web.archive.org/web/*/https://gpil.jura.uni-bonn.de/2023/10/banning-belarusian-airlines-in-response-to-belarus-diversion-of-ryanair-flight-fr4978-as-a-third-party-countermeasure/
7	Freedom House — Transnational Repression (1,375 cases; 54 origin / 107 host countries)	https://freedomhouse.org/report/transnational-repression	https://web.archive.org/web/*/https://freedomhouse.org/report/transnational-repression
8	France 24 — HK women protesters facing rape threats and doctored images (Sep 2019)	https://www.france24.com/en/20190902-attacked-for-gender-not-views-hk-women-protesters-facing-troll-army	https://web.archive.org/web/*/https://www.france24.com/en/20190902-attacked-for-gender-not-views-hk-women-protesters-facing-troll-army
9	Reuters (via U.S. News) — Exiled HK activists targeted by fake sexualized images (Dec 2025)	https://www.usnews.com/news/world/articles/2025-12-12/exiled-hong-kong-democracy-activists-say-theyre-targeted-by-fake-sexualised-images	https://web.archive.org/web/*/https://www.usnews.com/news/world/articles/2025-12-12/exiled-hong-kong-democracy-activists-say-theyre-targeted-by-fake-sexualised-images
10	UK Government — What to do if you are a victim of transnational repression	https://www.gov.uk/government/publications/transnational-repression/what-to-do-if-you-think-you-are-the-victim-of-transnational-repression	https://web.archive.org/web/*/https://www.gov.uk/government/publications/transnational-repression/what-to-do-if-you-think-you-are-the-victim-of-transnational-repression
11	ICCT — Doxing: A Literature Review (Dec 2024)	https://icct.nl/publication/doxing-literature-review	https://web.archive.org/web/*/https://icct.nl/publication/doxing-literature-review
12	NBC News — Chinese agent case in New York, a classic Beijing spy effort	https://www.nbcnews.com/investigations/chinese-agent-case-new-york-classic-beijing-spy-effort-experts-say-rcna169506	https://web.archive.org/web/*/https://www.nbcnews.com/investigations/chinese-agent-case-new-york-classic-beijing-spy-effort-experts-say-rcna169506

Cora Aegis

Cora Aegis writes privacy-first OPSEC guidance at CypherpunkGuide, reading closed repression cases for the mechanism most coverage skips — here, how a leaked identity becomes a state operation that follows an activist across a border.

More about Cora →

Editorial Standards & Methodology

Fri, 19 Jun 2026 00:00:00 +0000

We publish under a pen name. That is a deliberate choice — set out in full on the author page — but it places a burden on us: you cannot check our work against a résumé, so the work has to be checkable on its own terms. This page is the standing record of how we source, how we research, how we correct mistakes, and how you can verify what we publish. It is our substitute for a credential, and we intend it to be a higher standard than one.

Sourcing
#

Primary sources first. We cite the manifesto, the specification, the court filing, the dataset — not a secondary summary of them. Where we rely on another writer’s reporting, we say so and link it.
We archive what we link. Every external reference is recorded as an archive.org snapshot alongside the original URL, because the record rots and a dead link is not evidence.
Named claims, named sources. When we quote an expert, we attribute the quote. We do not invent sources, affiliations, or credentials — our own or anyone else’s.
Every statistic carries its origin. Figures appear with their source and the year inline, so you can trace them without taking our word for it.

Original research and methodology
#

Our most load-bearing work is primary research: measurements we run ourselves rather than claims we repeat. The flagship is a standing measurement of how automated systems read the web — which AI and search crawlers fetch which pages, across a fixed set of user-agents, on a regular cadence — together with our machine-readable llms.txt and recurring checks of whether, and where, our material is cited by AI systems.

We hold that research to the same standard we ask of others:

Reproducible by design. We publish our method in enough detail to be repeated — and, where a finding rests on data, the data behind it — so a reader with the same tools can check us, or contradict us. A result you cannot reproduce is an opinion.
Collected, not asserted. We publish only measurements we actually ran. Where a number is an estimate or a projection, we label it as one.
Dated provenance. Each research piece states when the data was gathered and over what window, so you can judge how current it is.

Corrections
#

How to report an error. Email cora@cypherpunkguide.com — encrypt anything sensitive with our public key (fingerprint FFE1 ECFE 2C75 7E98 6077 AAE2 56FB 82BD 4541 5835).
What we do with one. Material corrections are marked in the affected article, with the date and a note on what changed. We do not silently rewrite a substantive claim and pretend it was always there.
A dated record. Significant updates are dated in the article itself; for research, the change is also recorded in the data.

Verification and integrity
#

One accountable voice. Cora Aegis is a single, consistent pen name, published across the author page, a verified Nostr identity (cora@cypherpunkguide.com), and an ORCID record. The consistency is the point: it lets every claim be tied back to one voice that can be held to account.
Cryptographic signing. Our OpenPGP key is published — fingerprint FFE1 ECFE 2C75 7E98 6077 AAE2 56FB 82BD 4541 5835. Download the public key, or fetch it automatically with gpg --locate-keys cora@cypherpunkguide.com (Web Key Directory). Corrections and research releases that carry our signature can be verified against this key, so you can confirm a statement came from us and was not altered in transit.
Independence. We are reader-funded through transparent streams — direct Bitcoin and Monero donations now, a Premium tier and editorially-aligned affiliate links later — and we always tell you which is which. We carry no surveillance advertising: no ad networks, no tracking pixels, no sponsored content. We answer to our readers, not to advertisers.

Disclosure
#

Pseudonymous by design. It would be incoherent to teach surveillance resistance under a legal name harvested by the very data brokers we help you evade. The reasoning is set out in full on the author page.
The portrait is an illustration. Every image of Cora Aegis is an AI-generated illustration, not a photograph, and is disclosed as such wherever it appears.
Affiliations are stated. Where an affiliate relationship exists, it is disclosed plainly and in context — never buried.

Contact

Tue, 02 Jun 2026 00:00:00 +0000

We are a distributed publication with no public physical office. Reach us by email:

editor@cypherpunkguide.com — editorial, story tips, corrections, and named-subject disputes (Cora Aegis)
privacy@cypherpunkguide.com — privacy questions and data-subject requests
legal@cypherpunkguide.com — DMCA notices, legal and regulatory correspondence

Encryption. For anything sensitive, please encrypt. Cora Aegis’s OpenPGP key — fingerprint FFE1 ECFE 2C75 7E98 6077 AAE2 56FB 82BD 4541 5835 — is available to download, or fetch it with gpg --locate-keys cora@cypherpunkguide.com.

Support our work. CypherpunkGuide is reader-funded. Bitcoin and Monero donation details will be published here. We answer to our readers, not to advertisers.

See our Imprint for our author-identity policy. Our Editorial Standards & Methodology explain how we source, verify, and correct our work.

Disclaimer

Tue, 02 Jun 2026 00:00:00 +0000

Last updated: 2 June 2026

Not professional advice
#

CypherpunkGuide is educational. Nothing here is legal, financial, tax, or security advice. Consult a qualified professional before acting on anything you read here — especially decisions involving your money or your safety.

Cryptocurrency & self-custody risk
#

Self-custody and cryptocurrency carry real risk of irreversible loss. You alone are responsible for your keys, your operational security, and your decisions. Test with small amounts first.

“As is”
#

Content and tools are provided “as is”, without warranty of any kind. We are not liable for decisions you make based on our content, for third-party services we link to or mention, or for service interruptions and data loss. No system is perfectly secure; we do our best with the resources we have and commit to transparent disclosure if an incident occurs.

Opinions, not absolutes
#

Our editorial positions are informed opinions, offered in good faith. Reasonable people disagree; we welcome it.

Affiliate links
#

When we include affiliate links, we disclose them plainly, recommend only tools we use ourselves, and never let a commission alter our judgement. We run no surveillance ad networks and never sell your data — we are funded by transparent streams (donations as the first stream we are standing up; a possible subscription and editorially-aligned affiliate links later). See our Privacy Policy.

Third-party links
#

We link to external resources for your convenience. We do not control them and are not responsible for their content or practices. We archive what we cite (e.g. via the Wayback Machine) against link rot.

Imprint & Author Identity

Tue, 02 Jun 2026 00:00:00 +0000

Last updated: 2 June 2026

Who publishes this
#

CypherpunkGuide is an independent editorial publication written under the pseudonym Cora Aegis.

Why a pseudonym
#

We write about operational security, surveillance resistance, and self-sovereignty. To do so under a legal name — harvested by the very data brokers we teach you to evade — would be incoherent. The pseudonym is not a gimmick; it is the first lesson, and we practise what we publish. We follow the example of peer publications that protect author identity for the same reasons.

What this means
#

Cora Aegis is a real person whose legal identity is intentionally not disclosed. We will not reveal it in response to:

reader requests,
journalist inquiries conditioned on identity disclosure,
commercial requests not based on lawful KYC requirements, or
hostile attempts to expose.

We may comply with valid legal process (a court order or subpoena from a competent jurisdiction), after appropriate review and with reasonable effort to preserve pseudonym integrity within the limits of the law.

How we operate
#

We are a distributed publication and keep no public physical office. The site is hosted in Switzerland and our domain registration uses WHOIS privacy by design.

Contact
#

editor@cypherpunkguide.com — editorial
privacy@cypherpunkguide.com — privacy & data requests
legal@cypherpunkguide.com — DMCA, legal, regulatory

See also our Contact, Privacy Policy, and Terms.

Privacy Policy

Tue, 02 Jun 2026 00:00:00 +0000

Last updated: 10 June 2026

Privacy is the core of this publication, so this policy starts with what we do not do.

What we refuse to do
#

No surveillance advertising. No ad networks, no tracking pixels, no sponsored content. We answer to our readers, not to advertisers.
No third-party trackers. No Google Analytics, no Meta pixel, no cross-site tracking.
No selling or renting your data. Ever. To anyone.
No behavioural profiling and no using your data to train AI.

We collect the minimum needed to operate, and we tell you exactly what that is.

What we collect
#

Visitors. We run no client-side analytics today — no analytics scripts, no fingerprinting, and the pages set no cookies. Our content delivery network (BunnyCDN, an EU provider acting as our processor) serves the pages and keeps delivery logs with IP anonymisation enabled, plus aggregate statistics (request counts, bandwidth, cache ratio, country-level totals) that we use to understand load — not people. If we later add detailed analytics, it will be self-hosted and cookie-less (self-hosted Plausible is the planned candidate), and this policy will be updated first.

Newsletter subscribers (planned — the newsletter is not yet live). If you subscribe once it launches: your email address (to deliver the newsletter) and an optional language preference. We will keep only aggregate open/click counts — no long-term individual tracking.

Interactive tools (when available). Any computations run client-side, in your browser. We do not collect your inputs or results unless you explicitly opt in to receive an emailed report — in which case we collect only your email address. A connectivity/leak test that must send a request to our resolver logs the source IP ephemerally (≤24 hours), then deletes it, retaining only country-level aggregates.

Why we use it
#

Serving the site reliably (CDN delivery and abuse protection); aggregate statistics to understand what is read (never for advertising or sales); newsletter delivery and language localisation once that launches; delivering a tool report only when you ask; and meeting legal obligations where they genuinely apply.

How long we keep it
#

Data minimisation throughout: newsletter data until you unsubscribe (plus a short backup window); aggregate analytics up to 24 months; resolver logs ≤24 hours (then country-level aggregates); emailed tool reports are not stored on our servers. Backups are encrypted.

Sharing
#

We do not share, sell, or rent your data, with narrow exceptions: processors acting strictly on our behalf (e.g. email delivery), bound to confidentiality; and valid legal process from a competent jurisdiction, which we review and will challenge where overbroad. We never share data with ad networks, data brokers, social platforms, or AI-training providers.

Your rights
#

Depending on where you live (GDPR/UK GDPR, CCPA/CPRA, Japan’s APPI, LGPD, and others), you may have rights to access, delete, correct, port, or object to processing of your data, and to non-discrimination for exercising them. We do not sell data, so opt-out-of-sale does not apply — but we affirm it explicitly.

To exercise any right, email privacy@cypherpunkguide.com. We respond within the timeframe your law requires (e.g. 30 days GDPR / 45 days CCPA) and may verify your identity first. Reasonable requests are free.

Cookies
#

This site sets no cookies today — there is no login, no session, and no consent banner because there is nothing to consent to. Your theme preference (light/dark) is stored in your browser’s localStorage and never leaves your device; language is part of the URL, not a cookie. No advertising cookies, no tracking cookies. Where we embed third-party media, we prefer privacy-respecting embeds and tell you when we cannot.

Funding & affiliate links
#

We answer to our readers, not to advertisers. We are supported by transparent revenue streams: Bitcoin and Monero donations as the first stream we are standing up, with a possible Premium subscription and a small number of editorially-aligned affiliate links in a later phase. If and when we use affiliate links, we disclose them plainly and only recommend tools we use ourselves.

Children
#

This site is not intended for children under 13 (under 16 in the EU). We do not knowingly collect their data.

Changes
#

We may update this policy; material changes will be announced (newsletter notice and a site banner), with the “last updated” date above.

Contact
#

Privacy questions and data requests: privacy@cypherpunkguide.com. We are a distributed publication and keep no public physical office. See also our Imprint.

Terms of Service

Tue, 02 Jun 2026 00:00:00 +0000

Last updated: 2 June 2026

1. Acceptance
#

By using cypherpunkguide.com or subscribing to our newsletter, you accept these Terms. If you do not accept them, please do not use the site.

2. What we provide
#

CypherpunkGuide is an editorial publication: articles on privacy & OPSEC, self-custody, sovereignty, and cypherpunk philosophy. As the publication grows we may add free interactive tools and a newsletter (including a possible future Premium tier). Content is provided for information only and is not a substitute for professional legal, financial, or security advice.

3. Your responsibilities
#

Use the site lawfully; do not attempt to compromise its security or scrape it abusively; do not impersonate Cora Aegis or our staff; and do not share account credentials if and when accounts exist.

4. Editorial position
#

We take clear positions: privacy as a fundamental right (after Hughes’ A Cypherpunk’s Manifesto), self-custody and financial sovereignty, and critical analysis of surveillance technology and policy. These are informed opinions, not absolute truths — we welcome respectful disagreement. We may decline service to anyone engaged in harassment or hate speech.

5. Affiliate links & independence
#

All content is editorially independent. We do not accept sponsored content or paid placements. We are funded by transparent revenue streams (donations as the first stream we are standing up; a possible subscription and editorially-aligned affiliate links later). When affiliate links appear, they are disclosed plainly and never alter our recommendations. See our Privacy Policy and Disclaimer.

6. Authorship & pseudonym
#

CypherpunkGuide is written under the editorial pseudonym Cora Aegis. See our Imprint for the full author-identity policy.

7. Corrections
#

We correct material errors openly: a correction note on the affected article, a newsletter notice, and preservation of the original in the Wayback Machine. If you are a named subject of a case study and dispute a fact, contact editor@cypherpunkguide.com for a good-faith review.

8. Copyright & DMCA
#

We respect intellectual-property rights. To submit a takedown notice, email legal@cypherpunkguide.com with: the work claimed, the allegedly infringing URL, your contact details, a good-faith statement, a statement of accuracy and authority, and your signature. We respond within 14 days and may counter-notice where we believe the use is fair use, journalism, or otherwise lawful. We will not act on overbroad or bad-faith requests.

9. Disclaimers & liability
#

Content and tools are provided “as is”, without warranty. See our full Disclaimer.

10. Governing law
#

Whatever these Terms say, your local consumer-protection and data-protection laws apply (e.g. GDPR for the EU/UK, CCPA for California, APPI for Japan, LGPD for Brazil). Disputes are resolved first by good-faith negotiation, then mediation, then a competent court.

11. Contact
#

Editorial: editor@cypherpunkguide.com · Privacy: privacy@cypherpunkguide.com · Legal: legal@cypherpunkguide.com

About CypherpunkGuide

Mon, 01 Jun 2026 00:00:00 +0000

Why we exist
#

“Privacy is the power to selectively reveal oneself to the world.” — Eric Hughes, A Cypherpunk’s Manifesto, 1993

Three decades on, that power is harder to hold than ever. Every transaction, message, and movement is logged, correlated, and sold. CypherpunkGuide exists for the person who has decided this is not acceptable — and who wants practical, tested ways to take that power back.

We begin with privacy, not with any single technology. Privacy is the right; the tools are how we exercise it.

Who is Cora Aegis
#

Cora Aegis is the editorial voice behind this publication. The name is a pseudonym — deliberately. We write about operational security, surveillance resistance, and self-sovereignty; it would be incoherent to do so under a legal name harvested by the very data brokers we teach you to evade. The pseudonym is not a gimmick. It is the first lesson.

Our perspective is unapologetically that of an advocate. Privacy and self-sovereignty are not abstract preferences — they are the foundation of personal dignity: the right to hold your body, your money, and your story without first asking permission.

More about Cora Aegis →

What we cover
#

Our work is organized around four pillars, in the order we believe they are best learned:

Privacy & OPSEC — the foundation. Threat modeling, metadata, surveillance, and the everyday practices that shrink your attack surface. This is where most readers begin, whether or not they have ever touched Bitcoin.
Self-Custody — privacy made financial. Bitcoin is not our headline; it is the means by which financial privacy and censorship resistance become real. From your first hardware wallet to multisig, we treat it as a tool in service of the first pillar.
Sovereignty — privacy extended across a whole life: communication, residency, health, and the quiet infrastructure of independence.
Cypherpunk — the philosophy that ties it together, read from the primary sources rather than the slogans.

The path runs one way: privacy as the entry, Bitcoin as one of the means, sovereignty as the extension, the cypherpunk ethic as the horizon.

How we work
#

Education first. The large majority of what we publish is explanatory — threat models, comparisons, primary-source analysis — not product pitches.
Tools we actually use. When we recommend something, we run it ourselves, we name the trade-offs, and we disclose any affiliate relationship plainly.
Primary sources. We cite the manifesto, the spec, the filing — and we archive what we link, because the record rots.
We practice our own OPSEC. Pseudonymous authorship, privacy-respecting hosting, no surveillance analytics, no advertising trackers.

How we are funded
#

Our work is supported by several transparent revenue streams, and we will always tell you which is which:

Direct donations in Bitcoin and Monero — addresses are published on the Contact page as soon as our self-hosted setup is live; this is the first stream we are standing up.
A Premium subscription for readers who want more depth (planned for a later phase).
Carefully chosen affiliate links to a small number of tools that already meet our editorial standards — no hype, only things we use, always disclosed.

We answer to our readers, not to advertisers. That single sentence decides every editorial call we make.

Start here
#

If you are new, begin with Privacy & OPSEC. Everything else — including Bitcoin — makes more sense once you can see the threat you are actually defending against.

ExposureCheck

Mon, 01 Jan 0001 00:00:00 +0000

What it does, in one minute
#

ExposureCheck reads the data you export from a platform — never a live account, never anyone else’s — and asks the question an adversary would ask: given all of this together, what can be inferred about the person behind it?

It parses your Reddit GDPR export and your X / Twitter archive (a folder or a .zip).
It runs a recall-preserving cascade: a cheap pass ranks every post, an expensive pass reads the high-priority ones, and weak signals are kept — the mosaic is built from weak signals, so discarding them would be false comfort.
It extracts the metadata layer deterministically — the self-set location field, outbound links, image EXIF/GPS, device model, and the posting-time concentration that betrays your timezone. On X this leaks more than the text does.
It reports category risk cards — Location, Employer, Family, Schedule, Finances, Account-linkage — ranked by risk contribution, each with masked examples and concrete, generalise-first fixes.

It is local-first, writes no dossier, and never saves a profile of you to disk.

New to “mosaic re-identification”? Start with the threat, not the tool: read the companion explainer, Audit your own post history the way an AI would, then come back.

What it deliberately does not do
#

No dossier. It never prints “you live in X, work at Y, your name is Z.” Cards show masked snippets; the resolved value appears only when you click through to your own original post, in-session, never saved.
No export of findings. No scraping (export input only). No posting or deleting on your behalf. No analysing anyone else’s history.
It does not make you anonymous. It reduces risk. “Low” is not “safe”, and metadata, timing, and writing-style are only partly in scope.

What leaves your machine — and what doesn’t
#

This is the first thing a privacy tool should tell you, so here it is up front. The inference runs on a backend you choose, and that choice — not the tool — decides what travels:

Backend	What it is	Does your data leave your machine?
`local`	a local Ollama / llama.cpp / LM Studio model	✅ No — stays on your computer
`heuristic`	offline regex stub, near-zero recall	✅ No — but dev/CI only, not a real audit
`cloud`	any OpenAI-compatible endpoint, your key	⚠️ Yes — your posts go to that provider

The tool itself has no server, no telemetry, no account. The author holds none of your data and no keys. When you pick cloud, your export goes to the API provider you chose — and that provider’s logging, retention, training policy, and the IP/billing tied to your key all apply. ExposureCheck does not add a hop; it also cannot remove the one you opted into.

The one cloud caveat that actually matters
#

If the account you are auditing is a pseudonymous one you keep apart from your real identity, and your AI/cloud account is registered or paid under your real name, then sending that history to the cloud lets the provider link real identity ↔ anonymous account on their side (subpoena, breach, insider). That is the exact deanonymization this tool exists to prevent.

So: auditing a strictly-anonymous account → use --backend local (or a cloud account opened and paid for anonymously). Auditing your real-name / public account → cloud is fine. The CLI states this and asks you to acknowledge it when it applies. We never force local — that would shrink the audience to nobody — we make the trade-off explicit.

How it works
#

export ─▶ parse ─▶ prefilter (drop only TRUE-empty) ─┬─▶ deterministic: profile + EXIF + timing ─┐
 └─▶ cascade: cheap route ─▶ expensive read ─┤
 ▼
 risk-contribution scoring ─▶ category cards ─▶ no-dossier report

The cascade exists so a 1–3k-post history stays affordable: the cheap pass decides what deserves the expensive read instead of sending everything. Risk-contribution scoring then ranks categories by how much they actually narrow you down — not by raw model confidence, which is not calibrated.

Install
#

The core — parsing, EXIF, the cascade, and the cloud/local HTTP backends — is Python standard library only. No third-party package touches your export, which keeps the code you have to trust small.

# from source (a PyPI release ships with the first public version):
git clone https://github.com/coraaegis/exposurecheck && cd exposurecheck
pip install -e .

# or run without installing:
python -m exposurecheck --help

# Local model — nothing leaves your machine (recommended for anonymous accounts)
exposurecheck audit \
 --reddit ./reddit_export.zip \
 --twitter ./twitter_export \
 --backend local --expensive-model llama3.1 \
 --i-own-this-data

# Cloud — bring your own key; set it in the ENV, never on the command line
export OPENAI_API_KEY=sk-...
exposurecheck audit --twitter ./twitter_export --backend cloud --i-own-this-data

The API key is read from an environment variable on purpose: command-line arguments leak into shell history and process listings.

ExposureCheck is a command-line tool today, aimed at people comfortable in a terminal — which is also where its first reviewers live. A one-click app for non-technical users (a packaged build with a local, in-browser UI and no Python to install) is the next milestone; the CLI stays for power users.

Trust it the way you’d trust any privacy tool — by checking, not by faith
#

The author is pseudonymous, so don’t take a name on faith. Take things you can verify instead:

Read the code. It is open-source (MIT) and stdlib-only, so the dependency tree you have to audit is essentially the standard library.
Verify the release. Each release is PGP-signed by Cora Aegis. Fetch the key over WKD and check the signature:
```
gpg --locate-keys cora@cypherpunkguide.com
gpg --verify exposurecheck-0.1.0.tar.gz.asc
```
SHA-256 checksums ship with every release, and builds are reproducible — rebuild from the tagged source and confirm the artifact matches.
No identity code-signing certificate, by design — such a certificate would tie the project to a legal identity, the opposite of the point. An unsigned Windows binary may show a SmartScreen “unknown publisher” prompt; that is expected. Prefer a package manager (pip / Scoop / Homebrew) or run from source, and verify the PGP signature.
The output design is the safeguard. The no-dossier rule is enforced in code: masked labels are machine-generated, so even the model’s own text cannot surface a resolved value into the report. The dual-use guardrails — ownership-gated input, category-only output, masking, and a pre-release abuse evaluation — are documented in ABUSE-EVAL.md.

A transparent data-flow table and a published threat model show what the tool intends. The source, the signature, and the reproducible build are how you confirm it does that — and nothing else.

Limits you should hold in mind
#

“Low” is not “safe.” The tool reduces risk; it does not certify anonymity.
Recall is not perfect. A miss (“nothing flagged”) is not proof you are un-identifiable — especially on the heuristic backend, which exists for testing, not auditing.
Out of scope: writing-style fingerprinting, cross-platform correlation beyond what’s in your exports, network-level metadata, and the visual content of images (v1 reads EXIF/metadata only — see the roadmap).
The tool itself reads your most sensitive data. That is exactly why it is local-first, stdlib-only, open-source, and signed: so the thing you run to check your exposure is itself the smallest, most auditable surface it can be.

FAQ
#

Does ExposureCheck upload my posts anywhere?
#

Only if you choose the cloud backend, and then only to the API provider whose key you supplied. With local or heuristic, nothing leaves your machine. The tool has no server or telemetry of its own.

Will it tell me my own address or real name?
#

No. That is the deliberate “no-dossier” design. It shows masked categories and points you at your own original posts so you can decide what to change. It never assembles or stores a profile of you.

I’m auditing an anonymous account. Is the cloud backend safe?
#

Use --backend local for a strictly-anonymous account, unless your cloud account is itself anonymous. Sending an anonymous account’s history to a real-name AI account links the two on the provider’s side — the exact risk this tool helps you find.

Is it really safe to run on my full history?
#

The code is open-source and stdlib-only so you can read what it does, the release is PGP-signed and reproducible so you can confirm what you installed, and it writes no profile to disk. Verify those, don’t take them on trust — that’s the whole posture.

Why a command line and not an app?
#

The first audience is technical, and a CLI is the most auditable form. A packaged one-click app with a local in-browser UI is the next milestone for non-technical users.

Built by Cora Aegis. Found a privacy or safety flaw? Responsible disclosure is welcome — cora@cypherpunkguide.com (PGP via WKD). The canonical source and the name ExposureCheck live at github.com/coraaegis/exposurecheck.

#	Source	URL	Archived
1	FBI — Galveston Man Sentenced to Federal Prison for Computer Hacking (2012)	https://www.fbi.gov/sanantonio/press-releases/2012/galveston-man-sentenced-to-federal-prison-for-computer-hacking	https://web.archive.org/web/*/https://www.fbi.gov/sanantonio/press-releases/2012/galveston-man-sentenced-to-federal-prison-for-computer-hacking
2	CSO Online — “Embedded data, not breasts, brought down hacker” (2012)	https://www.csoonline.com/article/535700/embedded-data-not-breasts-brought-down-hacker.html	https://web.archive.org/web/*/https://www.csoonline.com/article/535700/embedded-data-not-breasts-brought-down-hacker.html
2b	Gizmodo — reporting the Ochoa photo-GPS trace (iPhone, Wantirna South) (2012)	https://gizmodo.com/these-breasts-nailed-a-hacker-for-the-fbi-5901430	https://web.archive.org/web/*/https://gizmodo.com/these-breasts-nailed-a-hacker-for-the-fbi-5901430
3	NPR — “Betrayed By Metadata: John McAfee Admits He’s Really In Guatemala” (2012)	https://www.npr.org/sections/thetwo-way/2012/12/04/166487197/betrayed-by-metadata-john-mcafee-admits-hes-really-in-guatemala	https://web.archive.org/web/*/https://www.npr.org/sections/thetwo-way/2012/12/04/166487197/betrayed-by-metadata-john-mcafee-admits-hes-really-in-guatemala
4	The Next Web — “Vice leaves metadata in photo of John McAfee” (2012)	https://thenextweb.com/news/vice-leaves-metadata-in-photo-of-john-mcafee-pinpointing-him-to-a-location-in-guatemala	https://web.archive.org/web/*/https://thenextweb.com/news/vice-leaves-metadata-in-photo-of-john-mcafee-pinpointing-him-to-a-location-in-guatemala
5	The New York Times — “Web Photos That Reveal Secrets, Like Where You Live” (2010)	https://www.nytimes.com/2010/08/11/business/media/11photos.html	https://web.archive.org/web/*/https://www.nytimes.com/2010/08/11/business/media/11photos.html
6	Friedland & Sommer — “Cybercasing the Joint: On the Privacy Implications of Geo-Tagging” (USENIX HotSec 2010)	https://www.usenix.org/conference/hotsec10/cybercasing-joint-privacy-implications-geo-tagging	https://web.archive.org/web/*/https://www.usenix.org/conference/hotsec10/cybercasing-joint-privacy-implications-geo-tagging
7	ICSI — “Cybercasing” project note (2010)	https://www.icsi.berkeley.edu/icsi/news/2010/08/cybercasing	https://web.archive.org/web/*/https://www.icsi.berkeley.edu/icsi/news/2010/08/cybercasing
8	CIPA — DC-008 Exchangeable image file format standard	https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf	https://web.archive.org/web/*/https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
9	MetaFilter — thread documenting the 2003 embedded-thumbnail incidents	https://www.metafilter.com/27225/Photoshop-Thumbnails-Boobs	https://web.archive.org/web/*/https://www.metafilter.com/27225/Photoshop-Thumbnails-Boobs
10	Stolen Camera Finder — serial-number photo search	https://www.stolencamerafinder.com/	https://web.archive.org/web/*/https://www.stolencamerafinder.com/
11	Apple — Manage location metadata in Photos (Personal Safety User Guide)	https://support.apple.com/guide/personal-safety/manage-location-metadata-in-photos-ips0d7a5df82/web	https://web.archive.org/web/*/https://support.apple.com/guide/personal-safety/manage-location-metadata-in-photos-ips0d7a5df82/web
12	Google Photos Help — Edit photo locations	https://support.google.com/photos/answer/6153599?hl=en	https://web.archive.org/web/*/https://support.google.com/photos/answer/6153599?hl=en
13	ExifTool by Phil Harvey — official site	https://exiftool.org/	https://web.archive.org/web/*/https://exiftool.org/
14	ExifCleaner — open-source metadata remover (GitHub)	https://github.com/szTheory/exifcleaner	https://web.archive.org/web/*/https://github.com/szTheory/exifcleaner
15	Signal Community — metadata handling by file type (photo vs document/attachment path)	https://community.signalusers.org/t/list-of-meta-data-which-should-be-displayed-when-sending-certain-file-formats/31798	https://web.archive.org/web/*/https://community.signalusers.org/t/list-of-meta-data-which-should-be-displayed-when-sending-certain-file-formats/31798

#	Source	URL	Archived
1	PGP 2.6.2 User’s Guide — PGP 2.0 acknowledgments (1994)	https://web.pa.msu.edu/reference/pgpdoc1.html	https://web.archive.org/web/20201112040702/https://web.pa.msu.edu/reference/pgpdoc1.html
2	Hal Finney — archived homepage	https://fennetic.net/irc/finney.org/~hal/home.html	https://web.archive.org/web/20250314135429/https://fennetic.net/irc/finney.org/~hal/home.html
3	Hal Finney — Why Remailers I (1992)	https://nakamotoinstitute.org/library/why-remailers-i/	https://web.archive.org/web/20241005233552/https://nakamotoinstitute.org/library/why-remailers-i/
4	Hal Finney — Protecting Privacy with Electronic Cash (1993)	https://nakamotoinstitute.org/library/protecting-privacy-with-electronic-cash/	https://web.archive.org/web/20240813051548/https://nakamotoinstitute.org/library/protecting-privacy-with-electronic-cash/
5	Hal Finney — Detecting Double Spending (1993)	https://nakamotoinstitute.org/library/detecting-double-spending/	https://web.archive.org/web/20240521015620/https://nakamotoinstitute.org/library/detecting-double-spending/
6	Hal Finney — Politics vs Technology (1994)	https://nakamotoinstitute.org/library/politics-vs-technology/	https://web.archive.org/web/20240521015548/https://nakamotoinstitute.org/library/politics-vs-technology/
7	Hal Finney — PGP Web of Trust Misconceptions (1994)	https://nakamotoinstitute.org/library/pgp-web-of-trust-misconceptions/	https://web.archive.org/web/20240521015609/https://nakamotoinstitute.org/library/pgp-web-of-trust-misconceptions/
8	Hal Finney — RPOW announcement (2004)	https://cryptome.org/rpow.htm	https://web.archive.org/web/20200702094208/https://cryptome.org/rpow.htm
9	Hal Finney — RPOW IBM 4758 Security Model	https://nakamotoinstitute.org/finney/rpow/secmodel.html	https://web.archive.org/web/20240715202954/https://nakamotoinstitute.org/finney/rpow/secmodel.html
10	Satoshi Nakamoto — Bitcoin: A Peer-to-Peer Electronic Cash System	https://bitcoin.org/bitcoin.pdf	https://web.archive.org/web/20210812170542/https://bitcoin.org/bitcoin.pdf
11	Hal Finney — Bitcoin P2P e-cash paper reply (2008)	https://www.metzdowd.com/pipermail/cryptography/2008-November/014827.html	https://web.archive.org/web/20220407064228/https://www.metzdowd.com/pipermail/cryptography/2008-November/014827.html
12	Satoshi Nakamoto — Bitcoin v0.1 release (2009)	https://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html	https://web.archive.org/web/20200207210227/https://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html
13	Hal Finney — public reply to Bitcoin v0.1 (2009)	https://www.metzdowd.com/pipermail/cryptography/2009-January/015004.html	https://web.archive.org/web/20260802040419/https://www.metzdowd.com/pipermail/cryptography/2009-January/015004.html
14	Hal Finney — “Running bitcoin” (2009)	https://x.com/halfin/status/1110302988	https://web.archive.org/web/20240719190909/https://x.com/halfin/status/1110302988
15	Bitcoin transaction `f4184fc5…e16`, block 170	https://blockstream.info/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16	https://web.archive.org/web/20201112014519/https://blockstream.info/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16
16	Hal Finney — Bitcoin and Me (2013)	https://bitcointalk.org/index.php?topic=155054.msg1644175	https://web.archive.org/web/20220309092611/https://bitcointalk.org/index.php?topic=155054.msg1644175

#	Source	URL	Archive
1	EFF — Street-Level Surveillance: Automated License Plate Readers	https://sls.eff.org/technologies/automated-license-plate-readers-alprs	https://web.archive.org/web/*/https://sls.eff.org/technologies/automated-license-plate-readers-alprs
2	EFF — A Texas Cop Used 83,000 Cameras to Track an Abortion Patient (May 2025)	https://www.eff.org/deeplinks/2025/05/she-got-abortion-so-texas-cop-used-83000-cameras-track-her-down	https://web.archive.org/web/*/https://www.eff.org/deeplinks/2025/05/she-got-abortion-so-texas-cop-used-83000-cameras-track-her-down
3	IPVM — Flock-Powered Police LPR Abuse Triples At An Agency Once They Look	https://ipvm.com/reports/flock-police-triple-audit	https://web.archive.org/web/*/https://ipvm.com/reports/flock-police-triple-audit
4	ACLU — “Get the Flock Out” Campaign & Model Bill	https://www.aclu.org/campaigns-initiatives/get-the-flock-out	https://web.archive.org/web/*/https://www.aclu.org/campaigns-initiatives/get-the-flock-out
5	ACLU-WA — Gov. Ferguson Signs SB 6002, the Driver Privacy Act	https://www.aclu-wa.org/press-releases/gov-ferguson-signs-sb-6002-the-driver-privacy-act-into-law/	https://web.archive.org/web/*/https://www.aclu-wa.org/press-releases/gov-ferguson-signs-sb-6002-the-driver-privacy-act-into-law/
6	Institute for Justice — Plate Privacy Project (police LPR stalking cases)	https://ij.org/issues/ijs-project-on-the-4th-amendment/license-plate-readers/	https://web.archive.org/web/*/https://ij.org/issues/ijs-project-on-the-4th-amendment/license-plate-readers/
7	Congressional Research Service — Automated License Plate Readers (IF13068)	https://www.congress.gov/crs-product/IF13068	https://web.archive.org/web/*/https://www.congress.gov/crs-product/IF13068
8	California Attorney General — Bonta Sues El Cajon Over Illegal ALPR Data Sharing	https://oag.ca.gov/news/press-releases/attorney-general-bonta-sues-el-cajon-illegally-sharing-license-plate-data-out	https://web.archive.org/web/*/https://oag.ca.gov/news/press-releases/attorney-general-bonta-sues-el-cajon-illegally-sharing-license-plate-data-out
9	RadarTest — PhotoBlocker / reflective plate product review	https://radartest.com/photoblocker-review.asp	https://web.archive.org/web/*/https://radartest.com/photoblocker-review.asp
10	NCSL — Automated License Plate Readers: State Statutes	https://www.ncsl.org/technology-and-communication/automated-license-plate-readers-state-statutes	https://web.archive.org/web/*/https://www.ncsl.org/technology-and-communication/automated-license-plate-readers-state-statutes
11	TribLive — Ex-officer who used police gear to stalk woman sentenced (McSherry, PA)	https://triblive.com/local/valley-news-dispatch/ex-cop-who-used-police-gear-to-stalk-woman-pleads-guilty-sentenced-to-jail-probation/	https://web.archive.org/web/*/https://triblive.com/local/valley-news-dispatch/ex-cop-who-used-police-gear-to-stalk-woman-pleads-guilty-sentenced-to-jail-probation/
12	KAKE — Sedgwick police chief tracked ex-girlfriend 164 times using plate cameras (Nygaard, KS)	https://www.kake.com/home/sedgwick-police-chief-tracked-ex-girlfriend-164-times-using-license-plate-cams/article_21fdfdba-5dc5-11ef-95c4-8be8baa3f10c.html	https://web.archive.org/web/*/https://www.kake.com/home/sedgwick-police-chief-tracked-ex-girlfriend-164-times-using-license-plate-cams/article_21fdfdba-5dc5-11ef-95c4-8be8baa3f10c.html
13	TMJ4 — Former Milwaukee officer pleads guilty after stalking ex with police technology (Ayala, WI)	https://www.tmj4.com/news/local-news/in-your-community/milwaukee-county/former-milwaukee-officer-pleads-guilty-to-misdemeanor-for-stalking-ex-girlfriend-with-police-technology	https://web.archive.org/web/*/https://www.tmj4.com/news/local-news/in-your-community/milwaukee-county/former-milwaukee-officer-pleads-guilty-to-misdemeanor-for-stalking-ex-girlfriend-with-police-technology
14	EFF — Get the Flock Out of Here (2026)	https://www.eff.org/deeplinks/2026/06/get-flock-out-here	https://web.archive.org/web/*/https://www.eff.org/deeplinks/2026/06/get-flock-out-here
15	TechTimes — Flock Safety Crosses 100,000 Cameras as 53 Cities Cancel (Jun 2026)	https://www.techtimes.com/articles/319317/20260629/flock-safety-crosses-100000-cameras-as-53-cities-cancel-over-unauthorized-federal-data-access.htm	https://web.archive.org/web/*/https://www.techtimes.com/articles/319317/20260629/flock-safety-crosses-100000-cameras-as-53-cities-cancel-over-unauthorized-federal-data-access.htm
16	EFF & ACLU — SFPD Illegally Sharing ALPR Data with ICE and Anti-Abortion States (Sep 2025)	https://www.eff.org/deeplinks/2025/09/eff-aclu-sfpd-stop-illegally-sharing-data-ice-and-anti-abortion-states	https://web.archive.org/web/*/https://www.eff.org/deeplinks/2025/09/eff-aclu-sfpd-stop-illegally-sharing-data-ice-and-anti-abortion-states

#	Source	URL	Archive
1	NIST — SP 800-63B-4: Authenticators and phishing resistance	https://pages.nist.gov/800-63-4/sp800-63b/authenticators/	https://web.archive.org/web/20260701051113/https://pages.nist.gov/800-63-4/sp800-63b/authenticators/
2	NIST — SP 800-63B-4: Authenticator event management and account recovery	https://pages.nist.gov/800-63-4/sp800-63b/events/	https://web.archive.org/web/20260323072006/https://pages.nist.gov/800-63-4/sp800-63b/events/
3	FIDO Alliance — Passkey Index launch and 2025 results	https://fidoalliance.org/fido-alliance-launches-passkey-index-revealing-significant-passkey-uptake-and-business-benefits/	https://web.archive.org/web/20260420062740/https://fidoalliance.org/fido-alliance-launches-passkey-index-revealing-significant-passkey-uptake-and-business-benefits/
4	FIDO Alliance — Synced Passkey Deployment: Emerging Practices for Consumer Use Cases	https://fidoalliance.org/wp-content/uploads/2024/05/Synced-Passkey-Deployment_-Emerging-Practices-for-Consumer-Use-Cases_2024-Final.pdf	https://web.archive.org/web/20260420102322/https://fidoalliance.org/wp-content/uploads/2024/05/Synced-Passkey-Deployment_-Emerging-Practices-for-Consumer-Use-Cases_2024-Final.pdf
5	FIDO Alliance — Credential Exchange Format, Proposed Standard (2026-03-09)	https://fidoalliance.org/specs/cx/cxf-v1.0-ps-errata-20260309.pdf	https://web.archive.org/web/20260515224326/https://fidoalliance.org/specs/cx/cxf-v1.0-ps-errata-20260309.pdf
6	Google — Manage your Google Password Manager PIN	https://support.google.com/chrome/answer/16608973	https://web.archive.org/web/20260729220641/https://support.google.com/chrome/answer/16608973
7	Google — Recover your Google Account or Gmail	https://support.google.com/accounts/answer/7682439?hl=en	https://web.archive.org/web/20260713163540/https://support.google.com/accounts/answer/7682439?hl=en
8	Google — Recovery Contacts announcement (2025-10-15)	https://blog.google/innovation-and-ai/technology/safety-security/how-google-protects-against-scams-2025/	https://web.archive.org/web/20260524055556/https://blog.google/innovation-and-ai/technology/safety-security/how-google-protects-against-scams-2025/
9	Google — Passkey deployment update and adoption data (2024-05-02)	https://blog.google/innovation-and-ai/technology/safety-security/google-passkeys-update-april-2024/	https://web.archive.org/web/20260711072347/https://blog.google/innovation-and-ai/technology/safety-security/google-passkeys-update-april-2024/
10	Apple — iCloud Keychain security overview	https://support.apple.com/en-gb/guide/security/sec1c89c6f3b/web	https://web.archive.org/web/20260312052028/https://support.apple.com/en-gb/guide/security/sec1c89c6f3b/web
11	Apple — Set up a recovery contact for your Apple Account	https://support.apple.com/en-us/102641	https://web.archive.org/web/20260628000018/https://support.apple.com/en-us/102641
12	Apple — Set up a recovery key for your Apple Account	https://support.apple.com/en-ie/109345	https://web.archive.org/web/20260516085000/https://support.apple.com/en-ie/109345
13	Microsoft — What are passkeys and why they matter	https://support.microsoft.com/en-us/windows/security/identity-signin/what-are-passkeys-and-why-they-matter	https://web.archive.org/web/20260722085522/https://support.microsoft.com/en-us/windows/security/identity-signin/what-are-passkeys-and-why-they-matter
14	Microsoft — Help with the Microsoft account recovery form	https://support.microsoft.com/en-us/accounts-billing/manage/help-with-the-microsoft-account-recovery-form	https://web.archive.org/web/20260727062121/https://support.microsoft.com/en-us/accounts-billing/manage/help-with-the-microsoft-account-recovery-form
15	Microsoft — How to get a Microsoft account recovery code	https://support.microsoft.com/en-us/accounts-billing/manage/how-to-get-a-microsoft-account-recovery-code	https://web.archive.org/web/20260713003505/https://support.microsoft.com/en-us/accounts-billing/manage/how-to-get-a-microsoft-account-recovery-code
16	Microsoft Entra — Passkeys by default and SMS/voice retirement	https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement	https://web.archive.org/web/20260724230317/https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement
17	GitHub — Managing your passkeys	https://docs.github.com/en/authentication/authenticating-with-a-passkey/managing-your-passkeys	https://web.archive.org/web/20260708055407/https://docs.github.com/en/authentication/authenticating-with-a-passkey/managing-your-passkeys
18	GitHub — Configuring 2FA recovery methods and recovering lost credentials	https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication-recovery-methods	https://web.archive.org/web/20260716133240/https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication-recovery-methods
19	GitHub — Recovering your account if you lose 2FA credentials	https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/recovering-your-account-if-you-lose-your-2fa-credentials	https://web.archive.org/web/20260728005320/https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/recovering-your-account-if-you-lose-your-2fa-credentials
20	Google — Sign in with a passkey instead of a password	https://support.google.com/accounts/answer/13548313?hl=en	https://web.archive.org/web/20260721063041/https://support.google.com/accounts/answer/13548313?hl=en
21	Google — Fix common issues with 2-Step Verification	https://support.google.com/accounts/answer/185834?hl=en	https://web.archive.org/web/20260627232455/https://support.google.com/accounts/answer/185834?hl=en
22	Apple — About the security of passkeys	https://support.apple.com/en-us/102195	https://web.archive.org/web/20260728162533/https://support.apple.com/en-us/102195
23	Apple — About Security Keys for Apple Account	https://support.apple.com/en-gb/102637	https://web.archive.org/web/20260217211459/https://support.apple.com/en-gb/102637
24	Microsoft — SMS codes for personal accounts are being phased out	https://support.microsoft.com/en-us/accounts-billing/manage/microsoft-to-stop-sending-sms-codes-for-personal-accounts	https://web.archive.org/web/20260714002357/https://support.microsoft.com/en-us/accounts-billing/manage/microsoft-to-stop-sending-sms-codes-for-personal-accounts
25	Apple — How to use account recovery when you cannot reset your Apple Account password	https://support.apple.com/en-gb/118574	https://web.archive.org/web/20260309005225/https://support.apple.com/en-gb/118574

Privacy, OPSEC & Self-Sovereignty | CypherpunkGuide on CypherpunkGuide

After Buying Bitcoin: A 10-Step Custody Drill (2026)

First principle: self-custody is a risk transfer #

Receipt, Signing, and Recovery are different proofs #

The 10-step custody drill #

Step 1: Preserve the purchase and secure the exchange account #

Step 2: Decide how much responsibility to take today #

Step 3: Obtain the wallet from a verifiable source #

Step 4: Create the wallet and record the full recovery recipe #

Step 5: Check the backup before it carries the full balance #

Step 6: Generate a fresh address and verify every character #

Step 7: Make a risk-limiting test withdrawal #

Step 8: Establish Receipt proof #

Step 9: Establish Signing proof with a small spend #

Step 10: Establish Recovery proof, then close the operating plan #

What our isolated Bitcoin Core 31.1 drill found #

Bottom line: finish the handoff before moving the balance #

Frequently asked questions #

Should I withdraw bitcoin from an exchange immediately? #

Do I need a hardware wallet? #

Does a successful test withdrawal prove self-custody? #

Can any wallet recover my bitcoin from the seed phrase? #

What tax records should I keep after buying bitcoin? #

Cora Aegis

Primary sources and archives #

Bitcoin Password Recovery: What AI Can and Can't Do (2026)

Can a lost Bitcoin password actually be recovered? #

What AI did in one reported 2026 recovery #

AI plans the candidates; software checks them #

What our 11-run synthetic BTCRecover lab found #

BTCRecover vs Hashcat vs local AI vs a recovery service #

A seven-step offline-first recovery protocol #

How to evaluate a recovery service without surrendering the wallet #

Bottom line: choose by failure type and secret boundary #

Frequently asked questions #

Can AI recover a forgotten Bitcoin wallet password? #

Can BTCRecover brute-force any Bitcoin password? #

Is a BIP39 passphrase the same as a wallet password? #

Is it safe to give a recovery service my wallet.dat file? #

What should I do immediately after recovering access? #

Cora Aegis

Sources and archives #

Methodology — how KYC Drift records hosted-AI claims

Current pilot status #

What this dataset records #

What it deliberately does not measure #

Where values come from #

Controlled vocabulary and blank-zero rule #

Evidence, dates, and integrity #

Claim source, integrity, enforcement, freshness, and conflict #

Drift, corrections, and disputes #

Update target and current limit #

Why there are no scores #

Selection and licensing #

Bitcoin Custody Under Coercion: A Survivor's Guide 2026

Why standard custody advice fails when the threat lives at home #

The adversary-capability matrix #

Before Bitcoin: secure the device and the plan first #

Custody choices under coercion — and their honest limits #

Bitcoin’s public ledger is its own exposure #

A staged response: match the move to the moment #

When Bitcoin isn’t the answer #

Bottom Line — build a plan that fits your risk #

Frequently asked questions #

Can a hardware wallet protect me if my partner watches me use it? #

Is a decoy or “duress” wallet safe to use under coercion? #

Should I name a friend or family member in a multisig? #

What should I do first if I think my device is monitored? #

Is Bitcoin better than a bank account for leaving safely? #

References #

Cora Aegis

What Is the Cypherpunk Manifesto? A 2026 Primer

What the Cypherpunk Manifesto Actually Says #

Three Texts, One Idea: May, Hughes, and Chaum #

The Woman Who Named It: Jude Milhon #

Scoring the 1993 Predictions Against 2026 #

“Cypherpunks Write Code”: The Ethic in 2026 #

Bottom Line — Why a 1993 Essay Still Sets the Spec #

Frequently Asked Questions #

What is the Cypherpunk Manifesto? #

First principle: self-custody is a risk transfer
#

Receipt, Signing, and Recovery are different proofs
#

The 10-step custody drill
#

Step 1: Preserve the purchase and secure the exchange account
#

Step 2: Decide how much responsibility to take today
#

Step 3: Obtain the wallet from a verifiable source
#

Step 4: Create the wallet and record the full recovery recipe
#

Step 5: Check the backup before it carries the full balance
#

Step 6: Generate a fresh address and verify every character
#

Step 7: Make a risk-limiting test withdrawal
#

Step 8: Establish Receipt proof
#

Step 9: Establish Signing proof with a small spend
#

Step 10: Establish Recovery proof, then close the operating plan
#

What our isolated Bitcoin Core 31.1 drill found
#

Bottom line: finish the handoff before moving the balance
#

Frequently asked questions
#

Should I withdraw bitcoin from an exchange immediately?
#

Do I need a hardware wallet?
#

Does a successful test withdrawal prove self-custody?
#

Can any wallet recover my bitcoin from the seed phrase?
#

What tax records should I keep after buying bitcoin?
#

Primary sources and archives
#

Can a lost Bitcoin password actually be recovered?
#

What AI did in one reported 2026 recovery
#

AI plans the candidates; software checks them
#

What our 11-run synthetic BTCRecover lab found
#

BTCRecover vs Hashcat vs local AI vs a recovery service
#

A seven-step offline-first recovery protocol
#

How to evaluate a recovery service without surrendering the wallet
#

Bottom line: choose by failure type and secret boundary
#

Frequently asked questions
#

Can AI recover a forgotten Bitcoin wallet password?
#

Can BTCRecover brute-force any Bitcoin password?
#

Is a BIP39 passphrase the same as a wallet password?
#

Is it safe to give a recovery service my `wallet.dat` file?
#

What should I do immediately after recovering access?
#

Sources and archives
#

Current pilot status
#

What this dataset records
#

What it deliberately does not measure
#

Where values come from
#

Controlled vocabulary and blank-zero rule
#

Evidence, dates, and integrity
#

Claim source, integrity, enforcement, freshness, and conflict
#

Drift, corrections, and disputes
#

Update target and current limit
#

Why there are no scores
#

Selection and licensing
#

Why standard custody advice fails when the threat lives at home
#

The adversary-capability matrix
#

Before Bitcoin: secure the device and the plan first
#

Custody choices under coercion — and their honest limits
#

Bitcoin’s public ledger is its own exposure
#

A staged response: match the move to the moment
#

When Bitcoin isn’t the answer
#

Bottom Line — build a plan that fits your risk
#

Frequently asked questions
#

Can a hardware wallet protect me if my partner watches me use it?
#

Is a decoy or “duress” wallet safe to use under coercion?
#

Should I name a friend or family member in a multisig?
#

What should I do first if I think my device is monitored?
#

Is Bitcoin better than a bank account for leaving safely?
#

References
#

What the Cypherpunk Manifesto Actually Says
#

Three Texts, One Idea: May, Hughes, and Chaum
#

The Woman Who Named It: Jude Milhon
#

Scoring the 1993 Predictions Against 2026
#

“Cypherpunks Write Code”: The Ethic in 2026
#

Bottom Line — Why a 1993 Essay Still Sets the Spec
#

Frequently Asked Questions
#

What is the Cypherpunk Manifesto?
#

Who wrote the Cypherpunk Manifesto, and who coined the word “cypherpunk”?
#

How is the Cypherpunk Manifesto different from the Crypto Anarchist Manifesto?
#

Is the Cypherpunk Manifesto still relevant in 2026?
#

Do I have to be a programmer to be a cypherpunk?
#

“Delete” Is a User-Interface Illusion
#

The 2026 Vector — Your Posts Are Now AI Training Data
#

What Justine Sacco’s 12-Hour Flight Still Teaches in 2026
#

The Old-Account Audit Playbook — A Six-Step Self-Assessment
#

When the Stakes Aren’t Symmetric — Footprint Risk for Women and Targeted Individuals
#