Why does squeezing a stolen object detector onto edge cameras erase the owner's watermark?

## What is actually being marked An ownership watermark on a trained model is not a tag attached to a file. It is a **behaviour**: during training the owner arranged for the network to respond in a chosen, unusual way to a small set of inputs it keeps secret. Verification later means presenting those inputs to a suspect model and checking how many of the chosen responses come back. Everything that follows comes from one fact — the mark exists **only as a shape in the weights**, so anything that rewrites the weights can rewrite the mark, and nothing that travels beside the file (names, headers, checksums) carries it at all. ## The adversary, and the limit they are working under The adversary here is a party who ended up with the weight file of a proprietary detector — say one built for camera-based retail shelf and yard auditing — and now holds it **offline**. They pay no query bill, nobody meters them, and nobody sees what they do. Their limit is not access; it is **hardware**. The stolen detector was trained to run on server accelerators, and it is worth nothing to the thief until it fits a camera's compute and memory envelope at the frame rate the customer expects. That is the whole point of this leaf: **the adversary is not aiming at the mark.** The steps they take — continuing training on their own footage so the detector works on their shelves, removing weights, lowering numeric precision, or training a smaller fresh network against the stolen copy's outputs — are steps they want for their own reasons. Mark removal is a **side effect of ordinary deployment**, not an attack. ## Why the mark is the most fragile part of the function Every one of those adaptation steps is driven by an objective measured on **the thief's data**. Continued training moves the weights in whatever direction reduces error on their footage. Compression steps are accepted or rejected on whether accuracy on their footage holds up. Distillation copies whatever behaviour their transfer inputs happen to expose. So the function is actively defended exactly where the thief measures it, and completely undefended everywhere else. The mark, by construction, lives everywhere else: it is behaviour on rare, secret inputs that the thief's footage never contains. Nothing in their pipeline notices when that behaviour changes, because nothing in their pipeline evaluates it. The mark is not targeted; it is simply **unprotected**, and unprotected behaviour drifts. This also explains a result that surprises people: the thief can report that the compressed detector matches the original's accuracy to within a fraction of a point, and the mark can still be gone. Aggregate accuracy on their data being preserved proves the adversary preserved *that*, not that the function is unchanged. ## Getting the direction of the claims right Two statements are routinely stated backwards. - **A mark that still verifies** shows the planted behaviour is present in that file. It does not show the holder tried and failed to remove it, and on its own it does not establish derivation — that needs the false-positive rate of the test on models trained independently, which is a separate and harder question. - **A mark that fails to verify** shows the behaviour is not present at the threshold used. It does not show the model is innocent. Incidental removal is the expected outcome of ordinary compression, so a negative result is close to uninformative against a copy that has been through a deployment pipeline. ## What a marking scheme has to report Because the threat is an indifferent adversary rather than a determined one, the claim that matters is a **survival budget** stated in the units of ordinary deployment work: | What is claimed | What the number must be attached to | | --- | --- | | The mark is robust | To how many epochs of further training on data unlike the owner's | | The mark survives compression | To what fraction of weights removed, at what numeric precision | | The mark survives re-distillation | To how many transfer queries, drawn from whose data | | The mark verifies | To the verification margin left at that point, and the threshold used | A marking scheme advertised as robust with none of these attached is the same empty statement as a robustness figure quoted without a perturbation radius: it names an outcome and hides the conditions that produce it. Survival should also be reported twice, because there are two adversaries. The **indifferent** one runs the compression pipeline they were going to run anyway; the **deliberate** one knows a mark may exist, adapts specifically until verification fails, and can check as they go. The indifferent adversary sets the minimum bar a scheme has to clear to be worth planting at all. The deliberate one sets the ceiling on what the resulting claim can ever be worth. ## The part that is not solved by surviving Even a mark that survives everything is only as good as the error rate of the test that reads it. Behaviour that reliably survives adaptation tends to be behaviour close to the model's ordinary function, and ordinary function is exactly what independently trained detectors also have. Survival and false-positive rate pull against each other, which is why an ownership claim is argued on both numbers or on neither.