DPE-2026-0020

Third party under a first-party subdomain

A subdomain of the site's own domain resolves to a third party, so its collection reads as the site's own.

In het NederlandsDerde partij onder een eigen subdomeinWat vraag ik hierover, en hoe herken ik een ontwijkend antwoord?
Chain webAPI status active
Not a vulnerabilityNothing is exploited and no control is broken. The alias is configured deliberately, usually to keep a measurement working, and the system resolves it exactly as intended.

What it is

A host under the site's own registrable domain is aliased in the domain name system to infrastructure operated by a measurement or advertising party. To the browser the requests and the cookies are first-party: they survive third-party cookie restrictions, they get first-party lifetimes, and blocklists that work on domain names do not match. The party at the other end is unchanged.

Why it is a separate entry

Every tool the person has to see who is collecting on a page reports the site itself. A visitor who checks, a researcher who scans by domain, and a browser that limits third parties all reach the same wrong conclusion, and the conclusion is wrong by construction rather than by accident.

How it arises

Not to be confused with

A resource served from a delivery network under the operator's own contract is not this entry: nothing collects there on its own account. Third-party resource loading is the opposite case, where the third party is visible as a third party. Here the recipient is a third party while presenting as the first.

How to establish it

A host under the site's own registrable domain whose name resolves through an alias chain to a name in a domain operated by another party, and which sets or receives an identifier cookie. The alias chain as resolved at capture time is the finding.

method network-with-identifierQoD 92

Requirements on the measurement

What would refute it

Where this plugs into existing processes

The one question that surfaces itWhich of your own subdomains resolve to somebody else, and who put those aliases there?
In a DPIA, verify this

Verify where each collection endpoint on your own domain actually resolves, rather than treating own-domain traffic as internal.

As a procurement clause

No host under the buyer's domain resolves to a party outside the processing chain, verifiable from the name resolution on delivery.

With a complaint, hand over

The resolution chain as recorded at capture time, the cookie set on that host with its attributes, and the requests sent to it.

Reproduction

Legal framing

Case law

Objections, and the answer

“It is our own subdomain, so it is first-party data.”

First-party is a browser concept, not a legal one. Who receives the data is established by where the name resolves, and that is measurable.

“We did it for measurement accuracy, not to evade anything.”

The effect is the same whatever the motive: the recipient becomes invisible to the visitor and to every domain-based control. Motive is not measurable, effect is.

“A scan of our site shows no trackers.”

A scan that works on domain names cannot see this by design. That is the finding, not a rebuttal of it.

What this does not establish

Related

How to cite this entry

In text
DPE-2026-0020 (Third party under a first-party subdomain)
URL
https://totaledigitalewaarborging.nl/register/DPE-2026-0020
Machine
https://totaledigitalewaarborging.nl/register/DPE-2026-0020/index.json
Full
DPE Catalogue. DPE-2026-0020: Third party under a first-party subdomain. Schema 2.0, entry status active. Retrieved from https://totaledigitalewaarborging.nl/register/DPE-2026-0020
Measurement
When you publish a finding, cite the method version alongside the entry: “DPE-2026-0020, 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.