Een host die je toestel belt is nog geen partij die je data krijgt

Waarom een lijst met hosts zo verleidelijk is¶

Open het netwerkpaneel op een willekeurige nieuwssite en je hebt binnen tien seconden een lijst met tientallen domeinnamen. Die lijst is echt. Elke naam erin is door jouw toestel opgezocht, benaderd en beantwoord. Er is niets aan verzonnen en er valt niets tegen in te brengen.

De verleiding zit in de volgende stap. Je telt de lijst en je schrijft op: zoveel bedrijven krijgen jouw gegevens. Dat is een sterkere zin dan de lijst draagt. De lijst bewijst dat er contact was. Over de vraag wat er bij dat contact meeging, zegt hij nog niets.

Dit is de fout die het makkelijkst door een redactie komt en die je later het duurst komt te staan. Een organisatie hoeft maar één naam uit je lijst aan te wijzen die een lettertype serveert, en je hele telling staat ter discussie. Zie Label elke bevinding op bewijsniveau en Gemeten is niet bewezen.

Wat een verzoek werkelijk bewijst¶

Een uitgaand verzoek bewijst drie dingen en niet meer. Dat je toestel een naam heeft opgezocht. Dat er een verbinding tot stand kwam. En dat de andere kant iets heeft teruggestuurd, of in elk geval de kans kreeg.

Wat het niet bewijst is even goed op te schrijven. Het bewijst niet dat er een identificerend gegeven meeging. Het bewijst niet dat de ontvangende partij iets bewaarde. Het bewijst niet dat de partij die de naam bezit ook de partij is die de bytes las, want daar kan een netwerk van doorgifte tussen zitten. Zie Een browsermeting ziet alleen de eerste server.

Een browsermeting is daarmee een meting van vertrek, niet van aankomst. Elk cijfer dat je eruit haalt is een ondergrens voor het aantal betrokken partijen en tegelijk een bovengrens voor het aantal partijen waarvan je de ontvangst kunt hardmaken. Die twee grenzen liggen ver uit elkaar, en het is jouw werk om te vertellen waar je bevinding tussen die twee in staat.

De drie bakken waarin ik elke host stop¶

Elke unieke host uit een opname gaat bij mij in precies één van drie bakken. De indeling is grof met opzet, want een fijnere indeling nodigt uit tot schatten.

1  herkende partij, inhoud waargenomen
   POST met een body, een Set-Cookie met een identifier, een biedverzoek,
   een sync-aanroep met een concreet gevuld id-veld

2  aangeraakt, inhoud onbekend
   GET van een script of pixel, geen identifier in het verzoek gezien,
   geen antwoordinhoud die iets terugkoppelt

3  louter infrastructuur
   lettertype, kaarttegel, icoonpakket, videostill, een CDN dat een
   bibliotheek uitserveert

Bak 1 is wat je in een wederhoorbrief zet. Bak 2 is wat je noemt als aanwezigheid, met de zin dat de inhoud niet is vastgesteld. Bak 3 noem je apart, want die hosts staan er vaak wel en horen zelden in een ontvangerstelling thuis.

De grens tussen bak 2 en bak 3 is de lastigste, en daar hoort een waarschuwing bij. Een CDN dat een lettertype uitserveert, ziet nog steeds je IP-adres, je user agent en de pagina waarvandaan je komt. Infrastructuur is dus geen synoniem voor onschuldig. Het is een andere claim, met een andere bewijslast. Zie Wat je van een CDN haalt, laadt voor je banner.

Twee tellingen over dezelfde run¶

Het verschil dat de indeling maakt, is te becijferen. Uit de scan van 14 juli 2026 over 1.718 Nederlandse overheidssites komen twee getallen die allebei kloppen en die niets met elkaar te maken hebben.

unieke externe partijen in de hele set          582
sites waarvoor een ontvangersdossier is gemaakt 1.177
mediaan aantal ontvangers per site                  2
gemiddeld aantal ontvangers per site              3,2
negentigste percentiel                              7
hoogste enkele site                                38

Het eerste getal telt hosts over het hele corpus. Het tweede blok telt ontvangers per site. Wie de 582 in een kop zet, suggereert dat een bezoeker met 582 partijen te maken krijgt. De mediaan zegt dat het er op de doorsnee overheidssite twee zijn. Zie De ontvangers die in geen enkel verwerkingsregister staan.

Bij de commerciële set ligt het anders, en dat verschil is zelf de bevinding. Uit de scan van 18 juli 2026 over 32 nieuws- en handelssites:

unieke externe partijen in de set                283
mediaan aantal ontvangers per site                36
gemiddeld aantal ontvangers per site            37,8
negentigste percentiel                            75
hoogste enkele site                               87

Dezelfde meetlat, dezelfde browser, een factor achttien verschil in de mediaan. Zie Dezelfde meetlat voor de overheid en de app in je broekzak.

Waarom bak 3 op overheidssites de meerderheid is¶

In de overheidsset zit het grootste deel van het verkeer voor toestemming in de derde bak. Uit dezelfde scan van 14 juli 2026, in de modus waarin de bezoeker niets deed:

partij               op sites   voor toestemming   aandeel
googleapis.com            196                192     98,0 %
gstatic.com               172                168     97,7 %
jsdelivr.net               47                 47    100,0 %
cloudflare.com             42                 42    100,0 %

Kaarten, iconen, bibliotheken. Als je die vier als data-ontvanger meetelt, loopt de ontvangerstelling van een gemiddelde site hard op zonder dat er één extra byte aan persoonsgegevens is aangetoond. De juiste bevinding is dat ze voor toestemming laden en dat ze daarmee een IP-adres krijgen, wat een aparte en veel beter houdbare claim is.

Ter vergelijking staat in dezelfde run het aantal keren dat er wel aantoonbaar inhoud vertrok. Verzoeken met een body naar derden leverden 604 bevindingen op onder artikel 6 en 28 van de AVG, en nog eens 411 in de lichtere variant. In de set van 32 commerciële sites gebeurde dat op 29 van de 32.

Het geval waarin de indeling een kop van me afhield¶

Op 18 juli 2026 legde ik de buitenlandse partijen op Nederlandse nieuwssites vast voor het Telegraaf-stuk. De ruwe telling gaf 24 sites met techniek van een Chinees concern aan boord.

Vierentwintig Nederlandse sites sturen data naar China. Dat is de zin die eruit rolt als je aangeraakte hosts als ontvangers telt. Die zin heb ik niet geschreven. Achteraf bleek dat de enige houdbare keuze.

Toen ik de 24 door de drie bakken haalde, bleef er van bak 1 één geval over dat het hield: Temu, met directe browserverstrekking, een cookie en een identifier, structureel in drie van drie geldige runs. De rest was aanwezigheid van techniek met een concernband, zonder waargenomen inhoud. De publiceerbare formulering werd daarmee dat er techniek met een Chinese concernband is waargenomen op 24 sites, met bij één daarvan een vastgestelde directe verstrekking.

Dat is een saaiere zin. Hij is ook de enige die overeind blijft als een advocaat ernaar kijkt, en hij bleef overeind. In dezelfde vastlegging staat de regel die ik er die dag uit destilleerde: tel per leverancier het bewijsniveau en het aantal geldige runs, en houd vestiging en bestemming uit elkaar. Zie Waar het pakket landt en wie het kan vorderen zijn twee assen en Herkomst is geen bestemming.

Waar infrastructuur alsnog ontvanger wordt¶

De indeling is geen vrijbrief. Er zijn drie situaties waarin een host uit bak 3 doorschuift naar bak 1, en die controleer ik altijd apart.

De eerste is een eigen subdomein dat via een CNAME naar een externe partij wijst. Voor de browser is dat eigen verkeer, dus first-party cookies gaan gewoon mee. In de overheidsset gebeurde dat op 710 van de 1.718 sites. Zie CNAME-cloaking zit op vier op de tien overheidssites.

De tweede is een verzamelpunt op het eigen domein dat daarna server-side doorstuurt. Wat er vanaf die server gebeurt, ziet een browsermeting nooit. Zie Een eigen verzamel-subdomein is geen geruststelling en Server-side tagging verplaatst de tracking uit het zicht.

De derde is een CDN dat naast statische bestanden ook een script uitserveert dat identificerend gedrag vertoont. Dan is het domein infrastructuur en de lading dat niet.

Wat er in het dossier komt te staan¶

Per host leg ik vier velden vast, en die vier zijn genoeg om de bak achteraf te reconstrueren zonder de opname er weer bij te halen.

host          de naam zoals hij in de opname stond
bak           1, 2 of 3, met de reden in één regel
grondslag     welk waarnemingsfeit de bak rechtvaardigt
frequentie    in hoeveel van de n geldige runs gezien

Dat laatste veld is er omdat een eenmalige waarneming geen patroon is. Een partij die per bezoek een kleine kans heeft om af te vuren, mis je in één meting bijna altijd, en zie je in één meting soms net wel. Zie Hoe mijn scanner werkt, van bezoek tot bewijsstuk.

Werkregel. Tel nooit aangeraakte hosts als ontvangers: deel elke host in drie bakken in, herkende partij met waargenomen inhoud, aangeraakt zonder waargenomen inhoud, en louter infrastructuur, en publiceer per bak een eigen getal met de reden erbij.