Reupload Detection System Architecture

Most of the work in a mature enforcement programme is not new discovery. It is the same film, episode or album turning up again: re-uploaded to the platform that removed it, posted by a fresh account, mirrored to a different file host, or relinked from the same forum thread under a new URL. A reupload detection system exists to recognise that recurrence and connect it to what is already known, so the second response is faster and better informed than the first.

Case memory comes before crawling

The core component is not a crawler. It is a record of every confirmed infringement and what happened to it: the URL, the host, the uploader account, the filename, the reference used to verify it, the notice sent, the time of removal and any counter-response. Without that history, every reupload is treated as a fresh find and verified from zero.

Good case memory stores more than the link. It keeps the evidence that justified the original action, because a reupload is usually judged against that evidence. If an analyst confirmed a copy by matching a particular scene, a burned-in logo or an audio passage, the reupload check can start from the same reference rather than rebuilding it.

Matching on more than one layer

Reuploads rarely look identical to the original. Uploaders rename files, trim intros, change containers, crop frames, overlay their own logos or split a feature into parts. A system that compares only exact file hashes will miss most of them. Practical architectures match on several layers in parallel:

• Content similarity. Perceptual fingerprints of frames or audio survive re-encoding and minor edits in a way that cryptographic hashes do not. The difference is set out in cryptographic vs perceptual hashing.
• Normalised metadata. Titles are lower-cased and stripped of release tags, resolution markers and site names in the filename, then compared against the title catalogue and its known alternative and translated names.
• Account and channel identity. A new upload from an account that has been actioned before is a strong prior, even when the file looks different.
• Location and path. The same forum thread, the same folder on a file host or the same embed slot on an aggregator page often receives the replacement shortly after a removal.

Each layer proposes a link to an earlier case with its own confidence. The system combines them rather than trusting any single signal, and a weak match on one layer is never promoted to a confirmed reupload on its own.

Re-checking what was already removed

A separate scheduled process revisits removed items. Some hosts restore files after a counter-notice or an internal review. Some pages that returned an error come back when a site migrates to a new server. Some links now redirect to a different host. The re-check confirms each item is still down and, where it is not, opens a recurrence on the original case with the new state attached.

The same process watches the places that fed the original copy. If a link aggregator page pointed at a removed file, the aggregator is checked again for its replacement link. This is often where a reupload is found first, because the aggregator updates before search engines index the new file.

Faster, but still verified

The purpose of linking a recurrence to its parent case is speed with context. The analyst sees the earlier verification, the previous notice and the platform's response, and can confirm the new copy quickly. What the link must not do is replace verification. A trailer posted by the distributor, a licensed clip or a review that quotes a short scene can match the same fingerprint as a pirated copy.

For that reason the architecture treats the authorisation list as a live input rather than a setting fixed at launch. When a new territory licence is signed, a platform partner is added or the marketing team publishes official clips, those changes have to reach the matching layer before the next cycle runs. A reupload system that moves quickly against a stale whitelist will produce wrongful notices quickly, and that damages standing with exactly the platforms whose cooperation matters most.

Reporting by parent case

Reupload reporting is more useful when grouped by the case it descends from. A rights holder learns more from "this title was removed from one host and keeps returning there through new accounts" than from a flat count of links. That grouping also supports escalation: a platform that keeps hosting the same work after repeated notices can be approached with the full history rather than another single URL. Why acting on the source matters more than removing individual links is covered in source takedown vs link removal.

DigiGuardians tracks re-uploads and mirror domains as part of ongoing protection. Every detection is checked by an analyst before anything is filed, and every action is documented for the client.