Wat mag er nu wel en niet onder de nieuwe cookiewet? Die vraag kreeg ik vele malen de afgelopen week. Het was ook een onoverzichtelijk zootje, de procedure rond de aanpassing van de Telecommunicatiewet. En er is nog geen geconsolideerde tekst beschikbaar met de definitieve versie van dit wetsartikel. Je moet echt het dossier door en dat naast de apart gepubliceerde stemmingsuitslagen leggen om te zien wat nu concreet het wetsvoorstel wordt.
Het cookieartikel in de Telecommunicatiewet heeft als nummer 11.7a gekregen, en komt daarmee direct na het spamverbod. Volgens mijn reconstructie gaat het er dan als volgt uitzien (met onderstreept en doorgehaald de wijzigingen):
Artikel 11.7a
1. Onverminderd de Wet bescherming persoonsgegevens dient een ieder die door middel van elektronische communicatienetwerken toegang wenst te verkrijgen tot gegevens die zijn opgeslagen in de randapparatuur van een gebruiker dan wel gegevens wenst op te slaan in de randapparatuur van de gebruiker:
a. de gebruiker duidelijke en volledige informatie te verstrekken overeenkomstig de Wet bescherming persoonsgegevens, en in ieder geval omtrent de doeleinden waarvoor men toegang wenst te verkrijgen tot de desbetreffende gegevens dan wel waarvoor men gegevens wenst op te slaan, en
b. van de gebruikerondubbelzinnigetoestemming te hebben verkregen voor de desbetreffende handeling.
Een handeling als bedoeld in de aanhef, die tot doel heeft gegevens over het gebruik van verschillende diensten van de informatiemaatschappij door de gebruiker of de abonnee te verzamelen, combineren of analyseren voor commerciële, charitatieve of ideële doeleinden, wordt vermoed een verwerking van persoonsgegevens te zijn, als bedoeld in artikel 1, onderdeel b, van de Wet bescherming persoonsgegevens.
2. De in het eerste lid, onder a en b, genoemde vereisten zijn ook van toepassing in het geval op een andere wijze dan door middel van een elektronisch communicatienetwerk wordt bewerkstelligd dat via een elektronisch communicatienetwerk gegevens worden opgeslagen of toegang wordt verleend tot op het randapparaat opgeslagen gegevens.
3. Het bepaalde in het eerste en tweede lid is niet van toepassing, voor zover het de technische opslag of toegang tot gegevens betreft met als uitsluitend doel:
a. de communicatie over een elektronisch communicatienetwerk uit te voeren, of
b. de door de abonnee of gebruiker gevraagde dienst van de informatiemaatschappij te leveren en de opslag of toegang tot gegevens daarvoor strikt noodzakelijk is.
4. Bij algemene maatregel van bestuur kunnen in overeenstemming met Onze Minister van Veiligheid en Justitie nadere regels worden gegeven met betrekking tot de in het eerste lid, onder a en b, genoemde vereisten. Het College bescherming persoonsgegevens wordt om advies gevraagd over een ontwerp van bedoelde algemene maatregel van bestuur.
Het stuk over ondubbelzinnige toestemming was de kern van de zaak. Punt was hier dat de Europese richtlijn spreekt van ‘toestemming’ maar de ministerraad in eerste instantie koos voor “ondubbelzinnige” toestemming. Dat leverde felle protesten op, waarna het wetsvoorstel formeel werd ingediend met alleen “toestemming”.
Uiteindelijk is de wet toch aangenomen met een expliciet toestemmingsvereiste, maar dan indirect vastgelegd. De crux zit hem in het feit dat artikel 11.1(g) Telecommunicatiewet bepaalt dat onder «toestemming» in de Telecommunicatiewet moet worden verstaan «toestemming» als bedoeld in de Wet bescherming persoonsgegevens. Oftewel:
elke vrije, specifieke en op informatie berustende wilsuiting waarmee de betrokkene aanvaardt dat hem betreffende persoonsgegevens worden verwerkt;
Dat biedt iets meer ruimte dan de originele tekst die expliciet ondubbelzinnig toestemming wilde hebben. Echter, er zal wel degelijk nog iets gevraagd moeten worden. De cookieinstellingen van huidige browsers voldoen niet, zo verklaarde de minister eerder. Met name omdat ze standaard alle cookies accepteren, maar ook omdat je vaak alleen grofmazig wel/geen cookies kunt accepteren of alleen heel moeilijk de cookies van zeg DoubleClick of Facebook kunt weren. (En Flashcookies vaak al helemaal niet.)
Een sprankje hoop voor de marketingbranche:
De toestemming hoeft slechts eenmalig verkregen te worden en dus niet bij elke handeling opnieuw. De aanbieder kan die toestemming zelfstandig verkrijgen van de gebruiker, maar ook collectief. Dat laatste vergt voor de gebruiker slechts een enkele handeling, waarna ongestoord gebruik kan worden gemaakt van het internet en andere diensten. Het is aan de sector zelf om dit slim te organiseren. Essentieel is dat de toestemming ondubbelzinnig is, zoals bedoeld in de Wet bescherming persoonsgegevens.
Er mag dus niet worden gewerkt met een puur passief systeem waarbij de gebruiker zelf maar moet ontdekken of er wellicht cookies op zijn PC staan en wat daarmee gebeurt. Maar een actief systeem van informeren zodra het gebeurt in combinatie met een knop “hou daarmee op” zou er denk ik wel onder kunnen vallen.
De zinsnede “onverminderd de Wet bescherming persoonsgegevens” komt uit amendement 39 (aangenomen 21 juni) en
voorkomt dat de indruk ontstaat dat met het verkrijgen van toestemming voor het plaatsen of lezen van een cookie op grond van artikel 11.7a Tw ook een grond voor verwerking van de met deze cookie verzamelde persoonsgegevens in de zin van de Wbp ontstaat. Dat is uitdrukkelijk niet het geval.
Er moet dus naast het plaatsen van cookies apart (uitdrukkelijke) toestemming worden gevraagd voor het aanmaken van profielen en dergelijke waarmee persoonsgegevens van gebruikers kunnen worden vergaard. Het onderstreepte blok tekst (uit datzelfde amendement) legt daarbij de bewijslast ook nog eens bij de site, die moet bewijzen dat het cookie níet wordt ingezet om persoonsgegevens te verwerken. Kan hij dat bewijs niet rondkrijgen, dan wordt zijn cookie geacht wél een privacyschending op te leveren.
Uitgezonderd van dit alles zijn de cookies die vallen onder lid 3, oftewel de cookies met als doel communicatie mogelijk te maken of die noodzakelijk zijn om een dienst te leveren. Daaronder vallen volgens de minister onder meer cookies die instellingen onthouden:
Deze functie zorgt er bijvoorbeeld voor dat de door de gebruiker zelf gekozen persoonlijke instellingen en voorkeuren van een site (zoals de taal) worden «onthouden» bij het browsen binnen het bezochte internetdomein en bij herhaald bezoek aan dit domein. … zonder deze technische opslag of toegang tot gegevens, is communicatie met gebruik van voorkeuren en instellingen niet mogelijk dan wel uitermate moeilijk.
Hetzelfde geldt voor cookies die de bekende virtuele winkelwagentjes en bijbehorende transacties mogelijk maken of die onthouden dat je echt niet mee wilt doen aan die enquête over die website. Zolang deze cookies nergens anders voor worden gebruikt, vallen ze onder lid 3 en is er dus geen aparte toestemming voor nodig.
Overigens geldt de eis van toestemming niet alleen voor cookies. De minister noemde:
(flash)cookies, Java-scripts (sic), webtaps, spionagesoftware of soortgelijke programmatuur (waaronder zogeheten dialerpprogramma’s en inbelprogramma’s)
Met name de Javascripts fascineren me. Ik zie even niet hoe je met een Javascript meer kunt doen dan een dienst mogelijk maken. Worden er daadwerkelijk JS-applicaties gebruikt om gebruikers te tracken, of om überhaupt iets meer te doen dan alleen functionaliteit van de site mogelijk te maken?
Arnoud
Wat betreft javascripts: zie browser add-on http://www.ghostery.com/ om inzichtelijk te maken wat er zoal aan javascripts die iets met privacy van doen hebben ronddwaalt op websites (en eventueel ook voor blokkeren).
Of dit een (tracking)dienst mogelijk maakt of dit zelf doet is een kwestie van interpretatie denk ik al neig ik naar het laatste.
Even gemeen denkend, je zou een javascript op je website kunnen plaatsen met een zeer lange cache timeout. Als je dan in de JS een random token opneemt (en die zelf in je database onthoudt) die je met diezelfde JS terugstuurt naar je server, dan kun je mensen ermee volgen. Mooi dat ze daar aan gedacht hebben.
Je kan met javascipt allerlei data uit de browser plukken. Bezoek Panopticlick maar eens zonder javascript en met javascript.
Je kan ook denken aan iets anders dan cookies, bv scripts die (al dan niet een securitygat uitbuitend) lokale bestanden lezen om de gebruiker te identificeren.
@2 Marten ik vrees dat de cache niet betrouwbaar (lees: groot genoeg om langdurig bestanden te bewaren) is.
In mijn overweging of de cache nou wel of niet meedoet in dit verhaal merkte ik overigens nog een verschil op.
In de toelichting gaat het over opslag && opvragen.
In de wettekst gaat het over opvragen || opslag
NB De randapparatuur van de gebruiker? Dus als mijn browser over 5 jaar in de cloud draait…. !
Dank voor de heldere uiteenzetting.
Voor de mensen die niet kunnen wachten op invoering van de wet en nu al actie willen ondernemen op flashcookies:
Voor een overzicht van de flashcookies op JOUW computer, kun je surfen naar
http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html .
Je kunt via dit panel de instellingen van je flashcookies (en meer) wijzigen of verwijderen. Ik heb echter de vreemde ervaring dat ondanks het weigeren van flashcookies ze er na verloop van tijd toch weer opduiken. Daarom is een mooi alternatief de firefox add on Better Privacy, te vinden via Firefox add-ons of http://netticat.ath.cx/BetterPrivacy/BetterPrivacy.htm . Met deze add on kun je alle flashcookies gewoon accepteren, waardoor je geen last hebt van niet (goed) werkende sites. Bij het afsluiten van je browser laat je de add-on de flashcookies verwijderen, zodat eventuele nadelige effecten van de flashcookies beperkt zijn.
Hoe zit het met google analytics (en soortgelijke site tracking) dat doen we om er voor te zorgen dat we de site voor de klanten zo goed mogelijk kunnen inrichten
@Arnoud
Zie voor een interessante samenwerking tussen javascript en cookies ‘Evercookie’; een javascript API om persistent/re-spawning cookies te produceren. http://samy.pl/evercookie/
@6 “Zo goed mogelijk” en “strikt noodzakelijk” zijn wel verschillende dingen.
Sterker: Het is strikt noodzakelijk voor sommige websites om gerichte reclames te tonen. Immers kunnen alleen op die wijze de kosten worden gedekt. Maar ik vrees dat de giecheltoets hier roet in het eten zal gooien.
Misschien wordt met ‘Java-scripts’ gedoeld op zaken als localStorage in HTML5. We gaan van de simpele cookies steeds meer naar client-side databases in de browser, wat weer allerlei nieuew mogelijkheden opent.
@Rene brengt een goed punt naar voren. HTML5 heeft nu veel meer mogelijkheden om op de client informatie bij te houden over de gebruiker. De Local Storage is dan een alternatief voor cookies. Alleen, voor veel HTML5 web applicaties is het gebruik van local storage juist best belangrijk.
Het is een beetje een domme wet omdat het juist bepaalde technische ontwikkelingen blokkeert waardoor we best wat mooie ontwikkelingen mis kunnen lopen, alleen wegens het oogpunt van privacy. Alsof je de straat op moet met oogkleppen voor omdat je anders alle andere voetgangers kunt zien en identificeren…
Valt mij overigens op dat Silverlight niet is genoemd maar Flash wel. Daarnaast zullen er in de toekomst steeds meer browsers ontstaan met ingebouwde functionaliteit die weer gekoppeld is aan diverse websites. Mooi voorbeeld is Google Chrome, waarmee je al je browser-informatie online kunt opslaan in je Google profiel. Handig als je Chrome op meerdere computers gebruikt (zoals ik) omdat je instellingen dan overal hetzelfde zijn. (En dan vooral de bookmarks!)
Dan kun je wel cookies verbieden, maar wie blokkeert die extra intelligentie binnen de browsers zelf? Veel browsers gaan ook nog eens ingevoerde URL’s controleren met een online database om waarschuwingen te geven voor malware-sites en je ziet ook wel dat browsers soms een pre-fetch doen van pagina’s die vanaf de huidige pagina al ge-opend kunnen worden om zo het laden ervan te versnellen. De hedendaagse webbrowser is al veel te intelligent!
@Wim ten Brink: Wat je laatste punt betreft, de wetstekst spreekt niet over ‘cookies’ maar over “toegang wenst te verkrijgen tot gegevens die zijn opgeslagen in de randapparatuur van een gebruiker dan wel gegevens wenst op te slaan in de randapparatuur van de gebruiker”. Dat ziet dus ook op localStorage, in de browser ingebouwde gegevensverwerking, plugins, Silverlight etc.
@René De minister noemde een kort lijstje met daaronder JavaScript en Flash-cookies. Maar Silverlight en local storage zijn daarbij kennelijk overgeslagen.
Maar als je het verder doortrekt dan kom je terecht bij session keys die in een webpagina kunnen worden bijgehouden om weer met de volgende form POST naar de server door te sturen. Vrij van cookies maar toch informatie waarmee de gebruiker kan worden ge-identificeerd zolang hij maar via POST methodes blijft bladeren. Via GET methodes kan het ook als je de SessionID als url parameter meegeeft.
Wat mensen vooral vergeten is dat er in de browser helemaal niet zoveel bewaard hoeft te worden. Je moet alleen een unieke ID geven aan iedere bezoeker en zorgen dat die door de client wordt bijgehouden. Alleen is die bewaarmethode minder hardnekkig dan cookies omdat het afsluiten van de browser ook meestal dat ID weggooit. Maar als je een website dusdanig ontwikkelt dat gebruikers zich (gratis) moeten registreren kun je altijd weer een SessionID teruggeven naar de client wanneer hij weer inlogt. En met de opkomst van OpenID met daarbij al vele grote ID-providers zullen zo enkele grote partijen juist enorme voordelen behalen van deze wetgeving terwijl veel kleine gebruikers buitenspel worden gezet!
Arnoud doet er zelf eigenlijk ook aan mee met zijn “Tweet”-knop boven het artikel!
Klik erop en Twitter legt een relatie tussen jou en deze website! En dergelijke knoppen zijn tegenwoordig op heel veel plaatsen te vinden en geven deze grote bedrijven dus zeeen van informatie over wat populair is en wie dit populair vindt…
Wie heeft dan nog cookies nodig?
Een ieder? Wat betekent dit precies? Alle websites, alle nederlandse websites of alle websites die zich (ook) op Nederland richten? Geldt het dan misschien ook voor de site van een spaanse groente(n)boer of duitse autogarage, die meer wil opslaan dan alleen ‘instellingen’?
Ik vraag mij verder af wie er uiteindelijk verantwoordelijk zal zijn voor die gehele opt-in onzin om dat te implementeren. Vooral door moderne cloud-ontwikkelingen en het feit dat sites steeds vaker bestaan uit componenten vanuit andere sites wordt dit zeer lastig uit te voeren. Stel, je hebt binnen de domein een WordPress blog staan, en WordPress heeft cookies nodig, wat kun je dan doen? Of een winkelwagentje die door PayPal verwerkt wordt.
Waar ik vooral bang voor ben is dat de wetgeving zich alleen beperkt tot sites binnen Europa, zodat het steeds interessanter wordt om je website in het buitenland te hosten. Maar goed, de wet is nu zo’n grote chaos dat deze niet meer uitvoerbaar lijkt. Toch?
@Marcel: Het geldt echt voor een ieder, maar wel alleen als je cookies op Nederlandse computers gaat opslaan. Wat een Belg naar een Spaanse eindgebruiker stuurt, moeten ze in België en Spanje regelen. Facebook valt dus straks ook onder deze wet. Hoe dat wordt gehandhaafd is vers twee.
@Wim: Goed punt, cookies zijn niet echt nodig. Maar je zult denk ik wel íets offline moeten opslaan om mensen uit elkaar te houden (HTTP is stateless immers). Ik ben heel benieuwd of een unieke URL ook onder “gegevens” valt die een website wenst op te slaan op mijn computer.
@Arnoud, omdat veel mensen tegenwoordig een vast IP adres hebben is het IP adres al redelijk goed bruikbaar. Combineer dit met de “User Agent ID” informatie die browsers meesturen en je hebt al meer data.
Maar de truuk is gewoon dat je tijdens het bladeren steeds een SessionID doorstuurt van pagina naar pagina. Via POST methodes gaat dit onopgemerkt en via GET methodes moet je deze aan de URL toevoegen. Hedendaagse browsers schijnen bovendien de POST-data te bewaren als je van een website een bookmark genereert. Bij url’s die via GET de SessionID doorgeven zorgt een bookmark er zeker voor dat de SessionID wordt doorgegeven…
Het IP adres in combinatie met een SessionID kan ook nog eens meerdere gebruikers achter een router of wireless access point uit elkaar houden. Sowieso is het maar de vraag of ze allemaal dezelfde user agent gebruiken. En dan weet je niet of een van de diverse add-ins in je browser ook nog eens extra informatie meestuurt.
Google zal er wel voor zorgen dat mensen een opt-in doen, anders kunnen ze hun mail niet meer lezen vanuit hun browser. Maar Google onthoudt dus wie er is ingelogd en kan die informatie doorgeven aan andere Google applicaties dankzij het principe achter OpenID. Dit werkt ook voor sites buiten de Google Apps omgeving, hoewel je in die gevallen wel expliciet toestemming moet geven aan die site.
Google beheert dan het cookie en heeft daar toestemming voor van de gebruiker. En Google zelf geeft aan de andere sites een unieke ID door voor de betreffende gebruiker zodat deze later gewoon weer herkend kan worden. Daardoor kunnen die andere sites dus eenvoudig een gebruiker blijven volgen, ook al gebruiken ze zelf dus geen cookies! Geen idee of ze hierbij ook automatisch die OpenID informatie kunnen opvragen omdat er een redirect voor nodig is richting Google, maar iets dergelijks kan b.v. in JavaScript en onzichtbaar in de achtergrond worden uitgevoerd. Je krijgt zo de juiste Google ID die je aan de SessionID kunt koppelen en dan heb je zonder cookies alsnog de benodigde informatie.
Het is al wat ik zeg: grote partijen als Google, Yahoo, Microsoft en Facebook en zo die allen grote OpenID providers zijn hebben hier veel mee te winnen.
Hoe kan je voorkomen dat sites je “Nee, ik geef geen toestemming” zien als een reden om opnieuw toestemming te blijven vragen tot je uiteindelijk opgeeft en maar toestemming geeft om de site te kunnen zien.
Deze wet geeft weinig houvast voor mensen die geen toestemming geven. Deze kunnen wel aan een popup hel bloot komen te staan.
Je kunt wel in de GET sessionkeys gaan meesturen, maar hoeveel mensen gaan die vrijwillig bewaren? OpenID-sessies zullen inderdaad op het randje zitten, maar ook dat is iets waar mensen zelf bij zijn.
Hoe populair is OpenID trouwens? Ik kwam er gisteren achter dat de auteur van phpMyID ermee is gestopt, omdat tegenwoordig iedereen overal blijkbaar met zijn Facebook- of Google-account inlogt.
Simpel antwoord: Iedereen die vervolgens de pagina toevoegt aan hun favorieten!
Koppel die SessionIS ook nog eens met het IP adres en user-agent en je kunt controleren of niet iemand anders die SessionKey heeft gekaapt door dezelfde URL aan te roepen.
De populariteit van OpenID begint enorm toe te nemen, maar dat komt mede doordat de grote spelers (Facebook, Google, Yahoo) alle overige kleintjes eigenlijk wegdrukken. Hierdoor komen de mogelijkheden tot data-mining bij een steeds kleiner groepje bedrijven te liggen.
Bedenk verder dat voor veel websites het gebruik van OpenID er juist voor zorgt dat ze minder privacy-gevoelige data hoeven bij te houden! Het enige wat ze willen is een ID die ze van de provider ontvangen. Daarmee koppelen ze de rest van de gebruikers-data die ze moeten bewaren. Maar zaken zoals email adres en wachtwoord hoeven ze niet meer op te slaan, wat OpenID juist erg practisch maakt. Ik denk dat OpenID om die reden steeds populairder zal worden.
Zeker wachtwoorden zijn gevoelig omdat de meeste mensen geen tientallen wachtwoorden kunnen onthouden en dus overal hetzelfde wachtwoord gebruiken. Met OpenID heb je nog maar 1 account over waar je maar 1x op in hoeft te loggen en dan kun je op duizenden websites zo verder inloggen…
“Iedereen die vervolgens de pagina toevoegt aan hun favorieten!“
Sure, maar daar kun je als site-eigenaar nauwelijks een businessmodel op bouwen. ‘t Is hooguit een aardigheidje voor erbij.
“Met OpenID heb je nog maar 1 account over waar je maar 1x op in hoeft te loggen en dan kun je op duizenden websites zo verder inloggen…“
Je hoeft echter niet een OpenID-account te hebben bij een provider die vervolgens jouw data doorverkoopt.
@hAl:
Ha, eindelijk nog iemand die wakker is.
[Q] Hoe kan een site voorkomen je bij elk bezoek opnieuw te vragen of je getracked wilt worden?
[A] Door je te tracken.
De wet verbiedt niet tracken, de wet verbiedt het opbouwen van profielen en het parkeren van cookies die niet noodzakelijk zijn voor een dienst. Een cookie dat noodzakelijk is om het opbouwen van profielen tegen te gaan, valt onder de uitzondering en is dus legaal.
hAl heeft natuurlijk wel gelijk dat zulke cookies niet snel gezet zullen worden. Net zoals menig website bij elke bestelling weer de “ik wil op de nieuwsbrief” alvast maar aanvinkt (ja ik kijk naar jou, hotels.nl).
@wim je slaat de plank stevig mis. Je zoekt alternatieven voor sessiecookies maar die zijn noodzakelijk voor het functioneren van de website en dus (!) niet illegaal.
Daarnaast beschouw je het lijstje technologieen blijkbaar als limitatief. Het lijstje wordt echter geintroduceerd door de zin “Als voorbeelden van dergelijke handelingen die zich in de praktijk voordoen, kunnen worden genoemd het gebruik van “. Het zijn dus voorbeelden. En dan maakt het dus niet uit of het in de browser is, of binnenin de browser, of wat dan ook.
En ja, gaan die Googles, en Microsoften en Facebooks zich inderdaad druk maken om dat kleine landje ergens in Europa waar ineens OpenID niet meer zou werken?
@Richard, Wat je vergeet is dat cookies ook alleen maar een ID nodig hebben om vervoplgens op de server de bijbehorende data te koppelen aan een gebruiker. Voor het bijhouden van profielen hoef je niets bij te houden in de client, behalve dan een ID om op de server het juiste record te vinden.
Daarnaast, OpenID blijft gewoon werken omdat gebruikers daarvoor opt-innen. Ze geven dus toestemming via Google en Google houdt vervolgens de boel bij voor alle andere sites die je bezoekt en die via OpenID aan Google koppelen.
Overigens, bij Google komt er nog een eventueel extra scherm bij als je bij een site aanmeldt met Google OpenID. Op dat scherm moet je dus extra toestemming geven.
Dat vergeet ik helemaal niet; maar ik zie je punt ook niet helemaal.
Je weet dat er twee ‘smaken’ cookies zijn: de zgn. sessie-cookies die verdwijnen wanneer je je browser sluit, en de permanente(re) cookies met een bepaalde verloopdatum?
Sessie cookies zijn niet het probleem. Die zijn volatiel en kunnen niet gebruikt worden om een (niet geauthentificeerde) gebruiker te herkennen. Maar je mag straks dus wel gaan uitleggen waarom er een script op je server staat dat verwijst naar een script bij Doubleclick, wat een cookie opslaat tot 2037, en waarom je site niet zonder zou kunnen.
@Richard: Hmmm, mag je dat gaan uitleggen of mag Doubleclick dat gaan uitleggen? Zij plaatsen en lezen immers het koekje.
Doubleclick dus, https://zoek.officielebekendmakingen.nl/kst-32549-3.html:
Ik zie het probleem van cookies en vergelijkbare technieken, maar ik vind wetgeving niet het geschikte middel. Sowieso: wat wil de minister beginnen tegen buitenlandse websites?
Waarom huurt de overheid niet een software-team in om een veilige browser te maken, of waarom zorgt ze niet op zijn minst voor een keurmerk voor veilige browsers? Laat mensen daarna zelf beslissen of ze dat willen gebruiken of niet. Maar wetgeving is zo’n on-liberaal middel…
Pingback: Nieuwe Telecomwet netneutraliteit en cookiewet aangenomen | Marconcepts Internet Marketing
@Corné: Buitenlandse websites zijn een probleem, zeker, maar in EU-verband is daar wel wat aan te doen. Facebook wil écht niet uit Europa geweerd worden of boetes op dat niveau opgelegd krijgen.
Een overheidsbrowser lijkt me echt een heel slecht idee, als ik zie hoe IT-projecten bij de overheid nu gaan. Een keurmerk lijkt me dan beter, hoewel de vraag dan is waarom een browserbouwer dat keurmerk zou willen hebben. Immers hij krijgt alleen geld van zoekmachines en adverteerders, niet van consumenten, dus er is geen prikkel om de consument ter wille te zijn. Deze markt is verre van functionerend. En bij marktfalen is overheidsingrijpen gerechtvaardigd.
@Arnoud (15): Ik snap niet waarom deze wet zou gelden voor buitenlandse websites; een Amerikaanse website, gehost op een Amerikaanse server zou toch onder het Amerikaanse recht vallen? Als een Amerikaan een Nederlander beroofd in de VS valt dat toch ook niet onder Nederlands recht?
@Ralf: Deze wet geldt voor iedereen die cookies (informatie) plaatst op servers die in Nederland staan. Het maakt niet uit waar de plaatser zich bevindt. Het feit van het parkeren van het cookie gebeurt in Nederland, en dus heeft Nederland rechtsmacht.
Als jij vanuit Duitsland een pistool afschiet en mij in Nederland raakt, val je onder Nederland strafrecht omdat het gevolg van jouw handelen hier intrad. (Mogelijk val je óók onder Duits strafrecht omdat je daar handelt maar dat hangt van Duits recht af.)
In de context van cookies concludeerde de Artikel 29-werkgroep dit al in 2002 (WP 56):
@Wim jouw systeem gaat bij ons al de mist in op onze citrix servers. wij hebben 50+ gebuikers achter zelfde ip met zelfde user agent. Dus die zijn niet uit elkaar te houden. En zoals al aangegeven session cookies is geen probleem.
@Franc, mijn systeem gaat mogelijk ook mis bij ieder bedrijf waarbij de medewerkers allen achter dezelfde router zitten. Die hebben allen dus hetzelfde IP adres. Daar komt dus weer de “User Agent” bij om de hoek kijken, die per medewerker toch weer iets kan verschillen. (Zeker als medewerkers vrije keuze qua browsers en add-ons voor de browser hebben.) Citrix is dan wel weer lastiger omdat dan de gebruikers niet alleen hetzelfde IP adres hebben, maar ook grotendeels dezelfde configuratie delen. Dan moet je het weer hebben van een specifieke inlog die je kunt uitvragen. OpenID kan hier weer bij helpen omdat je dan de unieke ID van een OpenID provider ontvangt. Het inloggen bij een dergelijke provider kan bijna onopgemerkt gebeuren, zolang je maar weet welke provider dit is.
Vraag is natuurlijk ook of een adverteerder geinteresseerd is in een specifieke medewerker van een enkel bedrijf of gewoon het doen en laten van een geheel bedrijf. En dat laatste is vaak al genoeg informatie waardoor alleen al het IP adres voldoende is. Als je dan merkt dat er iemand binnen zo’n bedrijf regelmatig zoekt naar boeken op bol.com, dan kun je dus specifieke bol-reclames aanbieden voor iedereen binnen dat bedrijf! Beetje lastig als een bedrijf grotendeels uit mannen bestaat maar een vrouwelijke medewerker regelmatig een maandverband-website bezoekt want dan sla je de plank mis met je nieuwe product met vleugeltjes maar meestal zal dat wel meevallen…
@Richard, je hebt gelijk… Ik heb niet aan session cookies gedacht. Die zijn immers gewoon noodzakelijk, net als session data in webpagina’s zelf. Maar het probleem is geen cookies, session data of wat dan ook maar het feit dat de server op de een of andere manier een unieke ID aan iedere bezoeker kan toekennen om deze later weer te herkennen. Cookies zijn maar een manier om dat te doen. Maar website-bouwers zijn creatief genoeg om andere methodes te bedenken! Webbrowsers worden steeds intelligenter en er komen dus steeds meer methodes bij om te bepalen wie je bent. Er zijn zelfs websites die jouw locatie kunnen uitlezen! Geeft hen nog een methode om jou te identificeren. (Okay, ook hier moet je toestemming geven maar een instelling in Chrome kan die toestemming automatisch geven! Net zoals cookies automatisch toestemming kunnen krijgen.)
Als cookies niet mogen dan worden bezoekers aangemoedigd om in te loggen via Twitter, Facebook, Google, Yahoo of iets anders. Als dat niet kan dan moedigen ze bezoekers wel aan om een site te bookmarken, inclusief een unieke ID in de bookmark.
Bedenk ook dat men helemaal niet geinteresseerd is in wie jij bent maar alleen naar wat jij online allemaal uitspookt zodat de advertenties daarop afgestemd kunnen worden en advertenties dus veel effectiever zijn!
Welke andere technieken er mogelijk zijn? Hangt helemaal af van de browser die je gebruikt en wat je via JavaScript allemaal toestaat. Hoe meer informatie er opgevraagd kan worden van de client, des te handiger wordt het om de gebruiker te identificeren!
Maar goed, wie weet maakt er straks een bedrijf een handige add-in die iedereen wil hebben maar die daarnaast ook informatie doorstuurt naar een speciale server waarmee alsnog unieke ID’s opgevraagd kunnen worden van de client. Als de add-in er maar op draait!
Privacy moet je niet afdwingen door websites te verplichten om iets te doen. Privacy dwing je af door hoge eisen te stellen aan webbrowsers. Een keurmerk zou goed helpen. Het is de browser die de privacy moet bewaken, niet de website. Want foute websites zullen er altijd blijven…
@Arnoud
Zonder het falen van al die projecten te willen bagatelliseren is er natuurlijk wel een verschil tussen een automatiseringsproject en het ontwikkelen van een losstaand stuk software. Zeker wanneer je als basis bijvoorbeeld Firefox gebruikt en die van standaard-instellingen en/of bepaalde add-ons voorziet zou dit geen project mogen zijn wat zo complex is dat het tot mislukken gedoemd is.
Jamaar… de wet verbiedt het gebruik van dergelijke technieken. Het gaat niet om cookies, het gaat om mechanismen die de gebruiker ‘ongemerkt’ identificeren.
Ik vind deze wet betuttelend, maar als technicus kan ik niet anders stellen dan dat deze vanuit technisch oogpunt goed doordacht lijkt te zijn: de formulering dicht alle truuks, workarounds en grappen puur door het algemene concept van opslaan en/of teruglezen van gegevens (voor zover niet noodzakelijk voor de dienst) te verbieden. Dit laat voldoende ruimte voor alle noodzakelijke mechanismen terwijl het alle mechanismen die privacy raken goed aanduidt.
Aan een keurmerk voor browsers zou een bedrag gekoppeld kunnen zijn of een site waar op deze browser gepromoot wordt. Beiden kunnen interessant zijn voor browser makers. Veel van hen verdienen geld door hun gebruikers bepaalde data te laten zien of ze te sturen naar bepaalde pagina’s. Zo is bij Internet Explorer standaard Bing als zoekmachine ingesteld en heeft Firefox een “eigen” Google pagina als zoekmachine standaard ingesteld staan. Het is voor de browser makers dus wel degelijk van belang om zoveel mogelijk gebruikers te hebben.
Is een tool zoals Userfly ( http://userfly.com/ ) nu in principe illegaal?
Deze tool houd met javascript bijvoorbeeld alle bewegingen van de cursor bij van bezoekers. Je krijgt dus effectief een video waarop exact te zien is wat de bezoeker van een site precies doet, waar geklikt is etc. Verder verzameld userfly ook gegevens over de browser, land, en het ip adres.
@Arnoud, 30:
Daar heb je een punt. Maar is daar nu echt niets aan te doen?
Met een beetje geluk hoeft het alleen maar te gaan om patches op een bestaande browser, zoals bijv. de NSA ook patches heeft geleverd om Linux beter te beveiligen.
Aan de andere kant: om een moderne browser echt goed te beveiligen, moet het hele plugin-framework zodanig gemaakt worden dat plugins geen enkele mogelijkheid tot (ongeautoriseerde) ‘persistent local storage’ hebben. Aan de andere kant moeten plugins, om performance-redenen wel in machine-code geschreven kunnen zijn, en toegang kunnen hebben tot hardware-resources zoals de videokaart en de geluidskaart. Heeft iemand een idee of zoiets makkelijk te realiseren is?
Dat kan niet helemaal kloppen. Ik gebruik Firefox, en die browser heeft standaard een popup blocker aan staan. Dat is toch niet in het belang van adverteerders? Volgens mij doen in ieder geval de makers van Firefox wel het één en ander om de consument ter wille te zijn.
Nee hoor!
Een browser die een speciaal Scripting-taaltje ondersteunt kan plugins ondersteunen in scriptvorm. Als de browser daarnaast aan de plugin toegang verstrekt tot de diverse systeem-resources dan kun je in een script-taaltje net zo effectief bezig zijn als in machinecode. De Google Chrome Add-ins zijn b.v. geschreven in JavaScript met CSS en HTML! Ook andere browsers hoeven niet per definitie een binaire plug-in te ondersteunen hoewel het wel veel voorkomt. Plug-ins voor Firefox, bijvoorbeeld, hebben problemen indien deze in machinecode worden uitgebracht omdat de plug-in dan alleen maar werkt op een specifiek platform. Windows, Linux of OS-X. Het gebruik van een scripted plug-in heeft enorm veel voordelen, zeker als het om beveiliging gaat omdat iedereen de plug-in kan nakijken en omdat dan de browser voorschrijft welke resources er wel en niet gebruikt kunnen worden…
Vaak wel, maar ik zie een Flash player niet snel als script geimplementeerd zijn…
@Richard, Is dat dan noodzakelijk? Een flash player kan gewoon een vast onderdeel zijn van de browser zelf. Zo heeft Chrome al ingebouwde ondersteuning voor PDF bestanden zodat Acrobar Reader optioneel is. Hoe lang voordat iets vergelijkbaars voor Flash in Chrome zit?
Nou, eigenlijk zit Flash al een jaar ingebakken met Google Chrome! Dus geeneens een add-in maar standaard browser-gedrag…
In de wet staat: “…toegang wenst te verkrijgen tot gegevens die zijn opgeslagen in de randapparatuur van een gebruiker…”. Betekent dit, dat ook fingerprinting niet meer mag? Op veel sites wordt Fingerprinting als alternatief voor cookies aangedragen waarbij allerlei data van de browser (zoals welke fonts er op staan, de schermresolutie, welke plugins er geinstalleerd zijn etc) uitgelezen wordt waarna er een redelijk unieke ID van gemaakt wordt. Zo kunnen gebruikers toch nog gevolgd worden zonder cookie te plaatsen.
De vraag is of uitlezen van deze data gelijk is aan het toegang verkrijgen tot gegevens… wat denken jullie?
Ik denk van niet, omdat die gegevens aangeleverd worden door de browser en dus niet worden uitgelezen door de fingerprinter. Toch? Of is dit een Javascript-achtige constructie die van alles leest en dat terugrapporteert? Dan hebben we zowaar een van die vermaledijde “Java-scripts” gevonden
Ik ben even helemaal de draad kwijt. Wat mag niet meer? Het zetten van cookies of het uitlezen ervan?
Bij het aanroepen van een site stuurt de browser in de header allerlei data mee: dus de data die voor o.a. voor fingerprinting gebruikt wordt, maar ook de cookies (ja die worden telkens standaard meegestuurd). Als in de wet staat dat je geen cookies mag zetten, dan is het voor mij helder, maar als er in de wet staat dat je ze niet uit mag lezen, dan zou het “uitlezen” van data over de computer van de gebruiker zoals resolutie etc precies hetzelfde zijn, want die data wordt in dezelfde header als de cookies meegestuurd naar de webserver. Vandaar mijn vraag: is “toegang verkrijgen tot gegevens” hetzelfde als de http headers bekijken?
Ik lees: “…waarvoor men gegevens wenst op te slaan…” wordt hiermee bedoeld het opslaan van data in een cookie op de computer van een gebruiker? Als dat het geval is begrijp ik het, maar waarom dan ook nog de beperking ??????toegang wenst te verkrijgen tot gegevens die zijn opgeslagen in de randapparatuur van een gebruiker?????? deze zin kan op allerlei manieren uitgelegd worden.
@Arnoud, ik denk wel dat we er eentje hebben gevonden met dat fingerprinten, hoewel het bijbehorende script wel een beetje browser-afhankelijk is. Maar goed, er kan veel informatie over de browser worden uitgelezen en dan vooral inder Internet Explorer waar je via b.v. WMI (Windows Machine Instrumentation) zo’n beetje alle hardware mee kunt uitlezen. Werkt via JavaScript en ActiveX Maar er is hier een voorbeeld van te vinden!
Bedenk verder dat je die hardware data niet terug hoeft te sturen. Je gebruikt die informatie gewoon binnen JavaScript door alle informatie aan elkaar te plakken en dan vervolgens een hash te berekenen over de totale data. Zolang de gekozen data niet verandert is die hash ook steeds hetzelfde voor die bezoeker. Maar (vrijwel) iedere gebruiker zal toch een eigen, unieke hash hebben.
Niemand is geinteresseerd in de specifieke hardware die je hebt, maar het is wel enorm handig om alsnog een unieke sleutel te kunnen bepalen voor je bezoekers.
@Koen: Het is zowel het plaatsen als het uitlezen dat toestemming vereist. (Je kunt immers ook data uitlezen die je niet zelf geplaatst hebt.) Bij cookies gaat het dus concreet om de cookie zelf die wordt opgeslagen op de harde schijf, niet om het profiel dat jij op je server opbouwt dat je koppelt aan dat cookie.
Bij andere data is denk ik de discussie vooral of die “opgeslagen” is en uitgelezen wordt. Is een accept-header of een referer “opgeslagen” informatie? Ik denk niet dat dat bedoeld wordt.
Daarbij geldt dan ook nog dat je die informatie wél mag uitlezen als dat noodzakelijk is voor je dienstverlening. De browser vertelt jou dat hij Firefox 4 is, en daar kun je dan wat mee. In die context is het dus niet verboden die header te bekijken.
Ga je die headerinformatie gebruiken om te profilen, dan val je denk ik ook wel onder dit artikel. Hmm.. dat artikel is steeds slimmer geformuleerd
Wim, kom op, lees het wetsartikel nog eens een keertje. Daar valt fingerprinting toch echt onder.
“dient een ieder die door middel van elektronische communicatienetwerken toegang wenst te verkrijgen tot gegevens die zijn opgeslagen in de randapparatuur van een gebruiker (…) die tot doel heeft gegevens (…) te verzamelen, combineren of analyseren (…)”
@Arnoud
Dat zeg ik
Er hebben echt mensen nagedacht en alle gaatjes lijken effectief gedicht.
Gaat het hier niet om informatie die (vanuit de site gezien) ONGEVRAAGD toegezonden is geworden (door de browser)? De website heeft immers niet om deze informatie gevraagd en er is door de site geen wens kenbaar gemaakt om toegang te verkrijgen tot deze data.
Dat zou een goed tegenargument kunnen zijn ja. Maar het feit dat je iets ongevraagd krijgt, betekent nog niet dat je er alles mee mag doen – in ieder geval niet als het om persoonsgegevens gaat.
“op een andere wijze dan door middel van een elektronisch communicatienetwerk”
“wordt bewerkstelligd dat via een elektronisch communicatienetwerk”
Huh?
Ik mis op de plaats waar ik de sterretjes heb neergezet “OP het randapparaat”. Ik haal hier nu niet uit dat het ALLEEN gaat over gegevens die OP het randapparaat bewaard gaan worden. Mee eens?
@Richard zei: “Wim, kom op, lees het wetsartikel nog eens een keertje. Daar valt fingerprinting toch echt onder.” Inderdaad valt fingerprinting daar dus onder. Ik gaf ook antwoord aan Arnoud die dus dacht of we nu een JavaScript-situatie gevonden hebben die dus niet toegestaan is. Heb je goed opgemerkt! We hebben nu dus kennis van een stukje JavaScript die we waarschijnlijk niet meer mogen gebruiken…
Het gekke van deze wet is dat het eigenlijk verbiedt om bij de browser allerlei data te verzamelen om zo gebruikers-profielen op te stellen. De wet doet kennelijk niets met gebruikers-profielen die op de server opgebouwd kunnen worden met alleen maar de data die de browser toestuurt. De beperking is alleen maar op de computer van de bezoeker van toepassing. Toch niet zo slim indien browsers gewoon extra informatie zomaar meeleveren die dus gebruikt kan worden om op de server dus de data bij te houden.
Brengt mij eigenlijk bij Chrome OS van Google, wat eigenlijk een hardware-matige webbrowser is zonder locale functionaliteit. Met dat ding wordt bijna al je data online bewaard, bij voorkeur op de Google sites natuurlijk. Client-side data begint dan overbodig te worden, dus dan heeft deze wet ook weinig zin meer. En moderne ontwikkelingen gaan steeds meer richting data-opslag op servers zelf, zodat de client computers steeds “dommer” kunnen worden als het gaat om data-beheer…
@Wim, nu ik je reactie herlees snap ik je. Excuses!
@Marcel, Wim: voor fingerprinting heb je meer data nodig dan alleen dat wat in de HTTP headers meekomt*. Je moet ook gaan kijken naar geinstalleerde fonts, plugins, resolutie, en die komen niet standaard mee. Je hebt Javascript nodig om die uit te lezen.
@Richard, webbrowsers en HTTP headers worden steeds verder uitgebreid en er komt steeds meer extra informatie mee. Ten minste, er kan meer informatie meekomen indien de server hierom vraagt en de browser hier toestemming voor geeft. Toch is de hoeveelheid informatie nog vrij beperkt voor fingerprinting.
Betreffende de user-agent, combineer die 1 op 1.500 met het IP adres en het wordt al vrij uniek. Je moet dan echt als groep gebruikers achter een proxy server zitten of een Citrix-achtige omgeving gebruiken om toch enigszins gemaskeerd te zijn en is dat erg voor het fingerprinten? Niet echt, want dan heb je een profiel van een geheel bedrijf in plaats van de individuele werknemers. Dat maakt de data toch nog handig om profielen mee op te maken.
Vreemd genoeg is dit dus alleen server-side informatie en zegt de wet niets over het profileren op basis van deze data. Profielen zullen dan wat grover zijn, maar nog steeds bruikbaar…
Pingback: 24 oranges » Six things you should know about the Dutch cookie law
Ik heb vrij detaillistische kennis van het HTTP protocol maar dit kan ik niet echt plaatsen. Kan je aangeven wat je hier concreet mee bedoelt ?
Ja, dat is heel, heel erg voor het fingerprinten, zelfs veel meer dan een factor 1500 omdat het profiling bedrijf nu echt niet meer weet wie ze bij de kladden hebben. Ik denk dat je onderschat hoe gedetailleerd profielen vandaag de dag zijn. Ik zit met mijn laptop het ene moment van de dag achter dat ene IP adres op mijn werk, en een ander deel van mijn tijd met mijn iPad op een verbinding met dynamisch IP. Beide profielen zijn gelinked doordat ik met beide devices op Facebook inlog. En dus word ik nu netjes op mijn iPad achtervolgd door die paar producten die ik gedetailleerd heb bekeken in een paar webwinkels op mijn PC. Deze technieken schelen significant in de effectiviteit van online advertising, en die zijn dan echt niet meer bruikbaar.
@Richard, ook al zit HTTP nog steeds bij versie 1.1, browsers en websites zijn wel steeds meer van die headers gaan ondersteunen. Met de opkomst van REST web services is b.v. de PUT en DELETE methodes steeds meer in gebruik. Ook de HTTP headers worden steeds meer gebruikt nu steeds meer ontwikkelaars er bekend mee raken. Er zijn daarnaast een aantal headers bijgekomen die (nog) geen onderdeel zijn van de standaard, zoals “X-Do-Not-Track”, “X-Forwarded-For” en nog een aantal meer.
Als het gaat om bedrijfs-profielen dan denk ik dat dit best nog meevalt. Zeker als het gaat om kleine bedrijven en/of kleine kantoren. Je kunt dergelijke bedrijven ook nog verder profileren door ook nog eens het browse-gedrag in de gaten te houden en te kijken hoe de gebruikers van de ene site naar de andere site springen binnen de servers die je in de gaten houdt.
Daarnaast geef je al aan dat je nog een extra identificatie verzorgt doordat je op facebook bent ingelogd. Kun je ook doen met LinkedIn, Twitter en GMail en opeens ben je ook te volgen als je je verbergt achter een bedrijfs-proxy.
Daarom lijkt in deze discussie Google Chrome OS ook zo interessant. Een compleet besturings-systeem dat eigenlijk web-based is. Je start hem op, logt in met je Google account en daarna kun je doen wat je wilt, maar Google kan wel mooi jouw browse-gedrag in de gaten houden en zeer gedetailleerde profielen opbouwen terwijl andere bedrijven door deze wet dus enorm beperkt worden. (En toch ben ik zeer geinteresseerd in een Chrome OS laptop en is het vooral de prijs van die dingen die mij tegenhoudt van een aanschaf van die laptop! Oh, en hij is officieel nog niet op de Nederlandse markt…)
Prima samenvatting, heel nuttig.
Inmiddels wel: Wetsvoorstel (onderdeel AV).
Pingback: Internetrecht door Arnoud Engelfriet
Ik zou weleens een overzicht willen hebben van technieken die nog wel zijn toegestaan.
Want van het vertalen van wetsteksten naar wat technisch nog mag heb ik geen kaas gegeten.
@Jan van Westland, wat ik ervan begrepen heb is dit: Als je gegevens gekoppeld aan een gebruiker opslaat op het systeem van de gebruiker dan moet je de gebruiker vertellen dat je dit doet, waarom je dit doet en wat je precies opslaat. En de gebruiker moet daar dus toestemming voor geven en kan die toestemming ook ieder moment weer intrekken.
Er zijn technieken die het mogelijk maken om zonder dergelijke methodes te werken maar die maken het moeilijk om een gebruiker bij meerdere sessies keer op keer te herkennen. Dat kan overigens weer wel indien je de bezoeker laat inloggen en daarbij de optie aanbiedt om lokaal zijn gebruikersnaam (en eventueel wachtwoord) op te slaan zodat deze de volgende keer automatisch ingevuld wordt. (De site mijn.ing.nl doet zoiets met alleen gebruikersnaam.) Daarmee geef je dus ook toestemming voor een cookie en die kun je ook uitlezen als de gebruiker uitgelogd is!
Alle technieken zijn dus gewoon toegestaan, alleen zul je in de meeste gevallen de gebruiker (eenmalig) om toestemming moeten vragen. (En je mag er gevolgen aan verbinden als de gebruiker dit weigert door b.v. de site voor de gebruiker te blokkeren tot ze de toestemming alsnog geven!)
Pingback: De cookiewetgeving: wat is het en wat zijn de gevolgen
Pingback: Hosters hebben niks te vrezen van de cookiewet | ISPam.nl
Pingback: Internetrecht door Arnoud Engelfriet
@ arnoud
Wat is nou de echte toevoeging van deze wetgeving. Voor de implementatie van de e-Privacy wetgeving in de telecommunicatiewet was er al het regime van de Wbp, die nu ook nog geldt voor persoonlijke data. Hiervoor is volgens art. 8 ondubbelzinnige toestemming nodig. Volgens Working Party 29 is het plaatsen van cookies t.b.v. behavioural targeting een vorm van persoonlijke data. Dit ondanks dat het niet terug te leiden is tot een individu. Maar het is volgens de WP29 terug te leiden tot een groep (bv een groep die zoeken naar bepaald marktsegment) of terug te leiden naar een unieke computer (waar toch meerdere mensen op kunnen zitten). Er was dan toch al (ondubbelzinnige) toestemming nodig voor het plaatsen van zeer veel cookies (ook al wordt niet bijna niet gedaan in de praktijk). De cookies waarvoor het niet hoeft veroorzaken geen privacy schending of komen daar niet in de buurt. De reden voor het amandement in de e-privacy directive is toch meer privacy?? De Wbp was er toch al?
Hallo Arnoud,
Bedankt voor de samenvatting!
Voor wat betreft je laatste vraag: onder Javascript kan worden verstaan alle API’s die in deze taal door de browser ter beschikking gesteld worden voor het opslaan van data in de randapparatuur. Denk hierbij vooral aan zgn. LocalStorage. Dat is geen cookie, geen Flash, geen Java, maar wel een database in je browser, toegankelijk vanuit Javascript. Kan niet gebruikt worden voor cross-site tracking overigens, omdat de scope van de data die je opslaat die van het domein is (dus sites kunnen allen de door henzelf opgeslagen data raadplegen bij een volgend bezoek).
IANAL maar wel een web developer, en dat is mijn interpretatie.
Het grootste probleem in de huidige oplossing zit hem erin dat het geen oplossing is omdat gebruikers nog steeds geen notie hebben wat ze toestaan en of ze zonder kunnen als ze het niet toestaan.
Mijn inziens zou de wet moeten regelen dat het weigeren van cookies of scripts de functionaliteit van de website vanuit het oogpunt van de gebruiker in principe niet mag aantasten en dat anders voorafgaand aan ELK gebruik van de website moet worden gevraagd of men de cookies of scripts wil weigeren of niet, en dat daarnaast moet worden uitgelegd wat daar dan de consequenties van zijn in het kader van de functionaliteit en vastgelegde of verzamelde type informatie.
Dit heeft te maken met het feit dat een computer vaak door verschillende individuen wordt gebruikt en het niet zo mag zijn dat het toestaan van cookies of scripts door de ene gebruiker op het ene moment ertoe leidt dat op later moment informatie wordt vergadert van een andere gebruiker. Verder denk ik dat het vooral van belang is wettelijk vast te leggen welk type informatie wel en welke informatie vooral niet door dergelijke cookies of scripts mag worden vastgelegd of worden verzameld.
Volgens mij vult de wet dit nu niet goed in. Of zie ik dat verkeerd?