Not a vulnerabilityNothing is broken and nothing is exploited. The exchange is a deliberate feature that both parties built and both benefit from, which is exactly why it has no place in a vulnerability register.
What it is
One party calls the other and passes its own identifier for the visitor in the request; the other answers, sets or reads its own identifier, and returns the pairing. Usually this runs as a short chain of redirects or invisible image requests at page load. Afterwards each party can translate its own identifier into the other's.
Why it is a separate entry
Two separate records become one. Data collected in one place, under one story about what it is for, can from that moment be matched with data collected somewhere else entirely. The person cannot see this happen, and deleting a cookie at one party does not undo the mapping already stored at the other.
How it arises
a match or sync endpoint invoked automatically when a tag loads
a chain of redirects in which each hop appends its own identifier to the query string
an audience or measurement partner integrated by activating a template that includes the exchange
a match performed between servers, so no cookie is set in the browser at all and a cookie-based audit reports the parties as absent
Not to be confused with
Passing an identifier to one recipient for that recipient's own use is ordinary tracking. What distinguishes this entry is the exchange: the value of party A appears in a request to party B, and the purpose of that request is the pairing rather than any content.
How to establish it
A request to a host under one registrable domain whose URL, body or redirect location contains, verbatim or trivially encoded, an identifier value that another registrable domain set as a cookie or returned in the same capture. The match of the two values is the finding, and it holds equally where no cookie is set anywhere and the value only travels in the requests.
method network-with-identifierQoD 92
Requirements on the measurement
clean profile, so every identifier observed was minted during this capture and its origin is known
follow redirect chains fully; the pairing is often in an intermediate 302 that a summary view collapses
record cookie values as set, so the later match is against a value with a known source
capture per consent mode; the exchange frequently only runs in the accepted state
What would refute it
by handThe matching value is a page identifier, campaign code or cache buster rather than a per-visitor identifier.Compare across two clean profiles: a value that differs per profile is per-visitor, a value that is identical is not.finding falls
by handBoth hosts belong to the same registrable domain or the same declared processor.reclassify
automatedThe exchange only occurs after consent was registered.It changes the consent question, not the joining itself.weakens
not from the captureThe value passed is a per-recipient pseudonym that the receiving party cannot map back.Cannot be settled from the capture. It is a question for the operator, and it belongs in the request for comment.weakens
automatedThe identifier field in the exchange contains an unresolved template placeholder rather than a value.An attempted exchange and a completed one are different findings. Report the completed one only where the field carries an actual value.finding falls
Where this plugs into existing processes
The one question that surfaces itDoes any of your partners receive an identifier that another partner issued, and where is the arrangement between them?
In a DPIA, verify this
Verify whether any recipient receives an identifier belonging to another recipient, rather than assessing each recipient in isolation.
As a procurement clause
No party in the chain receives an identifier issued by another party, demonstrated by a capture in which no identifier value appears across two registrable domains.
With a complaint, hand over
A HAR with the redirect chain intact, the cookie value as set by the first party, and the request to the second party containing that same value.
Reproduction
METHOD.md · by hand · no dedicated reproduction exists yet; follow the general method and the indicator above
Legal framing
eu-gdpr-26
eu-gdpr-6-1-a
nl-tw-11-7a
Case law
cjeu-fashion-id
Objections, and the answer
“This is purely technical plumbing between suppliers.”
Deciding to make two datasets joinable is a decision about the purpose and the means. That the mechanism is a redirect does not make it a technicality.
“The identifiers are pseudonymous.”
Pseudonymous data is personal data under the regulation, and the entire purpose of the exchange is to keep recognising the same person across contexts.
“Users can delete their cookies.”
Deleting a cookie at one party does not remove the mapping already stored at the other. The exchange survives the deletion.
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-0016: Identifier synchronisation between parties. Schema 2.0, entry status active. Retrieved from https://totaledigitalewaarborging.nl/register/DPE-2026-0016
Measurement
When you publish a finding, cite the method version alongside the entry: “DPE-2026-0016, 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.