over mij

Cookies, Javascript, pixels en tags. Wat hebben ze gemeen?

21 januari 2021 | 10 minuten lezen | Deel dit blog viaFacebook,LinkedIn,Twitter,WhatsApp

“Wij maken gebruik van cookies en daarmee vergelijkbare technieken…”. Voor de minder oplettende internetgebruikers onder ons: deze en vergelijkbare teksten staan in cookiebanners. Maar wat zijn “cookies” en “vergelijkbare technieken” eigenlijk? Er is al veel over cookies geschreven. Deze keer een technische maar toch juridische kijk op dit onderwerp.

Bron: Mae Mu (Unsplash)

Je ontkomt niet aan het gebruik van cookies. Ze worden gebruikt om het surfgedrag op een website te analyseren of om je Google Ads campagnes door te meten. De wet schrijft een aantal zaken voor wanneer je hiervan gebruikmaakt. In dit blog leg ik uit waarom cookies en andere technieken onder de zogenaamde “cookiewet” (artikel 11.7a Telecommunicatiewet) vallen.

Wat zijn de belangrijkste regels?

De cookiewet is gebaseerd op de E-Privacyrichtlijn uit 2002. Het gebruik van cookies was op dat moment nog relatief nieuw. Het was al wel duidelijk dat deze techniek een impact zou kunnen hebben op iemands privacy. Je kan je voorstellen dat er ondertussen alleen maar meer is geïnnoveerd op gebied van cookies en andere technieken. Het is niet voor niks dat er in de EU alweer sinds 2017 over vernieuwing van de e-privacy regels wordt gesproken (zie hier en hier de geschiedenis).

Wat zijn de belangrijkste regels om rekening mee te houden? Je komt een heel eind met het beantwoorden van deze vragen:

  1. Gelden de cookieregels voor het type techniek dat ik gebruik?
  2. Wanneer moet ik toestemming vragen?
  3. Waarover moet ik informeren?

Voor de volledigheid beantwoord ik alle drie kort, maar ga ik in het vervolg van dit blog alleen in op de 'typen technieken'. Voel je daarom vrij om dit gedeelte over te slaan als je al met de regels bekend bent.

Typen techniek

In de richtlijn worden cookies en “soortgelijke programmatuur” genoemd. In cookiebanners en/of -statements wordt vaker gekozen voor de wat meer toegankelijke term “cookies en vergelijkbare technieken”. De cookiewet maakt een meer concreet onderscheid tussen technieken welke:

  1. Informatie opslaan op het apparaat
  2. Toegang verkrijgen tot informatie op het apparaat

Het gaat hier duidelijk niet alleen om cookies, maar ook om elke andere techniek waarmee informatie kan worden opgeslagen op iemands telefoon of computer. Het gaat ook om technieken die worden gebruikt om toegang te verkrijgen tot informatie. Ik kom terug op welke technieken dit specifiek zijn, maar denk hierbij aan Javascript of een tracking-pixel waarmee informatie kan worden verzameld.

Toestemming tenzij...

Voor het gebruik al deze typen technieken is toestemming vereist, tenzij deze functioneel of analytisch (kwaliteit en effectiviteit) van aard zijn. Alleen dan is toestemming niet vereist. Dit geldt bijvoorbeeld voor Google Analytics wanneer je dit volgens de Handleiding van de Autoriteit Persoonsgegevens is ingesteld.

Het vragen van toestemming doe je gewoonlijk via een cookiebanner. Hiervoor zijn kant-en-klare oplossingen beschikbaar, zoals die van Cookiebot. Het is ook erg eenvoudig om zelf een oplossing in Google Tag Manager te maken. Hierop kom ik nog eens terug in een ander blog (to-do).

Altijd informeren

Als laatste punt van aandacht is van belang dat elke website (en app) moet informeren over het gebruik van de technieken die onder de cookiewet vallen. Deze informatie zet je in de cookiebanner en op je ‘/privacy’ pagina, oftewel je privacybeleid of -statement. Hier informeer je de bezoekers in ieder geval over:

  1. De soorten persoonsgegevens die worden verzameld met de technieken;
  2. De doeleinden (analyse, functioneel of marketing etc.) en de grondslag (toestemming of een gerechtvaardigd belang);
  3. De betrokken (advertentie) partners of verwerkers;
  4. Bewaartermijnen van de cookies en de gegevens die je verzamelt.

Dit is wat de wet verwacht van elke website die cookies en/of vergelijkbare technieken inzet.

Laten we eens inzoomen op de verschillende opslag- en verzameltechnieken.

Opslag-technieken, zoals cookies

Hoe werken cookies?

Om te beginnen met het cookie. De cookies zoals wij die nu kennen zijn meer dan twee decennia geleden bedacht om afzonderlijke HTTP verzoeken als één sessie met elkaar te verbinden. Een sessie wordt door het gebruik van cookies stateful. Met stateful wordt bedoeld dat er een bepaalde status (bijv. “ingelogd” of token = 123) is die naar de server wordt mee- en weer teruggestuurd. Zonder sessies en cookies zou je bijvoorbeeld steeds opnieuw moeten inloggen. Binnen een sessie kan iemand dus zijn ingelogd en de status hiervan is vastgelegd in een cookie. Bij elk verzoek wordt dit gedeeld met de server om geprivilegieerde verzoeken te doen.

Een cookie is heel concreet een vorm van opslag in de browser. Een cookie bestaat uit een aantal parameters. Dit zijn een naam, waarde en verval moment. Dit zijn min of meer de basisinstellingen.

Cookies zoals deze inzichtelijk zijn in de Firefox hulpmiddelen onder het 'opslag' tab.

Een cookie kan je op twee manieren plaatsen, namelijk server-side (set-cookie HTTP header) of client-side in de browser. Hieronder een tweetal simpele voorbeelden van beide methoden:

// SERVERSIDE COOKIE VOORBEELD (Node JS server):
const http = require('http');
const server = http.createServer((req, res) => {
  res.setHeader('Content-Type', 'text/html');
  res.setHeader('set-Cookie', ['COOKIE-NAAM=WAARDE']);
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('ok');
}).listen(3000);
// CLIENT SIDE COOKIE VOORBEELD (Javascript):
document.cookie = "COOKIE-NAAM=WAARDE";

Het vervalmoment bepaalt de geldigheidsduur van het cookie. Een groot aantal browsers beperkt de geldigheidsduur met tracking prevention mechanismen voor client-side cookies tot maximaal 7 dagen (na het laatste bezoek). Dit zijn bijvoorbeeld Safari’s Intelligent Tracking Prevention (ITP) of Mozilla’s Enhanced Tracking Prevention (ETP). Onder omstandigheden is de bewaartermijn zelfs maximaal 1 dag. Lees dit blog van Simo Ahava of de website cookiestatus.com als je de technische ins-en-outs wil weten.

Tracking prevention heeft impact op de betrouwbaarheid van statistieken in Google Analytics vanwege de beperkingen om te tracken. Dit raakt het verdienmodel van de AdTech industrie in het hart. Door de verkorte geldigheid van een cookie wordt een gebruiker na 7 dagen niet als terugkerend maar als nieuw herkent in Google Analytics. Dit heeft zijn weerslag op de betrouwbaarheid van analyses en/of het kunnen toekennen van conversie aan een Google Ads campagne.

Naast het instellen van de naam, waarde en geldigheidsduur kan je aan een cookie ook een domein koppelen. Dit is standaard gelijk aan het domein van de website dat je bezoekt, maar dat hoeft niet zo te zijn. Het instellen van een ander domein is het fundament voor het welbekende third party (ook wel 'tracking') cookie, waarmee advertentienetwerken je surfgedrag over verschillende websites kunnen volgen. Dus, in tegenstelling tot een first party cookie is het domein van een third party cookie anders dan dat van de website dat je bezoekt. Je bezoekt bijvoorbeeld de website nu.nl, maar een cookie wordt gekoppeld aan het facebook.com domein. Dit cookie kan dan op verschillende websites worden uitgelezen door het script op de servers van facebook.com. De waarde van third party cookies is de laatste jaren sterk verminderd. Dit komt door de genoemde tracking prevention mechanismen, welke primair zijn gericht op het verhinderen van cross-site tracking. Enkel in Chrome werkt het third party cookie nog zoals voorheen, maar ook Google gaat dit cookie vanaf 2022 uitfaseren.

Nog kort even over ITP en ETP. Er zijn een paar “reparatiemogelijkheden”. Simo Ahava heeft een erg goed blog geschreven over hoe je dit kan oplossen met server-side cookies. Wil je een kant-en-klare oplossing? Bekijk dan TraceDock en Cookie Saver.

Er zijn naast de naam, waarde en geldigheidsduur nog een aantal andere cookie-instellingen (same-site, httpOnly, secure en path), maar die laten we gelet op de relevantie voor de cookieregels achterwege. De cookies zijn na 20 jaar in ieder geval nog steeds een belangrijke webtechniek.

De andere client-side opslag technieken

Cookies zijn het meest geschikt wanneer je de informatie in het cookie ook server-side wil gebruiken. Alle cookies worden bij een verzoek aan de server namelijk automatisch meegestuurd. Dit is dan ook het belangrijkste onderscheid met de volgende browsers opslag API’s.

Web Storage (localStorage en sessionStorage): In vergelijking met cookies zijn localStorage en sessionStorage wat eenvoudiger te gebruiken. Het voordeel is dat de opslagcapaciteit van Web Storage vele malen groter is dan dat van een cookie: 5mb vs. 4096 bytes.

Elke entry in Web Storage heeft een naam en een waarde. Je slaat een entry op met het Javascript:

localStorage.setItem('naam', 'waarde')

En je leest de waarde van een specifieke entry uit met de naam (key):

console.log(localStorage.getItem('naam')) // 'waarde'

Het verschil tussen beiden is dat entries in sessionStorage voor de duur van één sessie beschikbaar zijn, terwijl localStorage onbeperkt kan worden bewaard. Maar tracking prevention technieken beperken dit voor bepaalde browsers (zie hierna).

Wat kan je er zoal mee? Deze website gebruikt localStorage voor de opslag van je darkmode voorkeur.

Client-side databases (IndexedDB en Web SQL): IndexedDB is in feite een volledige client-side database, waarmee je op een meer overzichtelijke wijze gestructureerde data beschikbaar kan maken. De overhead is daardoor wat complexer, maar je hebt wel zoekfuncties (‘queries’) vergelijkbaar met die van een SQL-database. In de praktijk wordt IndexedDB bijvoorbeeld gebruikt voor Google Docs waarin je met gestructureerde data/bestanden werkt. Naast IndexedDB kan ook worden gedacht aan Web SQL.

Ook deze technieken worden geraakt door bepaalde tracking prevention technieken (ITP en ETP). Hierdoor is de opslagtermijn in de praktijk voor Safari en Firefox beperkt tot 7 dagen wanneer een entry is geplaatst door een tracker.

Zijn we volledig met bovenstaande? Nee maar hiermee heb je een beter idee welke opslagtechnieken ook onder de cookiewet vallen.

Toegang-/verzameltechnieken, zoals Javascript

Dan zijn er ook nog andere technieken waarmee gegevens worden verzameld. Je kan hierbij denken aan het gebruik van Javascript in de webbrowsers en Software Development Kits in apps.

We gebruiken Google Analytics in de browser als voorbeeld. Je kan met deze oplossing gegevens verzamelen over sessies van gebruikers. Denk hierbij aan de bezochte pagina's, iemands browser, apparaat, herkomst-url (referrer) en taal etc. etc. Google Analytics maakt gebruik van script tags, Javascript, tracking pixels en cookies. Overigens geldt dit op een vergelijkbare wijze voor het bekende Facebook-pixel. Een veelgebruikt recept dus.

Om Google Analytics te gebruiken moet je het volgende script snippit aan je html-document (in de <head>) toevoegen:

<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=UA-XXXXXXXX-X"></script>
<script>
window.dataLayer = window.dataLayer || [];
functiongtag(){dataLayer.push(arguments);}
gtag('js', newDate());

gtag('config', 'UA-XXXXXXXX-X');
</script>

Bij een bezoek aan de website wordt het Google Analytics script uitgevoerd. Vervolgens gebeurt er wat interessants, want Google Analytics verstuurt de gegevens via een 1x1 afbeelding. Een 1 pixel afbeelding dus. Dit gebruik van een afbeelding staat ook wel bekend als een tracking pixel. Een dergelijke pixel is handig, want je kan het als (niet zichtbare) afbeelding bijvoorbeeld ook opnemen in een (html) e-mail. Zo kan je dan zien op welke manier een e-mailcampagne presteert. Vergeet dan alleen niet de cookieregels… Eventueel is (separate) toestemming een vereiste en je moet altijd vooraf informeren.

Per gebeurtenis wordt er een GET-verzoek verstuurd waarmee deze informatie via de afbeelding met Google Aanalytics wordt gedeeld. Of meer volledig: via het verzoek van de afbeelding aan de Google Analytics server ontvangt Google de request headers en informatie in de url. Dit verzoek bevat ook de informatie welke in het _ga cookie is opgeslagen. Het _ga cookie bevat een unieke id, namelijk het “cid” (client id) in het het onderstaande verzoek. Hiermee kan worden gedifferentieerd tussen unieke (en nieuwe vs. bestaande) gebruikers.

Een weergave onder het netwerktab van een verzoek gericht aan het /collect tracking pixel.

Bij het versturen van het verzoek ontvangt de server van Google Analytics ook de verzoek-headers (Request Headers), waarin interessante informatie staat. Samengevat wordt de informatie per event afgeleid uit de door het Measurement Protocol gedefinieerde /collect?-URL waarmee het tracking pixel wordt opgevraagd, het first party cookie _ga cookie, en de HTTP (request) headers. Het afvuren van een Google Analytics gebeurtenis is event-based. Een event is bijvoorbeeld het bezoeken van een pagina, de actieve tijd die je doorbrengt op een website (engagement, zie voorbeeld hierboven), een scrollbeweging of het toevoegen van een product aan een winkelmand.

Er is technisch uiteraard nog meer mogelijk. Als variatie op het bovenstaande recept is het bijvoorbeeld mogelijk om het tracking pixel door een webbaken (sendBeacon) te vervangen.

Conclusie

Nu je weet wat “vergelijkbare technieken” zijn snap je waarom de zogenaamde cookiewet meer regelt dan alleen cookies. De regels zijn van toepassing wanneer je met een techniek informatie opslaat of uitleest in het apparaat van de gebruiker. Dit is ook logisch, want alleen met de opslag van een cookie kan je niet zoveel. Javascript en tracking pixels zorgen ervoor dat je measurements tot leven komen. Bij al deze technieken moet je voldoen aan de vereisten van de cookiewet.

Meer lezen?

Bekijk mijn andere blogs.

© 2021 Frank de Vries. Alle rechten voorbehouden
Privacy
RSS Feed