Not a vulnerabilityNothing leaks and nothing is broken into. The address is passed on deliberately, by design, and the design is the objection.
What it is
An address the person supplied for a purpose of their own, an account, an order, a newsletter, is used as a key. It is sent to other parties in the clear or, more often, as a hash of the address in lowercase with the spaces trimmed. The hash protects nothing here: any party that already holds the address computes the same value, which is precisely why that form is used. Neither side has to exchange anything with the other, because both derive the same key from a value the person handed over once.
Why it is a separate entry
An address is stable for years and follows the person across devices, browsers and applications. A cookie can be cleared; this cannot. It joins what someone did on one service to what they did on another, and usually to a name, because an address is rarely anonymous. It was given in order to be reached, not in order to be recognised elsewhere.
How it arises
an advertising tag configured to send the address field on form submission, for audience matching
a customer list uploaded from server to server for matching against a platform's own users
an identity resolution component added through a tag container
a login form that hashes the address in the browser and sends it onward in the same step
Not to be confused with
Text the visitor typed appearing in a request as content is User input to third parties; there the content itself is what travels. Here the address is used as a key, it may be hashed, and it may travel from a server rather than from the browser. Two parties exchanging identifiers of their own is Identifier synchronisation between parties; here no exchange is needed, because both sides can compute the same value from the address.
How to establish it
A request to a host under a different registrable domain containing the address entered, or the MD5, SHA-1 or SHA-256 of that address in lowercase and trimmed, in hexadecimal or base64. Compute the hashes of the test address before measuring and search the capture for those strings.
method network-with-identifierQoD 95
Requirements on the measurement
use an address that exists only for this measurement, so a match cannot have come from anywhere else
compute the hashes in advance, including a variant without normalisation, and record which one matched
search request bodies and fragments as well as query strings; matching values are usually posted rather than appended
a transfer from server to server does not appear in a browser capture at all, so absence in the capture settles nothing
What would refute it
automatedThe matched value is a hash of something other than the address, shown by recomputing the hash of the exact address against the captured value.finding falls
by handThe address travelled to a party executing a step the person asked for, such as delivering the message or the order.finding falls
not from the captureThe recipient acts only on the operator's instruction and does not use the value to recognise the person elsewhere.The transfer is visible in the capture; the purpose is not. A processing agreement of the same date is what settles it.weakens
automatedA refusal registered in the consent state removes the request.The mechanism is then present but gated, which is a different finding from an ungated one and is worth stating as such.weakens
Where this plugs into existing processes
The one question that surfaces itIf I enter an address on your site, which parties can compute that address afterwards?
In a DPIA, verify this
Verify with a test address, and a search for its hashes, which parties receive it, rather than accepting that no personal data is shared with advertising partners.
As a procurement clause
No form field and no server process transmits a customer address, in any encoding, to a party that is not executing the service the person asked for.
With a complaint, hand over
A capture containing the hash of a test address, the hashes computed in advance, and the moment the address was entered.
Reproduction
METHOD.md · by hand · no dedicated reproduction exists yet; follow the general method and the indicator above
Legal framing
eu-gdpr-5-1-b
eu-gdpr-6-1-a
eu-gdpr-13
Objections, and the answer
“It is hashed, so it is not personal data.”
A hash of an address is a pseudonym, not anonymity: every party that holds the address computes the same value, and that is exactly why it is sent. If it did not identify, it would not work.
“It is our own customer data.”
It is, until it leaves. The objection is not to holding the address but to using it as a key at another party, for a purpose it was not given for.
“It is only for suppression, so we do not advertise to existing customers.”
That purpose is testable. Suppression is a list matched once; it does not require the address to travel on every form submission or every page view.
“The recipient deletes it after matching.”
The value it matched on is the same value the person has everywhere else, so the match persists in the profile whether the input is deleted or not.
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-0031: Email address as a cross-service identifier. Schema 2.0, entry status active. Retrieved from https://totaledigitalewaarborging.nl/register/DPE-2026-0031
Measurement
When you publish a finding, cite the method version alongside the entry: “DPE-2026-0031, 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.