Not a vulnerabilityThis is a fault in a measurement rather than in a system. Nothing is exploited and no party is at fault; the finding is wrong, and it is wrong in a way that survives review because the number it produces looks plausible.
What it is
A capture is turned into a claim about which page sent data to which recipient. The link between page and request is taken from the referring header in the request, or from the order in which requests appear. Both are unreliable: the header can be set by whatever issued the request, measurement instrumentation routinely rewrites it, and ordering breaks as soon as a capture spans more than one page.
Why it is a separate entry
The party named as a recipient may never have received anything from that page, and the party that did receive something disappears from the finding. A published measurement that cannot survive this objection damages the case it was meant to support and, worse, the next one by the same researcher.
How it arises
traffic attributed by referring header because it is the field that is always present
one capture spanning several pages, with requests from a later page counted against an earlier one
navigation to another site during the capture, whose traffic is then counted against the target
a redirect chain collapsed to its final host, so the intermediate recipients vanish
Not to be confused with
A recipient that is genuinely present but not named in the privacy statement is Undisclosed recipient, a fault in the system. This entry is about the finding: the recipient may not belong to the page at all.
How to establish it
Re-attributing the same capture through the page reference recorded in it, or through the initiator chain, produces a different set of recipients per page than attribution by referring header. The difference between the two sets is the fault.
method differentialQoD 95
Requirements on the measurement
the raw capture must be retained with its page reference intact; a summarised recipient list cannot be re-attributed
record every navigation during the capture, including redirects away from the target
keep one capture per page where feasible, so attribution does not depend on reconstruction
state which attribution route was used in the publication itself
What would refute it
automatedAttribution was already done through the page reference or the initiator chain.finding falls
automatedThe capture contains exactly one page load and no navigation, so there is nothing to confuse.finding falls
automatedBoth routes yield the same recipient set for the page in question.The finding then stands on the stronger route, and saying so is worth a sentence in the publication.finding falls
not from the captureThe raw capture no longer exists and the attribution cannot be redone.The finding cannot be repaired, only repeated. Report it as unverifiable rather than as sound.weakens
Where this plugs into existing processes
The one question that surfaces itHow do you know that this request came from that page?
In a DPIA, verify this
Verify how the assessment's supporting measurement attributed traffic to pages before relying on its recipient list.
As a procurement clause
Measurements delivered by a supplier state their attribution route, and the raw capture is delivered with them.
With a complaint, hand over
The raw capture, the attribution route used, and the recipient list produced by that route rather than a summary.
Reproduction
METHOD.md · by hand · no dedicated reproduction exists yet; follow the general method and the indicator above
Legal framing
eu-gdpr-5-2
Objections, and the answer
“The header is what the browser sends, so it is authoritative.”
It is what the issuing party chose to send. Instrumentation rewrites it as a matter of routine, and a field that anything may set cannot establish who caused a request.
“The finding was correct anyway.”
Then it survives re-attribution, which costs one pass over the capture you already have. Doing it is cheaper than defending it later.
“Nobody checks this.”
The party you named will, and it is the first thing their technical people will look at.
What this does not establish
harm; the catalogue standardises a finding so it can be referred to, it does not weigh it
severity; there is no score here, by design. Weighing belongs to whoever applies the entry to a concrete case
unlawfulness; that is for a supervisory authority or a court
intent; a fault is usually a build decision, not a plan
absence: not finding it in one capture is not evidence that it is not there
DPE Catalogue. DPE-2026-0026: Recipient attributed by a spoofable header. Schema 2.0, entry status active. Retrieved from https://totaledigitalewaarborging.nl/register/DPE-2026-0026
Measurement
When you publish a finding, cite the method version alongside the entry: “DPE-2026-0026, established under DPE Measurement Method 1.0”
Identifiers are permanent and are never
reused. An entry that is deprecated keeps its number and its address, with the reason attached, because
references to it exist elsewhere.