Artikel · 3 juni 2026

Het houdt niet op bij de Belastingdienst: twee sites van Defensie leveren je herkenningsnummer aan de advertentiemarkt

De Tweede Kamer eist opheldering over de Adobe-tracking bij de Belastingdienst, naar aanleiding van mijn vorige artikel. En het houdt daar niet op: twee websites van het Ministerie van Defensie leveren je herkenningsnummer rechtstreeks aan een advertentie-inkoopplatform, en drie merken van de staatsbank Volksbank poolen je bezoekersprofiel. De Belastingdienst zelf doet dat laatste juist níét, en dat verschil hoort er glashelder bij. Met de echte hostnamen en een harde grens om wat ik niet kan bewijzen.

Illustratie: een man aan een tafel met koffie wordt aan zijn shirt achteruit getrokken door een figuur met een rood Adobe-logo als hoofd. Bovenaan de tekst 'niet zo tracken'. Tekening door Mick Beer

Een addendum op mijn Belastingdienst-artikel, met een vondst die verder gaat dan meten: bij Defensie wordt je herkenningsnummer rechtstreeks aan de advertentiemarkt geleverd. Maar eerst dit.

De Kamer eist nu opheldering

Dit is geen losse waarneming van één onderzoeker meer. Op 3 juni 2026 stelde JA21-Kamerlid Van den Berg, naar aanleiding van mijn Belastingdienst-artikel, Kamervragen aan staatssecretaris Eerenberg (Financiën) en staatssecretaris Aerdts (Economische Zaken en Klimaat). De vragen nemen de techniek die ik beschreef vrijwel letterlijk over, tot en met de eerste vraag die mijn artikel bij titel noemt.

Fragment van de officiële schriftelijke Kamervragen 2026Z11812: het kamerstuknummer, de datum 3 juni 2026 en de eerste twee vragen. De eerste vraag noemt het artikel van Mick Beer bij titel; de tweede citeert de doorverwijzing van adobe-analytics-dc.belastingdienst.nl naar data.adobedc.net.
Uit de officiële Kamervragen (kenmerk 2026Z11812, 3 juni 2026). De eerste vraag noemt mijn artikel bij titel; de tweede citeert de cloak-keten letterlijk. Bron: Tweede Kamer.

Van den Berg wil bevestigd zien “dat binnen Mijn Belastingdienst, na inloggen met DigiD, bij het openen van een aanslag en het starten of annuleren van een betaling via iDEAL of Wero, gegevens worden verzonden naar adobe-analytics-dc.belastingdienst.nl en dat dit domein technisch doorverwijst naar Adobe-infrastructuur, waaronder data.adobedc.net”. Dat is, woord voor woord, de cloak-keten uit mijn vorige artikel.

Hij vraagt de staatssecretarissen ook om uit te sluiten dat bedragen, BSN, IBAN, betalingskenmerk, aanslagnummer, vorderingsidentificatie, claim-identifier, IP-adres, sessiegegevens of referrers bij Adobe belanden, en naar de juridische grondslag onder de AVG voor “het meten van betaalgedrag binnen een verplichte overheidsdienst na DigiD-inlog”, inclusief noodzakelijkheid, proportionaliteit en subsidiariteit.

En dan het scherpst: het Kamerlid vraagt om het verzenden van de betaalflowgegevens naar Adobe Analytics tijdelijk stop te zetten zolang rechtmatigheid en proportionaliteit niet overtuigend zijn vastgesteld, en om binnen twee weken een tijdlijn, technische analyse, DPIA, verwerkersovereenkomst en de relevante beslisnota’s naar de Kamer te sturen. Eerenberg en Aerdts hebben drie weken om te reageren (officiële Kamervragen: Tweede Kamer, kenmerk 2026Z11812; zie ook Security.NL, 3 juni 2026).

Wat ik in mijn eigen browser zag, ligt nu als vraag op het bureau van twee staatssecretarissen. De bevindingen houden stand tot op het hoogste niveau.

En precies daarom dit addendum: dezelfde vraag moet breder gesteld worden dan die ene dienst, en aan de Defensie-kant weegt ze zwaarder, want daar blijft het niet bij meten.

In mijn vorige artikel stond één site centraal, en de conclusie was scherp maar smal: wie achter DigiD een aanslag betaalt, levert zijn gedrag plus een tweejarig herkenningsnummer in bij Adobe, ongevraagd. Twee vragen liet ik bewust open. Doet de overheid dit vaker? En blijft het bij meten? Om dat te beantwoorden heb ik honderden Nederlandse sites zelf doorgemeten: per site leg ik vast welke verzoeken er echt afvuren en naar wie. Niet wat een privacyverklaring belóóft, maar wat er feitelijk over de lijn gaat in de browser. Deze Adobe-techniek vuurde op elf van die sites. Dit stuk pakt eruit wat het minst te verdedigen is: de overheid, en wat de staat zelf bezit. Op beide open vragen is het antwoord ja.

Eén technische regel vooraf, want hij houdt het hele stuk overeind: aanwezig is niet hetzelfde als afgevuurd. Code die op een pagina staat, doet niets tot ze echt vuurt. Juist dat onderscheid houdt de Belastingdienst uit het zwaarste deel hieronder. Ik reken organisaties af op wat hun site dóét, niet op wat er dormant in een bundel ligt.

De techniek, in gewone taal

Achter veel Nederlandse sites zit Adobe Experience Cloud. Drie onderdelen, en je moet ze uit elkaar houden, want ze verschillen wezenlijk in hoe ver ze gaan.

Adobe Analytics is de meet-laag. Het registreert wat je doet en stuurt dat naar Adobe. Dat is wat de Belastingdienst draait, en zoals ik in dat artikel liet zien is dat allesbehalve onschuldig: het is een handeling-voor-handeling verslag van je betaling, vastgeknoopt aan een herkenningsnummer dat twee jaar blijft staan, dat zonder toestemming naar Adobe in de VS vertrekt. Meten dus, maar meten met naam en rugnummer.

Adobe Audience Manager gaat een stap verder. Dit is een Data Management Platform: het smeedt bezoekers tot doelgroep-profielen en kan die delen met andere systemen. Je herkent het aan verzoeken naar demdex.net, een domein dat Adobe in 2011 kocht en sindsdien bezit. Een aanroep naar dpm.demdex.net is in Adobe’s eigen woorden een “Data Provider Match”: een ID koppelen of opvragen.

De Experience Cloud ID, de ECID, is het herkenningsnummer dat alles aan elkaar knoopt. Hetzelfde nummer dat in het vorige artikel twee jaar bleef staan.

Meten is één ding. Een profiel bouwen en poolen is een tweede. Maar er is een derde stap, en die is de ernstigste: je ID actief doorgeven aan een advertentie-inkoopplatform, zodat je in de advertentieveiling herkenbaar wordt. Dat is geen meten meer, dat is je de markt op duwen. En precies dat vond ik op twee sites van Defensie.

Defensie zet je op de advertentiemarkt

Spotprent van Trump en Rutte achter een spreekgestoelte met een Amerikaanse vlag. Rutte vraagt: 'en? Nog m'n defensie data ontvangen?' Trump antwoordt: 'Tuurlijk'. Tekening door Mick Beer
Tekening door Mick Beer.

Op werkenbijdefensie.nl, de vacaturesite van het Ministerie van Defensie, vuurt de browser een verzoek af in deze vorm:

dpm.demdex.net/ibs:dpid=1586&dpuuid=1005952494248986562
   &redir=https://c1.adform.net/serving/cookie/match?party=1007&cid=${DD_UUID}&noredirect=1

Ontleed:

dpm.demdex.net/ibs:dpid=...&dpuuid=...&redir=... is volgens Adobe’s eigen documentatie het ID-sync-mechanisme. Twee systemen kunnen elkaars cookies niet lezen (dat verbiedt de browser), dus wisselen ze via zo’n verzoek hun ID’s uit en leggen ze een koppeling vast. De redir= wijst naar wie de andere partij is.

Die andere partij is Adform: c1.adform.net/serving/cookie/match. Adform is een demand-side platform, een advertentie-inkoopplatform aan de koperskant van de advertentieveiling. De cookie/match is Adforms eigen koppel-endpoint, en de cid=${DD_UUID} betekent dat Adobe’s herkennings-ID daar wordt ingevuld en doorgegeven.

Lees dat nog eens. Wie naar een baan bij Defensie kijkt, wordt door Defensie zélf herkenbaar gemaakt voor de advertentiemarkt.

Geen “er was een bezoeker”, maar: deze identiteit, klaargezet voor de advertentieveiling. Op een site van het ministerie dat over onze nationale veiligheid gaat.

En niet één keer. Ik trof drie van deze syncs aan op deze ene site, elk met een eigen herkennings-ID (1005952494248986562, 6189711310105807621, 7340252596364062959).

Het bleef ook niet bij de vacaturesite. Exact dezelfde sync (dpid=1586, doorgezet naar Adform met party=1007) vond ik op veva.nl, met dpuuid 7666712060736852904. VeVa is geen los bedrijf: het is de militaire mbo-opleiding Veiligheid en Vakmanschap ónder het Ministerie van Defensie, met Defensie in de navigatie en als afzender. Twee websites van hetzelfde ministerie, allebei schuiven ze je herkenning de advertentieketen in. Dit zijn echte waarden uit mijn scan, geen voorbeelden.

De Volksbank: drie staatsbank-merken, één gedeeld profiel

snsbank.nl, asnbank.nl en regiobank.nl zijn alle drie merken van de Volksbank, sinds de nationalisatie in 2013 voor honderd procent eigendom van de Nederlandse staat (via NLFI), en sinds 2025 samengevoegd onder de naam ASN Bank. Geen ministerie, maar wel de staat als enige aandeelhouder. In mijn scan deden de drie merken iets opvallends samen.

Alle drie vuren naar dezelfde twee gedeelde data-bron-ID’s (dpid=1957 en dpid=393426), met echte herkenningswaarden, geen lege placeholders maar concrete ID’s:

Ze publiceren doelgroepen via een gedeeld adres (snsbank.demdex.net/dest5.html) en delen een gemeenschappelijk Adobe Target-domein (snsbank.tt.omtrdc.net).

In gewone taal: de drie bankmerken poolen het bezoekersprofiel. Wie bij RegioBank kijkt en wie bij SNS kijkt, belandt onder dezelfde gedeelde data-bron-ID’s: één profiel-infrastructuur die dwars over drie merken van dezelfde staatsbank loopt. Voor een bank die zich afficheert als de “sociale”, ethische uitdager én die honderd procent van de staat is, is een merk-overstijgende advertising-DMP niet “een vraag waard”, die is moeilijk te rijmen. Eerlijk blijft eerlijk: anders dan bij Defensie zag ik hier geen doorsync naar een advertentieplatform. Het gaat om het bouwen en poolen van het profiel, niet om de stap naar Adform. Dat onderscheid hoort erbij.

En de Belastingdienst? Niet vrijgesproken, wel een ánder kwaad

Misverstand uitsluiten, want het scheelt nogal: de zwaarste stap hierboven, het uitleveren aan de advertentiemarkt, vond ik bij Defensie en niet bij de Belastingdienst. Dat is geen vrijspraak. Het is het verschil tussen twee overtredingen.

Toen ik het Belastingdienst-cluster (belastingdienst.nl, toeslagen.nl, herstel.toeslagen.nl, overdedouane.nl) langs dezelfde meetlat legde, vond ik dat het géén Audience Manager draait. De velden die bij een actief profiel horen (in vaktermen d_blob, dcs_region, een gevulde dests-lijst) ontbreken in elke serverrespons. Het /id-verzoek geeft kaal het herkenningsnummer terug, meer niet. Er gaat geen enkele aanroep naar de demdex-domeinen. Sterker nog, er staat een instelling aan (d_coppa=true) die het doorsturen naar derden juist onderdrukt. De Audience Manager-code zit dormant in de bundel die de site laadt, maar wordt niet afgevuurd. (Met als bijvangst: zelfs de tagmanager, Adobe Launch, wordt first-party verstopt via pwa001.belastingdienst.nl/adobe/, een tweede cloak-laag bovenop de eerste.)

Maak van die nuance geen verzachting. Wat de Belastingdienst wél doet, is op zichzelf een schending: achter je verplichte DigiD-inlog, zonder dat iemand je iets vraagt, vertrekt een handeling-voor-handeling verslag van je betaling naar Adobe in de Verenigde Staten, vastgeknoopt aan een herkenningsnummer dat twee jaar blijft staan. Dáár gaat het vorige artikel over, dáár gaan de Kamervragen over, en dat verwijt staat onverkort overeind. Het enige wat ik níét op de Belastingdienst plak, is de láátste stap die Defensie er bovenop zet: het actief uitleveren van je identiteit aan de advertentiemarkt.

De Belastingdienst meet je betaling uit, achter je DigiD en zonder grondslag. Defensie levert je daarbovenop uit aan de advertentiemarkt. Twee overtredingen, geen van beide te verdedigen.

Waarom dit juist bij de overheid niet te verdedigen valt

Los van elkaar is elk van deze bevindingen een datapunt. Samen raken ze de staat zelf.

Dezelfde Amerikaanse advertentietechniek, met hetzelfde soort tweejarige herkenningsnummer, draait op sites van het Ministerie van Defensie en op drie merken van een staatsbank. Op de twee Defensie-sites blijft het niet bij meten: daar wordt je identiteit actief aan een advertentie-inkoopplatform geleverd. Bij een webshop is dat een toestemmingsvraag. Bij de overheid is het een grondslagvraag, en een principiële: je kunt de Belastingdienst niet mijden, je kunt Defensie niet mijden, en je hebt nooit ja gezegd.

De staat hoort je tegen deze markt te beschermen, niet je eraan te leveren.

Dat de techniek zo consistent opduikt, is geen toeval: het is dezelfde Adobe-tagmanager (Adobe Launch) die de Audience Manager-koppeling uitrolt. Eén keer ingericht, overal hetzelfde gedrag. En op de plekken waar de doorsync naar Adform aanstaat, schuift je herkenning mee de advertentieketen in, zonder dat iemand je iets heeft gevraagd.

Hoe je het zelf kunt nalopen

Net als de vorige keer hoef je dit niet van mij aan te nemen. Het staat in je eigen browser.

Open de ontwikkelaarstools (tabblad Netwerk), bezoek een van de genoemde sites, en filter op demdex. Zie je verzoeken naar dpm.demdex.net, dan draait Audience Manager. Zie je een verzoek met ibs:dpid= en een redir= naar een advertentiedomein zoals adform.net, dan wordt er actief een ID gesynct naar dat platform; de party= en cid= laten zien naar wie en met welk ID. Zie je in het antwoord van een /id-verzoek de velden d_blob en dcs_region, dan is het volledige profiel-mechanisme actief. Staat er d_coppa=true, dan wordt het doorsturen juist onderdrukt, zoals bij de Belastingdienst.

Een kanttekening bij mijn eigen werk: de scan is een momentopname (medio mei 2026, plus de forensische Belastingdienst-opnames van 30 mei en 1 juni). Sites veranderen. Voordat je een specifieke bevinding als actueel citeert, loop hem opnieuw na, dat is ook wat ik zelf doe.

Mick Beer doet onafhankelijk privacyonderzoek op mickbeer.com. Volledig self-hosted: geen trackers, geen cookies, geen advertenties. Dit is een addendum op het Belastingdienst-betaalflow-artikel. Bevindingen uit een eigen, reproduceerbare netwerkscan; een momentopname.

Technische bron

Eigen netwerkscan (BYOM/HAR), momentopname medio mei 2026, plus de forensische Belastingdienst-opnames van 30 mei en 1 juni 2026. Reproduceerbaar en gehasht bewaard. Dit stuk beperkt zich tot de overheids- en staatsdeelnemingsentiteiten in mijn scan; de techniek draaide daarnaast op commerciële sites die hier buiten beschouwing blijven. Kernwaarden:

← terug naar artikelen