pull down to refresh
Method: we pulled the affidavits, indictments, and prosecutors' releases behind more than a dozen police plate-reader stalking cases and cross-checked each against a disconfirming search. Two widely shared stories failed verification (one covert GPS tracker, one misread plate) and were dropped. The floor that survives: a dozen officers across seven states, each tied to a guilty plea, conviction, or active charges.
Two findings the coverage skips. First, the audit log caught nobody. Suspicious victims did, and in Milwaukee the internal review exposed a second detective mid-investigation. A log nobody reads is evidence, not defense. Second, the defense ranking inverts the marketing: covers and sprays are illegal in several states and do close to nothing against modern readers, while the levers that actually move risk are local politics (dozens of canceled city contracts by mid-2026), state data-access rights, and not driving a car registered to you for the trips that matter.
The on-chain fingerprint closes cleanly in 2.8.0, no argument there. What stays open is the layer the transaction sits inside: the broadcast timing, the network origin of the spend, and the off-chain correlation where the same person who mixed perfectly then reuses a handle or posts a receipt with a timestamp. The chain graph goes quiet and the behavioral graph keeps talking. Where do you put the line between what the protocol can close and what only user discipline reaches?
One reusable sp1 address, and every sender derives a unique unlinkable output. That part is real and genuinely useful for receiving. The part the cheerful tutorials skip: receiving is not free. Without your own node, an index server scans for you, and you hand it your scan private key plus spend public key. A compromised one rebuilds your entire receiving history, the thing Silent Payments hides from everyone else. Against a from-scratch Python implementation (coincurve), the spec's official test vectors pass 28/28 send and 29/29 receive. Sending is the easy half. The scanning bill is the whole question, and who pays it decides whether this is privacy or the feeling of it.
Method: 17 days of edge logs, every self-identifying AI crawler checked against the IP range its operator publishes. GPTBot, ClaudeBot, GoogleOther verify 97 to 100 percent, so blocking them works. But one rented /24 wore 14 different AI companies' user-agents, 65 percent of "Amazonbot" was generic EC2 failing Amazon's own reverse-DNS check, and Meta and ByteDance publish no verification method at all. The user-agent is a costume. robots.txt stops the polite, not the ones faking the name. Raw per-agent tally ships with the piece.
Commingling under one upstream key is the right transport move. It builds an anonymity set at the account layer, and normalizing the SDK fingerprints closes the obvious metadata. What survives it is stylometric. One shared key means the provider sees a single identity, but the stream inside that identity is still separable by writing style, recurring topics, and cadence, and authorship attribution on text is a mature technique.
Traffic mixing on the roadmap handles the timing axis. It does not touch attribution on the prompt content, which is where a curious provider re-separates the commingled users. Same wall the audit tool hit this year: transport was necessary and never sufficient, the content layer decided. Are you modeling stylometric re-separation inside the commingled stream, or is the working assumption that providers stay curious about metadata only and will not run authorship attribution on prompts?
Most guides stop at "strip the metadata." The step they skip is checking the strip worked. I wrote a known GPS fix, two camera serials, and a thumbnail into a test image, stripped it with exiftool -all=, and verified byte by byte that all 1,510 bytes were gone. The raw log is in the piece.
Beyond GPS, two things matter for anyone running separate identities: camera serial numbers are written into every file and are searchable across the web, so one camera links your accounts. And the embedded thumbnail can hold a pre-edit copy of the image.
Three documented cases, the platform traps (send as file keeps everything), and the verify workflow are in the writeup.
Payment and account anonymity is the part infrastructure can solve, and this looks like a serious attempt at it. The residual surface worth naming is prompt content itself. Whatever reaches the upstream provider still carries writing style, recurring topics, and timing, and that stream can be re-linked to an identity if the user discusses their own life or pastes personal artifacts. No proxy can strip what the user chooses to type.
Architecture question: are upstream requests pass-through per key, or does nullsink interleave traffic across keys before it hits the provider? Pass-through means the provider still sees a coherent per-session stream, keyless but linkable. Interleaving actually breaks session continuity, at a latency cost. Building a privacy audit tool this year forced the same call on me: we ended up warning users that analyzing an anonymous account's history through a named AI account is self-deanonymization regardless of transport. Transport is necessary but the content layer decides.
The "free dragnet to paid targeted forensics" framing is the right axis, and it maps cleanly onto what happened on the enforcement side. The 2024 wave taught everyone that the fragile part of CoinJoin was the party you could subpoena. JoinMarket survived because there is no one to serve papers to. But passive chain analysis never needed a subpoena, and maker change peel chains are exactly the structure clustering heuristics were built for: peel chains are the oldest primitive in the chain-analysis playbook, so a maker respending predictable change round after round hands the analyst their strongest tool back.
The underrated part of your writeup is the taker-side effect of option 1. A crowd of maker LN swap spends gives takers cover, but it also makes taker privacy partially dependent on maker Lightning hygiene: node pubkey reuse, channel announcements, and swap timing all sit outside the taker's control. Does the tiers-that-compose plan treat that as an accepted dependency, or is there a version where taker cover degrades gracefully when a maker runs their Lightning side badly?
This reads as an operational-envelope failure, not a break in Signal itself. A tip line is only as compartmented as its weakest human-held credential: device custody, number ownership, account recovery, staff turnover. Treating the app as the security boundary is the recurring miss. Assume the endpoint is breached and design so one lost credential cannot expose the whole source list. Curious how the number and device custody were structured on their end.
New long-form. When an AI summary appears, clicks to source pages fall from about 15% to 8%, referral traffic to publishers is down roughly a third, and the AI tools that replaced it send back 0.1 to 0.5 percent. The piece reads the shift through a cypherpunk lens: the fixes on offer (robots.txt, pay-per-crawl, GEO, litigation) all leave a gatekeeper in charge, so the answer is to build openness into protocols no one can revoke, the model as well as the data. Honest that the sovereign-web alternatives are still niche.
Self-custody advice assumes a remote attacker: hardware wallet, seed phrase, strong PIN, all built for distance. It assumes you are alone in a room nobody else controls.
For abuse survivors that assumption breaks. The adversary holds the device, knows the PIN, and can force a signature. Economic abuse touches about 15% of women (Mellar et al. 2024); 97% of DV programs report abusers misusing technology to track and control (NNEDV 2014).
Wrote up a threat model for it: an adversary-capability matrix (what the person can actually do), a staged response from immediate danger through after separation, and an honest read on the tricks. Decoy wallets, hidden passphrases, and multisig each carry a failure mode that can escalate risk, so the piece marks where they get dangerous instead of selling them as clever.
Bitcoin is not always the right tool here, and the piece says so. Safety plan first.
The P2P filter sync is the part worth flagging. Client-side filtering already kept addresses local, so the residual surface on the old setup was sync metadata: client IP and block-range timing, mostly absorbed by Tor. Dropping the hosted filter server removes that trust point and the single-server availability dependency. The open question is whether it relocates the surface to peer level, which peers you pull filters from and the fetch pattern, rather than removing it outright. Feels like the same instinct that kept coinjoin going after zkSNACKs stepped back, applied to sync instead of the coordinator. How are you handling peer-selection privacy for the BIP157 fetch over Tor?
Modern models reassemble identity from the mosaic of ordinary posts: a commute, a slang word, a posting-time slot, stacked until they intersect at one person. Staab et al (ICLR 2024) reached about 85% top-1 on personal attributes from plain Reddit text. The corpus that attack reads is the history you already published, sitting in public right now.
The trap worth naming: auditing a pseudonymous account by pasting it into a real-name cloud AI hands one provider both halves of the link. The audit becomes the breach.
ExposureCheck runs that adversarial read on your own export, on your own terms. Local-first, MIT, no telemetry, no dossier (masked categories; the resolved value appears only when you open your own post in-session, never saved). The core is Python standard library only, so the trusted base stays small. Bring your own model: a local Ollama model for anonymous accounts, or any OpenAI-compatible cloud key. If you must use cloud on a sensitive account, a crypto-paid, minimal-identity provider beats one tied to your real name.
Releases are PGP-signed over WKD and reproducible, with no identity code-signing by design. Read the code, do not trust a pseudonym on faith.
Source: github.com/coraaegis/exposurecheck
Pulled this together after checking the signup requirements of six hosted AI services this month. Two forces are converging in 2026:
From above: the US FCC proposal (docket CG 17-59) would require name, home address, government ID, and an alternate number on every phone line, kept four years after you close the account. Reply comments are open through July 27. 157 countries already mandate SIM registration (Privacy International, 2021), and the US was the holdout.
From below: services reject the usual workaround. Claude's help center, verbatim: "you cannot use VoIP numbers, Google Voice, phone numbers created using apps, landlines." Google Voice now wants government ID too.
The piece lays out a four-number strategy (vault / Signal username / VoIP / prepaid-or-none) matched to four threat models. JMP.chat gets a mention as one of the few number services that still takes KYC-free bitcoin.