How to catch a forgery you cannot inspect

Anti-counterfeiting has a comfortable assumption buried in it: that you get to examine the fake.

The standard method depends on it. A code is applied to a genuine product. Somebody scans that code. The record is retrieved. If the record shows the code has already been used, or used in three countries this week, you have found a counterfeit. The record exists, its state is the signal, and the party who gets alerted is the manufacturer who issued the code in the first place.

Every part of that breaks when what has been forged is the mark itself.

Forging the mark rather than the content

A certification service issues an identifier for something it has certified. A document, a message, a product, a page. The identifier is displayed alongside as a mark, a code or a footer, and anyone who wants to check can look it up and be told what the service knows.

A mark like that invites an attack that is much lazier than defeating the certification, and much more effective. Do not bother certifying anything. Just reproduce the appearance of the mark on content that was never certified, and rely on the fact that a mark reassures people who then do not check it.

This works because the mark's value is social rather than cryptographic at the moment it is seen. A recipient glances at it, recognises the shape of it, and proceeds. The verification step is available and mostly unused. Every trust mark on the internet operates on this basis and always has.

Now consider what the certifying service can see. There is no record for the forged identifier, because it never issued one. There is no duplicate to notice, no usage count to exceed, nothing to inspect. The forgery is out in the world, doing its job, and the service holding the register is completely blind to it.

Worse, the party being harmed is not the party who can see anything. The certifier's brand is the thing being borrowed, and the recipients being deceived are strangers to it.

The signal that is already arriving

Except that it is not entirely blind, and this is the part I find satisfying.

Some proportion of recipients do check. Not most. But some, and that is enough, because when they check they present an identifier the service has never heard of.

A lookup that resolves to nothing is normally treated as noise. A typo, a truncated code, a stale link, someone testing. Individually that is exactly what it is, and every system I have seen logs these and ignores them.

But a forgery in circulation does not produce one unresolvable lookup. It produces a stream of them, all for the same identifier or the same small family of identifiers, arriving from different people who have no connection to each other, over a period, at a rate. That is not the shape of a typo. Typos are scattered and unique. A forged mark is concentrated and repeated.

So the failed lookups, the ones everyone discards, are the detection channel. They tell you a forgery exists, roughly when it started circulating, and something about how widely it has spread, all from the pattern of people trying to check something you never issued.

I filed a patent application on this in August 2026, GB2619034.8, on detecting forgery of a certification mark from unresolvable verification requests under a bounded linkability window.

The part that makes it difficult

That last clause is where the actual problem lives, and it is the reason this is not obvious.

To distinguish a forgery from noise you have to determine that multiple lookups are related and that they come from genuinely different people. Which sounds like an instruction to identify the people doing the looking.

That is precisely what you must not do. The people checking a mark are the ones behaving well. They are the cautious recipients, the ones who did not simply trust the badge. Building a system that fingerprints them in order to protect them is a bad trade, and it is the trade that most fraud-detection architecture makes without noticing.

It is also the trade that makes such a system unusable in Europe. A verification endpoint that accumulates a persistent profile of everyone who has ever checked anything is a data controller with a very difficult story about necessity and proportionality.

So the requirement has two halves that pull against each other. Correlate enough to establish that a forgery is real and spreading. Bound the correlation so that the people who checked cannot be re-identified or tracked across time. The window in which requests can be linked has to be deliberately limited, which is what the phrase bounded linkability window is doing in the title.

I am not going to set out the construction here. The framing is the useful part for anyone thinking about this: treat the correlation window as a budgeted resource rather than as something to maximise.

Why this pattern generalises

The broader idea is that a system's failures are frequently more informative than its successes, and are almost always discarded.

Successful verifications tell you the world is working. Failed ones tell you something is wrong somewhere you cannot see. Most operational architecture is built to count the former and suppress the latter, on the reasonable-sounding grounds that errors are noise.

I have made a related argument about refusals, that what you tell a rejected requester is a security decision rather than a copywriting one. This is the same observation from the other side. The refusals are where you learn what is being attempted, and most organisations discover they are under attack from the loss rather than from the logs, which is the most expensive detector available.

If you run any kind of verification endpoint, the question worth asking this week is whether anybody has looked at what fails against it. Not the error rate. The actual identifiers that did not resolve, grouped and counted over time.

My experience is that there is usually something in there, and that nobody has ever looked, because the request returned nothing and nothing felt like nothing worth keeping.