Pixel, tag, SDK en tagmanager zijn vier dingen
De woorden voor het meetgereedschap worden door elkaar gebruikt, terwijl ze verschillen in wat ze mogen, wat ze zien en wie ze kan aanzetten. Een pixel is een verzoek. Een tag is een stukje code. Een SDK is een meegeleverde bibliotheek met de rechten van de app zelf. Een tagmanager is een luik waardoor een marketeer na oplevering nieuwe code de pagina in schuift zonder dat er een ontwikkelaar aan te pas komt. Dat laatste is het gevaarlijkste van de vier en staat in geen enkele risicoanalyse.
De vier, uit elkaar¶
Pixel. Een verzoek aan een extern adres, verpakt als het ophalen van een plaatje van één bij één, of tegenwoordig gewoon als een verzoek zonder plaatje. Het punt is niet het plaatje. Het punt is dat het ophalen zelf de boodschap is: het verzoek draagt in zijn url en zijn headers de gegevens die de ontvanger wil hebben. Wie de url ontleedt, ziet letterlijk wat er is verstuurd. Een pixel is dus het meest transparante meetmiddel dat er is, en juist daarom raakt hij uit de mode.
Tag. Een stukje JavaScript dat in de pagina draait en beslissingen kan nemen. Een tag kan het scherm uitlezen, het formulier volgen, wachten op een gebeurtenis en dan pas een verzoek versturen. Een pixel doet één ding op één moment. Een tag is een programma met de rechten van de pagina waarop hij staat, en die rechten zijn ruim: alles wat jij op die pagina ziet en typt, kan hij in principe ook zien.
SDK. Een bibliotheek die met een app wordt meegeleverd en die draait met de rechten van die app. Dat is het grote verschil met een tag. Heeft de app toegang tot je locatie, je contacten of je camera, dan heeft elke SDK in die app dat in beginsel ook. De ontwikkelaar heeft één regel in een configuratiebestand gezet en een compleet vreemd bedrijf binnen de rechtenring van zijn app gelaten. Zie Trackers hebben rollen, en die verwar je niet en Ook een schone app kan in de databrokerlijst staan.
Tagmanager. Geen meetmiddel maar een luik. Er staat één script op de pagina, van bijvoorbeeld Google Tag Manager, en dat script haalt bij het laden een configuratie op waarin staat welke andere scripts er nog meer geladen moeten worden. Die configuratie wordt beheerd in een webinterface, buiten de code van de site om, meestal door marketing en niet door ontwikkeling.
Waarom de tagmanager de gevaarlijkste van de vier is¶
Drie redenen, en ze stapelen.
De inhoud staat niet in de code. Een beveiligingsonderzoek, een code-review of een broncodescan van de site laat één regel zien: het tagmanager-script. Wat er via dat luik binnenkomt, staat op een server van de leverancier en verandert zonder dat er iets in de repository gebeurt. Wie de site gisteren heeft goedgekeurd, heeft niets gezegd over wat er vandaag laadt.
De beslisser is niet de bouwer. Degene die een nieuwe tag aanzet, is doorgaans een marketeer met een deadline. Degene die de consequenties overziet, is een ontwikkelaar of een functionaris gegevensbescherming die niet gevraagd wordt. Dit is het patroon dat ik in vrijwel elke zaak terugzie. Zie De bouwers en de beslissers weten vaak niet van elkaar.
Het is een ketenrisico met één schakel. Wie het tagmanager-account overneemt, kan op elke pagina van de site willekeurige code uitvoeren, inclusief de betaalpagina en het inlogformulier. Dat is geen theoretisch scenario, het is de standaardroute van een hele klasse aanvallen.
De praktische toets die daaruit volgt: vraag niet welke trackers er op de site staan. Vraag wie er toegang heeft tot de tagmanager, en wanneer die lijst voor het laatst is opgeschoond.
Het vijfde ding: het server-side eindpunt¶
Er is een variant die geen van de vier is en die de andere vier onzichtbaar maakt. Bij server-side tagging stuurt de pagina alles naar één adres, meestal een subdomein van de site zelf. Die server verdeelt het vervolgens door naar de echte ontvangers. Op jouw toestel is er dan nog maar één bestemming te zien, en die ziet er eigen uit.
Voor een meting betekent dat: de afwezigheid van een trackerdomein op de lijn bewijst niets meer. Zie Server-side tagging verplaatst de tracking uit het zicht, Een browsermeting ziet alleen de eerste server en Een eigen verzamel-subdomein is geen geruststelling.
Dit is ook het punt waar mijn eigen gereedschap tegen zijn grens loopt, en ik zeg dat er liever bij dan dat iemand anders het opmerkt. Een browserscanner ziet de eerste server. Wat daarachter gebeurt, is een dossiervraag, geen meetvraag.
Waarom de woorden ertoe doen bij het opschrijven¶
Als je schrijft dat er een tracker op een pagina staat, heb je nog niets gezegd over wie hem daar heeft gezet, wie hem kan aanzetten en wat hij mag zien. Een pixel van een analysebedrijf en een SDK van een locatiebroker zijn allebei een tracker en verschillen een orde van grootte in risico.
De formulering die wel werkt, benoemt drie dingen: wat voor gereedschap het is, met welke rechten het draait, en wie het kan wijzigen zonder een release. Dat laatste is de vraag die in geen enkele privacyverklaring wordt beantwoord.