Loading the interactive demo for "How invisible watermarking traces a leak"… The lesson text below is already here. The hands-on part loads next (requires JavaScript).
Skip the math. The workflow is simple: unique IDs in, exact file out, log lookup at the end. Everything hard lives in making the ID survive the route.
The four steps, no mystique
Embed: each CSV row becomes one file with its own recipient_id. Not a username stamp: a machine-readable payload spread invisibly.
Deliver + log: who got which file, when, at what settings. This log is half the product. Lose it and recovery names nobody.
Why exact file matters
Inspect reads the leaked bytes, not your memory of them. A preview thumbnail, a re-uploaded transcode, a screenshot: all different files with different survival odds.
Download the attachment. Hash it. Then compare.
Takeaways
- One master becomes N unique copies, one per recipient_id.
- Inspect reads the exact leaked file, not a screenshot or preview thumbnail.
- No delivery log means no attribution, even with a perfect mark.
Check yourself
Optional, local, instant. 0/2 answered.
- Inspect recovers a clean recipient ID, but you lost the delivery log. Who leaked?
- A fan sends a screenshot of the leak instead of the file. What first?
For your niche
Client galleries generate dozens of near-identical exports. The delivery log, which file went to whom, matters more than the watermark itself.
DMs, vault posts and PPV messages are different routes with different survival. Log the route per copy, not just the subscriber.
Revisions multiply copies fast. Version plus recipient in the log, or two similar leaks become indistinguishable.