Hoe bewijs je toestemming onder de cookiewet?

De cookiewet bepaalt dat het plaatsen van cookies alleen nog mag met toestemming (behalve bij enkele functionele cookies). Mocht daar discussie over komen, dan moet de site bewijzen dat die toestemming is gegeven. De OPTA -die de cookiewet gaat handhaven- hoeft alleen maar te bewijzen dat het cookie is gezet.

Het feit dat het cookie is gezet, bewijst natuurlijk niet dat het ook met toestemming is gebeurd. De site-eigenaar zal dus meer moeten doen. Op zijn minst zou ik loggen vanaf welk IP adres en op welk moment er toestemming is gegeven, inclusief de inhoud van het cookie dat wordt geplaatst. Ook zou ik als het even kan screenshots of een screencast (filmpje) maken van de procedure: welke tekst krijg je voor de toestemmingsvraag, en wat gebeurt er na een ja of nee.

In theorie kan al dat bewijs achteraf worden vervalst, maar met een duidelijk vastgelegde procedure én een database-entry mét de cookietekst zelf denk ik dat je in de praktijk een heel eind moet komen.

En dat bewijs van die toestemming moet u ook bewaren nadat het cookie is gewist! Men kan immers ook later nog bij u komen met een claim over een vermeend illegaal geplaatst cookie. Dit bewijs moet vijf jaar bewaard moet worden, omdat dat de termijn is waarna de OPTA geen boete meer mag opleggen. Voor de juristen: artikel 5:45 Awb.

Over Arnoud Engelfriet partner

Gespecialiseerd in complexe technisch/juridische ICT-vraagstukken, octrooien en softwarelicenties.

Er zijn 42 reacties

  1. Dus ik moet 5 jaar lang een user zijn cookiewensen tracken (bij een ‘ja’ wordt namelijk meestal elke pageview het cookie wel aangepast) om aan een wet te voldoen die tegen het tracken is? En hierbij moet ik nóg meer gegevens opslaan dan ik in eerste instantie deed?

  2. In hoeverre is een IP adres in deze situatie een persoonsgegeven, als daar de bezochte pagina en tijd aan vast zit?
    Want dan krijgt het CBP het druk!

  3. Ja, want de cookiewet is bedoeld om de gebruiker meer controle te geven over wat er op zijn PC wordt uitgespookt.

  4. Wat voor zin heeft dit opslaan, aangezien bij sommige/vele mensen/bezoekers het IP adres regelmatig wijzigt?

  5. Idd met het IP adres natuurlijk… alleen voor geregistreerde gebruikers zou je verder kunnen gaan met adres en of persoonsgegevens… alleen mag dat weer niet, tenzij je teoestemming hebt gevraagd.

    Verder bedoelde ik alleen te zeggen dat 5 jr in huisige maatschappij geen zin heeft/kan hebben, gezien de korte levensduur van IP adressen gekoppeld aan bezoekers. En hoe zou de OPTA daar dan een boete aan willen hangen, want ook als website eigenaar weet jij niet wanneer iemand van IP is gewijzigd, nadat het cookie al verdwenen is.

    Gaat iedere nedelander zijn eigen IP krijgen? onee dan is het weer persoonlijke informatie :)

    Kortom heeft bijhouden alleen het nut om te kunnen aantonen dat je registreerd dat bezoekers wel of geen cookie willen en kan het geen bewijs zijn.

    Misschien dat iemand weet wat het % vast IP adressen is, maar ook dat klopt weer niet aangezien mensen ook vanaf een andere locatie zoals bijvoorbeeld werk een cookie accepteren.

    Een MACadres gaat langer mee en zou meer als bewijs kunnen dienen en lijkt mij geen persoonsgegeven.

    Of is er iemand met een andere mogelijkheid.

  6. Sommige organisaties gebruiken een Machine-ID om gebruikers te tracken, omdat een IP zo generiek is (internetcafé’s, studentenhuizen, bedrijven). Alleen dan lijkt het nóg meer op persoonsgegevens verwerken.

    Het CBP kan gelukkig makkelijk alle aanvragen aan. (LOL)

  7. Een MAC-adres is bij de gemiddelde website niet uit te lezen, je hebt alleen het IP-adres en het tijdstip. Maar dat is inderdaad vijf jaar later niet meer te vertalen naar NAW, want de provider vernietigt die koppeling een jaar na uitgifte (Wet bewaarplicht).

  8. Moet je het -voor terugkerende bezoekers- niet veel langer dan vijf jaar bewaren, aangezien het cookie waarschijnlijk steeds vernieuwd? Anders gaat iemand natuurlijk zeggen van “ja dit had je gister pas geplaatst!”.

    Dus eigenlijk sinds het laatste bezoek 5 jaar…

  9. Dan zou mbv een cookie die 1 jaar geldig is een bezoeker kunnen worden gevolgd indien hij/zij een mobiel en of laptop gebruikt.

    In theorie zou je dan een cookie willen hebben die IP-adres en sessieID bevat van het moment van de keuze. Indien de bezoeker later met zijn mobiel, tablet en of laptop (waar cookie op staat) de website weer bezoekt, kun je de toestemming gegevens updaten adhv het unieke IP met SessieID, klopt in theorie toch?
    En mag je de bezoeker op deze manier volgen?
    In theorie zou dan na een jaar alleen nog het bewijs zijn dat je registraties opslaat, toch?

    of komen er nu te veel vragen door de vaagheid naar voren ;)

  10. Weet je hoeveel bezoekers ik heb op 5 jaar tijd? Per dag heb ik er al 200k… Wie gaat dat betalen aangezien ik het dan nog maar over 1 website heb? Dan heb ik het nog niet eens over ipv6 straks waar je x-xx ips per bezoeker kunt hebben hebt. Het opslaan van ips via het tor-netwerk nog niet eens erbij geteld.

    Ik zie dit niet zitten als ik eerlijk ben :(

  11. Hmm. Zou je de toestemming kunnen coderen in het cookie? Dus een of andere code als deel van het cookie die alleen gegenereerd kon worden doordat imand op tijstip X op knop Y drukte?

  12. Ik draai elke dag een automatische backup van mijn website. Als in die code te zien is dat cookies pas gegenereerd worden als een bezoeker ergens op geklikt heeft, en ik bewaar die backups 5 jaar, dan lijkt mij dat een vrij overtuigend bewijs. Als dat zou kloppen, dan hoef je geen IP adressen te gaan loggen, en heb je zeker niks met het CBP te maken.

    Toestemming coderen in het cookie is mi onmogelijk, behalve dat je door de bezoeker een regeltje tekst laat typen waarin hij/zij toestemming geeft, en die regel logt en in de cookie plaatst. Maar in praktijk gaat niemand je cookies accepteren, vrees ik.

  13. Is het kunnen aantonen van een feilloos systeem dat alleen meet bij aanwezigheid van cookies niet bewijs genoeg? Als er zonder cookies geen enkel meetsysteem aangeslingerd wordt heb je de bewijslast toch voor elkaar?

  14. Oke. Maar een DB met Nederlandse IP’s icm een tijdstip is ook in 2 minuten opgezet en aangevuld…het verschil is niet te zien. 100% zuivere bewijslast is dus moeilijk. Het meest zuivere is de cookie zelf, maar je kunt moeilijk je klanten opbellen of ze hun cookie even willen opsturen.

  15. Dat is ook weer waar.

    Hoe het zal gaan is dat je een lijst cookies krijgt die door jou zijn gezet (met tijdstip uit de browsercache) en dan moet aantonen dat jij toestemming had daarvoor. Een goed gedocumenteerd cookiebeleid (cookiestatement) en uitleg wat elk cookie doet en waarom is dus wel het misnte.

  16. Dan zie ik als optie een uniek getal van bijvoorbeeld de unix timestamp (aantal milliseconden vanaf 1-1-1970) + een willekeurig getal van 10 cijfers: 04958735261578375904920. Die sla je in een DB en in de cookie op icm met tijdstip van het zetten. Zo heb je redelijk sluitend bewijs. Maar dan mis je nog het bewijs dat iemand op “toestaan” geklikt heeft.

  17. Ook opslaan of ieman op ja of nee heeft geklikt, zou ik dan zeggen.

    Maar wat als cookie termijn is verlopen… dan opnieuw vragen, of zoals ik al iets beschreef en soort update uitvoeren op DB en of cookierefresh?

  18. Leuk, jurist tot techneut zit hier nu nog een manier te verzinnen hoe dit koekiemonster juridisch ingedekt en geïmplementeerd moet worden. Dat zegt toch al genoeg?

    Kan ik niet een BV (oid) oprichten die ik verantwoordelijk maak voor alléén de cookies van ál mijn sites, waar ik na oprichten mijn geld weer uithaal en dat ik gewoon op de fles laat gaan als de opta met zijn megaboete aankomt… Ok, dat klinkt stom, maar ik word ook een beetje gek van die cookies :)

  19. @Emile: je moet pér cookie kunnen bewijzen dat er toestemming is gegeven. Dus als je dat neit kunt voor het oude maar wel het nieuwe, heb je toch en probleem.

    @John: nee, dát gaat je niet redden, want dan kom je in het grijze gebied van de bestuurdersaansprakelijkheid. Je kunt in zulke situaties (BV gebruiken om opzettelijk de wet te omzeilen) persoonlijk aangesproken worden voor de boetes.

  20. OK er moet een historie worden opgebouwd, maar hoeveel ruimte zou je dan nodig kunnen hebben voor je database.
    Puur als simpel voorbeeld, waarbij DB tweaking achterwege is gelaten.

    Een tabel met velden; Type; Grootte:
    - IP; char(15); 15 byte
    - IPv6; char(41); 41 byte
    - J/N; bit(1); 1 byte
    - dagtijd; datetime; 8 byte
    Is totaal gemiddeld bij 50% IPv6; 37 bytes per record

    laten we zeggen 10.000 records met keuze per dag =
    37bytes x 10.000 = 370.000bytes of 361,328125kb of 0,352859497mb per dag

    Voor 365 dagen zou dat aan DB-opslag kunnen betekenen 128,7937164mb per jaar
    En ja heb je meer record keuzes? Past het in je hosting? Werk je met backups… Do your math ;)

  21. @Emile. Vergeet niet dat het ipveld waarschijnlijk een index is in bv. je mysql database en dat indexen (om nog een beetje performance te hebben) meestal in je ram geladen worden. Daar vreet het ook nog wel iets aan ruimte weg. Zeker als je een shared hosting server hebt met 100+ klanten…

  22. Waarom zou je dit in een MySQL database willen stoppen? Je hoeft er in principe nooit meer bij, en als je er al bij moet dan is realtime lezen niet belangrijk. Je wilt dus een ding waar je snel in kunt schrijven en dat efficiënt opslaat, en dat gerust traag mag uitlezen. Een SQL database is dan niet optimaal. Gewoon een logfile in platte tekst, zou ik zeggen.

  23. Omdat je ergens (snel) moet controleren of die user ja/nee heeft gezegd. Als ie zijn cookies van de pc verwijderd ga ik hem niet nogmaals vragen ervoor.
    Ik heb het even voor de gein op een drukke site ingebouwd en daar zit ik op tijd van een paar uur al op 70%+ dat nee aanklikt. Waarbij nee o.a. betekent ‘geen analytics’. Gaat lekker moet ik zeggen… Bij nee kunnen we beter naar de servers in den haag redirecten… :(

  24. Ah. Ik dacht, als je nou het cookie stuurt zodra je de ‘ja’ hebt, dan weet je bij een ontvangen teruggezonden cookie dat dit met toestemming móet zijn gezet.

    Maar, ja, dat heeft als gevolg dat zodra iemand nee zegt je het steeds weer staat te vragen.

    Alternatief zou zijn dat je een speciaal cookie zet: “toestemming=nee”. En als dat cookie er is, dan vraag je niets.

  25. Leuk voor de mensen die CCCleaner hebben en niet weten hoe ze cookie uitzonderingen kunnen toevoegen om de herhaaldelijke vraag te voorkomen :)

    @john: Als iedereen bij Nee wordt doorgestuurd naar 1 overheidsite, zou je dan een soort DDOS aanval krijgen/genereren ;)

  26. @Emile.. daar hoop ik stiekem wel op eigenlijk :)

  27. /Facepalm

    Ben het helemaal met John eens, schieten we allemaal niet een beetje door om dit gedrocht van een wetgeving te kunnen ondersteunen?

    Waarom laten we uberhaubt mensen zonder verstand van zaken dit soort dingen vastleggen?

  28. Dus het is niet voldoende om in je privacy/cookie-statement op te nemen dat gebruikers cookies kunnen uitzetten in hun browser als ze geen cookies willen accepteren?

    • Nee, dat was de eis uit de oude wet. De nieuwe wet eist dat je toestemming vraagt en krijgt. Iets doen en dan zeggen “als u dit niet had gewild dan haal het maar weg” is niet hetzelfde als toestemming vragen. Net zoals je bij e-mailmarketing met opt-in werkt en niet met opt-out.

  29. En kijken naar de Do Not Track http header die de gebruiker meestuurt naar je site?
    Als DNT aanstaat dan is dit in principe toch al duidelijk dat er geen toestemming gegeven wordt?

    • Het probleem met DNR zit hem in de default instelling. Als DNR standaard uit staat, dan is een DNR die zegt “u mag wél tracken” een toestemming. Maar als DNR standaard op “U mag tracken” staat en je als gebruiker actief die instelling uit moet zetten, dan is het géén toestemming. De browser biedt dan alleen een opt-outmechanisme, en de wet eist opt-IN.

  30. Een klantvriendelijke manier om er een positieve draai aan te geven.

    De DNT instelling is een mooie manier om voor de bezoeker het keuzevinkje alvast Aan of Uit te zetten, waarna alleen een klik op verzenden en 5 jr opslaan nodig is… want wij willen de bezoekers toch graag van dienst zijn.

    Dus hebben wij dit alvast adhv uw standaard instellingen voor u de bezoeker ingesteld :)
    Natuurlijk wel weer vermelden of verwijzen wat de standaard instelling is en of waar deze kan worden gevonden/aangepast.

  31. Organisaties met geld zouden een notaris of een dergelijke partij een paar honderdjes per jaar kunnen betalen om zeg zes keer per jaar onaangekondigd een site te bezoeken, en dan alle cookies van die site ergens op te slaan.

    De site-eigenaar zou dan in elk geval aannemelijk kunnen maken zich (al dan niet) aan de regels te hebben gehouden.

    Maar ik vraag me af of dat al niet te ver gaat. Immers: OPTA bezoekt de site. Situatie 1: krijgt met toestemming cookies, of zonder toestemming geen cookies. Moet nu gaan liegen om de site-eigenaar te kunnen beboeten. Verwachten we dat van de OPTA? Zo ja, hebben we dan niet al een veel groter probleem?

    Situatie 2: OPTA krijgt zonder toestemming cookies. Legt terecht een boete op.

    Situatie 3: OPTA krijgt geen cookies, legt geen boete op.

    Situatie 4: er is geen situatie 4.

    Het probleem gaat dus pas ontstaan als OPTA klachten van derden serieus gaat nemen. Gezien het feit dat mijn zakelijke spam veroneindigvoudigd is vanaf het moment dat OPTA zich met de ‘bestrijding’ bezig houdt, hoeven we ons daar denk ik geen zorgen over te maken.

  32. Het is dus feitelijk en technisch onmogelijk om een tegen bewijs te creeren. Wel laat ik het anders zeggen, iemand die geen verstand heeft van programmeren, dus een standerd burger die een eigen website heeft met een paar affiliate banners is gewoon weg de klos!

  33. Ik vraag mij af wat voor impact deze wet heeft op persistent cookies (LSO). Met name voor het onthouden van een keuze zou ik een persistent cookie willen plaatsen, zodat de keuze niet zo snel door een cleaner wordt verwijdert. Staat hier nog wat over omschreven?

    • De wet noemt niet expliciet sessie- versus persistent, voor beiden gelden dezelfde regels. Alleen een respawning cookie is altijd verboden, als mensen hwet weggooien dan moet het weg blijven.

  34. Het is heel simpel en kost je niks aan db / snelheid.

    Bij onze projecten word de bezoeker bij nee gewoon naar een andere site gestuurt, twitter, facebook, overheid (mbt het ddos geintje wat hier gemaakt werd (wel een goede)).

    Bovenstaand is dus toch ook direct je bewijs. Bij ons moet iemand het accepteren, dus niks opslaan, want als u op nee drukt komt u niet op onze site.

  35. En dit verhaal met het oog naar de bezoekers. Als iemand nee klikt en op een andere site komt, zal deze sneller de back knoppen drukken en toch maar voor ja gaan.

  36. Als een website toestemming vraagt en deze toestemming vastlegt en bewaart, hoe weten de eigenaar en de OPTA dan (een jaar later) dat aan deze gebruiker toestemming is verleend (bij een controle van de OPTA?). Een IP-adres van iemand is niet uniek en kan variëren in de tijd. Het bewaren van een akkoord met bijv. een IP-adres zegt derhalve weinig en lijkt nutteloos. Is het niet beter/voldoede dat je aantoont dat de website de wettelijke regels over akkoord van de gebruiker goed toepast (dus alleen een cookie plaatst als de gebruiker akkoord gaat). Als je dat doet, komen er ook geen klachten…

Plaats een reactie

Uw reactie wordt onder bovengenoemd artikel geplaatst. ICTRecht behoudt zich het recht voor om reacties te verwijderen. Alle reacties zijn te allen tijde voor verantwoordelijkheid van de inzender.