Detectie van adblockers volgens Europese Commissie illegaal

| AE 8606 | Privacy | 64 reacties

Volgens Europese wetgeving is het illegaal dat websites zonder toestemming scripts draaien op apparaten van gebruikers om te achterhalen of bezoekers gebruik maken van adblockers, las ik bij Tweakers. De Europese Commissie had dat gesteld in een brief aan privacyactivist Alexander Hanff. Je mag immers geen informatie opslaan op mensen hun computers zonder toestemming, en een adblockdetectiescript is ‘informatie’ en mag er dus niet zijn. Hmm.

We noemen het altijd de cookiewet, maar de wet is breder: ieder opslaan en uitlezen van informatie van randapparatuur van eindgebruikers is alleen toegestaan met hun toestemming, nadat je ze uitgebreid hebt geïnformeerd over wat je gaat doen en waarom. Vandaar dus de cookiepopups, maar ook bij het installeren of updaten van software moet er een toestemmingsvraag komen met uitleg wat er allemaal gaat gebeuren.

De EC neemt nu het standpunt in dat ook een script op een webpagina hieronder valt. Ergens logisch, want ook dat is informatie en die wordt (in de browsercache) op de randapparatuur van bezoekers van die webpagina opgeslagen. Maar als je díe harde lijn neemt, dan moet elke webpagina voor elke pixel toestemming vragen, en dat kan toch niet waar zijn?

Nou ja, niet helemaal want de wet kent een uitzondering. Als het noodzakelijk is voor een goede levering van de dienst, dan mag zonder uitleg en zonder toestemming die informatie worden gezet. De CSS-stylesheets in een gevraagde webpagina behoeven dus geen toestemming, die zijn gewoon nodig om die pagina in de gewenste vorm te leveren. Bij gewone afbeeldingen zie ik dat ook nog wel, maar je kunt vraagtekens stellen bij de advertenties in een webpagina. Zijn die technisch gezien ‘nodig’ net zoals de CSS bestanden nodig zijn?

Bij invoering van de cookiewet was altijd het argument, advertenties zijn nodig anders is de dienst niet meer te financieren. Maar dat telt niet onder de wet, het gaat om functioneel/technisch nodig en niet op de lange termijn eigenlijk best wel belangrijk. Dus eigenlijk is het al discutabel of je zonder toestemming überhaupt advertentiebanners in een webpagina mag stoppen. We doen maar alsof dat mag, anders worden we écht gek van de toestemmingspopups, maar als de discussie daar zit dan zal een adblockerscript al helemaal een probleem zijn om te rechtvaardigen als technisch noodzakelijk.

Een escape zou nog kunnen zijn dat een adblockdetectie ook op de server kan misschien. Je kijkt dan simpelweg of de advertentiebanner wordt opgevraagd. Maar dat is natuurlijk simpel te omzeilen; als adblocker haal je dan de afbeeldingen op en die gooi je vervolgens weg.

Wel hebben we in Nederland natuurlijk nog een uitzondering op de cookiewet: informatie die “geen of slechts geringe” inbreuk op de privacy maakt en bedoeld is om de effectiviteit van een dienst te meten, mag zonder toestemming worden opgeslagen. Je zou volgens mij een adblockerscript daar prima onder kunnen rekenen. Dus dan mag in Nederland een adblockdetectiescript wél. (En inderdaad, die uitzondering is tegen de Europese regels.)

Update (2 juni) in antwoord op Kamervragen meldt minister Kamp (DGETM-TM / 16075483) dat de ACM de uitzondering ook van toepassing acht, omdat het slechts gaat om detectie van een blokkade en er geen privacygegevens worden uitgelezen.

Arnoud

Deel dit artikel

  1. Een escape zou nog kunnen zijn dat een adblockdetectie ook op de server kan misschien. Je kijkt dan simpelweg of de advertentiebanner wordt opgevraagd.
    Uuuh… weet je zeker dat deze escape werkt? Of je een adblocker gebruikt is informatie die je niet zonder toestemming mag uitlezen, en het lijkt me nogal irrelevant of je dat dan met een javascriptje op de computer doet of server-side.

  2. De meeste adblockdetecties werken niet door een adblocker te detecteren, maar door te controleren of z’n ads of objecten die lijken op ads zoals div#ads getoond worden. Er wordt geen lijst van beschikbare plugins doorgelopen, en er wordt meestal niets op de computer opgeslagen. Valt dat wel binnen de cookiewet?

  3. Een opvallend en toch wel begrijpelijk standpunt van de EC. Ik vind het prima en gebruik een adblocker in de breedste zin. Zo krijg ik ook die vervelende duimpjes van Facebook niet meer in beeld en hou ik dat onderwaterspioneren van o.m. skimresources tegen. Reclamemakers moeten blij met me zijn. Internetreclames werkten averrechts op me. Ze waren zo irritant dat ik het spul waar de reclame voor was meed om zo niet indirect mee te betalen aan die irritante reclames. Ik vind hoe dan ook dat de commercie meer stukmaakt dan me lief is. Internetreclames zorgen er in hoofdzaak voor dat de middenstand in de buurt het loodje legt en we uitgestorven steden krijgen waar we alleen nog maar slapen. Maar ik vind de grote reclameborden bij drukke kruispunten net zo onverantwoordelijk als het om verkeersveiligheid en onnodige afleiding gaat. De commerciele belangen in het voetbal maken dat spelletje ook niet echt beter.

    En als iedereen evenveel reclame maakt, dan werkt reclame ook niet meer. Het is dus klanten wegkapen bij een ander en die werkzaameden mag je als klant later in het product betalen.

  4. @Arnoud: in hoeverre is er sprake van “uitlezen”, als de (client side) verzamelde informatie niet wordt teruggezonden naar de server? Want je kan natuurlijk prima die detectie (en het tonen van een of andere waarschuwing) volledig client side uitvoeren. Is er dan nog wel sprake van uitlezen?

    Sowieso leest het gemiddelde adblock detectie script geen “informatie opgeslagen op randapparatuur van de gebruiker” uit. Het bestudeert enkel het gedrag van de browser bij het laden van de pagina (worden bepaalde elementen wel geladen en hoe snel?). Het is niet dat zo’n script in het systeem van de gebruiker kan kijken om te zien of daar een adblocker plugin geïnstalleerd en actief is.

    In een hele strikte interpretatie van de wet kan je dan inderdaad nog stellen dat het opslaan van het detectiescript zelf niet is toegestaan zonder toestemming. Persoonlijk vind ik dat nogal vergezocht en vind ik de wet dusdanig onhandig geformuleerd dat het gewoon uitnodigt er allerlei zaken onder te scharen zijn die weinig meer te maken hebben met het beschermen van de persoonlijke levenssfeer van de gebruiker. Waardoor websites genoodzaakt zijn allerlei kunst en vliegwerk toe te passen, maar de daadwerkelijke boosdoeners (de grote advertentieboeren) buiten schot blijven en geen druk voelen om een privacyvriendelijkere manier van werken te zoeken.

    Want ook hier weer: voeg aan je cookiewaarschuwing een regeltje toe om toestemming te geven voor adblockdetectie en als website voldoe je aan de wet en alles gaat gewoon verder zoals het was.

      • Ik vraag me af of je mag stellen dat je het script opslaat. In tegenstelling tot cookies, die in local storage terecht komen wordt de javascript in het geheugen geladen en uitgevoerd. Er wordt niets opgeslagen op je PC en het script wordt alleen uitgevoerd om handelingen op de DOM uit te voeren van de website waar het script in staat. Zo’n script detecteert geen ad-blockers en kijkt niet op jouw computer, het verifieert ‘simpel’ de DOM of een verwacht element – de reclame – aanwezig is.

        Op slaan in de cache is geen handeling van de website, maar van jouw eigen browser! Of en hoe lang scripts in de cache staan hangt van de cache strategie van de browser, de gereserveerde ruimte en hoeveel je browst af, geen van ale zaken waar de website eigenaar invloed op heeft. Het lijkt me dan ook sterk dat deze aangesproken kan worden op het cachen van dit script aangezien dat geen handeling is waar hij bij betrokken is.

        • Hoezo wordt er niets opgeslagen? Het script wordt toch opgeslagen in de buffer/cache bij het downloaden? Het is niet zo of het van de ethernetkaart naar het werkgeheugen gaat lijkt me.

          Verder is cachen een handeling die in opdracht van de site gebeurt. Laat ik het zo zeggen: elk argument dat ook gebruikt kan worden voor een cookie, tracking pixel of stukje spyware kan per definitie niet geldig zijn. Een afbeelding wordt ook gecachet afhankelijk van browserinstellingen etc.

          • Wat noem jij opslaan? De gegevens gaan wel degelijk van de ethernetkaart naar het werkgeheugen. Hetzij via de CPU, danwel DMV DMA direct het geheugen in. Als het op disk terechtkomt is dit het gevolg van de software die de gebruiker geinstalleerd heeft, niet de server.

            Er is geen enkele reden voor de client om dit meer permanent op te slaan. Het is in order geval zeker niet nodig voor de working van een browser. Dat browser toch een cache aanleggen ( zonder dat de server daar overigens opdracht toe geeft) is om toekomstige bezoeken te versnellen. Servers moeten just de browsers explicit vertrekken iets niet te cachen als het veranderd zonder dat de URL wijzigt, Anders pakt de browser de wijzigingen niet op. De code die besluit wat er wordt opgeslagen is onderdeel van de browser, niet de website. Door de gebruiker gekozen, niet door de server.

            Een cookie werkt volledig anders. Een stukje JavaScript slaat deze explicit op in de local storage, hier is het dus wel degelijk de code die de server stuurt die het opslaan bewerkstelligt.

            Een magic pixel is juist weer niet opgeslagen bij de gebruiker, het idee is dat je de gebruiker iets op laat slaan waarin code staat die een uniek 1 pixel bestand laat downloaden. Die code is een unieke identification die op de PC is opgeslagen en dus verboden bij cookiewet.

            Spyware is toch weer heel wat Anders. Spyware slaat geen uniek identificeerbare info op, maar een standaardprogramma dat slinks informatie steelt. Dit lijkt mij meer een gevalletje computervrede breuk.

        • wordt alleen uitgevoerd om handelingen op de DOM uit te voeren van de website waar het script in staat

          De DOM wordt maar voor een beperkt deel bepaald door informatie die van de server van de website afkomstig is. De DOM wordt mede bepaald door eigenschappen van de webbrowser (kan die bepaalde elementen uit alle HTML aan?), of door instelling van de webbrowser (script toegestaan?). Daarnaast worden — zonder addblocker — grote stukken van de DOM ingevuld door zaken die afkomstig zijn van servers van de aangeroepen advertentieboeren. Hoe die advertentieboeren de ruimte die ze krijgen, invullen weet de oorspronkelijke website niet. Door delen van de DOM die niet rechtstreeks van de oorspronkelijke website server afkomstig zijn te onderzoeken naar structuur en inhoud, verschaft de website zich data die het zonder tussenkomst van deze scripts niet bezat en niet kon bezitten.

          • Dus nu doen we moeilijk over een website die toegang tot zichzelf heeft? Want laten we duidelijk wezen, de data blijft binnen de browser, het script blijft binnen de browser. De server weet van dit alles niets en heeft geen toegang tot de data. (Als het script wel data terugstuurt, dan kan het inderdaad een probleem zijn)

            Het is geen probleem dat scripts toegang hebben tot de dom om te zien of browsers bepaalde functionaliteit hebben danwel toestaan, dat is noodzakelijk voor functioneren website en dus gerechtvaardigd. En wiensdata is het dan, van de gebruiker of van de advertentie boeren?

            Maar mijn grootste bezwaar is nog altijd dat een maatregel bedoeld voor privacybescherming misbruikt wordt voor iets dat helemaal geen privacy issue is.

              • Nee, nu maak je de vergissing dat de anti-adblocker iets terugstuurt richting de server, maar dat is totaal niet nodig! De adverteerder hoeft niet te weten dat jij een adblocker hebt en de site eigenaar hoeft dat ook niet te weten. Een goed anti-adblocker script detecteert alleen of je een adblocker gebruikt en zorgt ervoor dat de pagina die je wilt zien dus niet verschijnt indien je een adblocker hebt. Dat is informatie binnen je browser die ook verder binnen je browser blijft. Die informatie wordt niet doorgestuurd.

                  • Het is niet logisch om ook maar iets aan te nemen, als je het doodsimpel kan controleren. Open de developer tools in Chrome en je weet of het gebeurt. Ik ben het nog niet tegen gekomen. En voor zover ik weet veroordelen we mensen of bedrijven nog niet voor iets wat ze zouden kunnen doen. Minority report is vooralsnog fictie.

                  • Zoals Elroy al aangeeft is dat eenvoudig te controleren door de scripts op die sites even te bestuderen. Maar sowieso mogen ze die informatie niet doorsturen naar de server vanwege de cookiewet. De vraag is verder in hoeverre dergelijke informatie eigenlijk waarde heeft voor adverteerders. Tja, een adverteerder die adblockers verkoopt heeft er misschien iets aan maar verder?

                    Het gaat altijd om welk motief een bedrijf zal hebben om te weten achter welke IP adressen er een adblocker verschuilt. Goed, je kunt die adressen dan blacklisten maar dan komen die bezoekers ook niet meer terug. Vervelender is het indien die gebruikers later besluiten om de adblocker gewoon uit te zetten voor jouw site, want de site blokkeert hen dan nog steeds. En dan hebben sommige bezoekers ook nog eens een dynamisch IP adres zodat dergelijke registratie niet eens 100% waterdicht is. Het kost ze alleen extra ruimte op hun systemen die ze moeten doorzoeken, filteren en statistieken berekenen of zo. Vrijwel nuttelose informatie, eigenlijk.

                    En dat terwijl het script gewoon even snel een controle kan doen en vervolgens kan bepalen of de content wel of niet weergegeven zal worden. Dan hoeft er niets naar de server want zoals ik al zei, de informatie heeft weinig nut. Om te weten wie advertenties blokkeren? Waarom zou dat ook maar enigszins interessant zijn als je deze bevindingen niet eens kunt koppelen aan andere gegevens en daarnaast dan ook nog eens de cookiewet overtreedt?

  5. Wat de Europese Commissie dus in feite wil is dat bij het laden van de website een pop-up komt waarin de gebruiker toestemming gevraagd wordt voor het gebruiken van een adblock detector. Zitten we daar dan op te wachten?

    Ik ben trouwens zelf pas een adblocker gaan gebruiken toen ik (zoals vele anderen) via een advertentie op nu.nl een virus binnen kreeg. Het veiligheidsaspect moet niet vergeten worden.

    • En het snelheidsaspect moet ook niet vergeten worden. Het is vaak gebeurd bij mij dat een pagina traag laadde omdat de advertenties traag waren (ik neem aan omdat de ‘advertentieserver’ traag was). Telegraaf.nl bijvoorbeeld. Met een adblocker is dat veel beter.

      Ik heb op zich niets tegen advertentie’s, ik begrijp dat de sites ook moeten overleven. Maar zorg dan dat ze niet voor storingen zorgen.

  6. Er zijn verschillende manieren om dit aan te pakken;

    – a. Je kunt een melding tonen om alsjeblieft te whitelisten, waar je met JavaScript vervolgens de ads overheen zet.

    – b. Je kunt ads laden, dan detecteren dat ze niet geladen worden, en dan een melding tonen.

    – c. Of bovenstaande met b: redirecten naar een andere banners-blocked pagina.

    – d. Of variant op c: je zet een meta refresh naar een banners-blocked pagina, welke je uitschakelt wanneer je ziet dat ads (etc.) geladen zijn. (Ik ben bang dat ik hiermee mensen op erg irritante ideeën breng, maar ik kwam hem erg recent tegen doordat ik NoScript gebruik.)

     

    a. mag gewoon, want je meet niets. b. en d. ‘mogen’ dus niet. Maar bij d zou je de detectie onder de noemer ‘nodig voor werking van de pagina’ kunnen gooien. Dat tenminste als je naar een klein stukje functionaliteit mag kijken. In het geheel is d. natuurlijk niet nodig.

    • Het gaat niet alleen om ‘meten’ maar ook om het ‘opslaan van informatie zonder toestemming op apparatuur van de gebruiker’. Bij methode a sla je de tekst van de melding op in de browsercache. Ik zie niet waarom een adblockdetectiescript niet zou mogen, en die tekst wel. Het maakt m.i. niet uit of de ‘informatie waarvoor geen toestemming is verkregen’ in een aparte file staat (wat bij een adblockdetectiescript ook niet het geval hoeft te zijn).

  7. De CSS-stylesheets in een gevraagde webpagina behoeven dus geen toestemming, die zijn gewoon nodig om die pagina in de gewenste vorm te leveren. Bij gewone afbeeldingen zie ik dat ook nog wel, maar je kunt vraagtekens stellen bij de advertenties in een webpagina. Zijn die technisch gezien ‘nodig’ net zoals de CSS bestanden nodig zijn? .

    Nee, niks geen vraagtekens volgens mij. Die reclames zijn namelijk gewoon een integraal onderdeel van de dienst die de website aan jou probeert te leveren. Misschine niet een onderdeel wat iedereen graag erin wil hebben maar reclame is wel een onderdeel van de content die de site probeert te leveren. Je gaat toch ook niet bij je dagelijkse krant die in je brievenbus waarop een “Nee” sticker zit bezwaar maken tegen de reclames die in de krant staan.

    De reclames zijn onderdeel van wat de website aan jou probeert te leveren en dus kan de website een script als technisch hulpmiddel zien om de correcte levering van die reclames binnen de website te verzorgen.

    • Op die manier kun je tracking cookies ook recht praten. Tracking cookies horen bij gepersonaliseerde content, wat een integraal onderdeel is van de dienst die de website aan jou probeert te leveren. Je vergelijking met de dagelijkse krant gaat mank, omdat die geen gegevens opslaat op jouw pc. De EC heeft gemeend dat een pc binnen de privésfeer valt, en dat daarom in beginsel toestemming nodig is voordat je iets op iemands pc mag opslaan. De enige uitzondering is voor de opslag van gegevens “strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user”.

  8. Ik vraag me af of het probleem wel zit in het opslaan van het script. De directive heeft het immers over ‘storing information OR gaining of access to information already stored in the terminal equipment’. De aanwezigheid van adblock software is informatie die reeds aanwezig is op (in?) de terminal. Serverside detecteren verandert daar niks aan.

  9. Even een ander scenario: de anti-adblocker is een stukje Javascript dat de overige content gaat downloaden als er geen adblocker is geinstalleerd. Echter, als er wel een adblocker is, dan komt er een melding hierover en krijgt de bezoeker de content niet te zien. Er worden dus geen gegevens verzameld die naar de server terug worden gestuurd. De website ontvangt dus geen informatie of de bezoeker wel of geen adblocker gebruikt. Valt een dergerlijk script ook onder de cookiewet? 🙂

  10. edit: dit is een reactie op Wim ten Brink 26 april 2016 @ 20:59

    Ik moest gelijk aan een citaat denken:

    als er iets is waar rechters een hekel aan hebben, dan is het wel aan bijdehante figuren die niet gewoon doen wat in de wet staat en daar met een zeer spitsvondig argument grijnzend omheen gaan draaien
    De cookiewet gaat niet alleen om ‘informatie uitlezen’ maar ook om het ‘opslaan van informatie zonder toestemming op apparatuur van de gebruiker’. De EC sloot bij de beoordeling van adblockdetectoren uitsluitend aan bij de tweede categorie: een website hoeft helemaal geen adblockscript op de pc van een gebruiker op te slaan om haar pagina te kunnen tonen, dus mag dat ook niet. Hetzelfde geldt voor jouw ‘laad-de-content-pas-in-als-er-geen-adblock-is’ script. Rot op met dat technisch en functioneel overbodige script en serveer gewoon de content 🙂

    • Er zijn anders best veel webpagina’s die interactief content ophalen om aan de client-kant een complete pagina op te bouwen. Dit is waarom we Ajax, JQuery en web services hebben ontwikkeld! Het is tegenwoordig vrij normaal om een vrijwel lege pagina aan te bieden in combinatie met Javascript waarbij het script vervolgens de overige resources en teksten ophaalt.

      Een voorbeeld van een dergelijke techniek is Knockout.js waarmee je interactieve, single-page sites mee kunt maken. Een erg mooie techniek waarbij het script alleen even bepaalt in hoeverre de browser geschikt is voor het weergeven van content. En daar de advertenties onderdeel zijn van deze content kan het script dus weigeren om content weer te geven indien er een adblocker aanwezig is.

      En Javascript helemaal blokkeren betekent dat je meteen een blanco pagina krijgt…

       

      Overigens wordt er in dit geval in principe niets opgeslagen. Nou ja, het script kan in de browser-cache staan, maar dat is wat de browser zelf doet. Het script slaat verder niets op.

      • Ik ben het met je eens dat het soms nuttig is om bepaalde delen van een pagina met Javascript in te laden. Amazon.com is een voorbeeld van een website die dat heel goed doet om de laadtijd zo kort mogelijk te houden. Als je om zulke redenen zo’n script implementeert (en niet alleen om adblockgebruikers te weren), is het if-statement met een adblock-detectie alsnog overbodig.

        Over het opslaan in de cache: dat is op Twitter aan de orde gekomen, waarbij Alexander Hanff aangeeft met IT experts van de Europese Commissie te hebben gesproken.

        • Ik heb vraag en antwoord en zijn tweets geskimmed, maar meneer Hanff doet alsof het opslaan van dat script een noodzaak is die veroorzaakt wordt door de server. En daar is ook het antwoord op gebaseerd. Terwijl het opslaan van het script een keuze is van de browser(ontwikkelaar).

          Daarnaast doet hij alsof het script data van de PC leest en doorspeelt, dat is ook niet zo. Het script heeft alleen toegang tot de pagina waar het onderdeel van is en zaken op het internet. Het script doet niet meer dan wat handelingen op de DOM van de webpagina uitvoeren en afhankelijk van wat hij ziet laadt hij de inhoud 1: de pagina meet informatie of inhoud 2: een een blanco pagina met het bericht de adblocker uit te zetten. Dit is overigens de functionaliteit van zo’n beetje elk script op een moderne website, danwel automatisch bij laden pagina, danwel door een user interactie: check de DOM, op basis van staat van de DOM voeg elementen toe of verwijder elementen, voila pagina is aangepast. Alles volledig in het werkgeheugen en binnen de data van de website, dus niet met enige data (persoonsgegeven of niet) van de client.

          Meneer Hanff is in deze de “bijdehante figuur” die niet doet wat er staat, maar wil doen voorkomen dat het wel zo is.

          • Maar het opslaan van een script is dezelfde keuze als het opslaan van een cookie. Beiden worden uitgevoerd door de browser, die is immers geprogrammeerd om iets te doen met <SCRIPT SRC> respectievelijk de HTTP Cookie: header. Als dát het argument is, dan is de cookiewet krachteloos want dan slaat een server nooit iets op. Dat kan niet waar zijn, wetten zijn per definitie niet krachteloos. Dus moet het argument volgens mij zijn dat de server zorgt voor het opslaan omdat hij willens en wetens <SCRIPT SRC> in de webpagina meestuurt respectievelijk een cookie: header zet. Daarmee is dan ieder stukje informatie dat aan een webpagina hangt ‘opslaan’ in de zin van de cookiewet, en moet je dus voor elk stukje rechtvaardigen dat dat mág onder de cookiewet.

            • Het verschil is dat http cookies een techniek is om webserver de mogelijkheid te geven om iets op te slaan op de client. Als je een cookie stuurt geef je de client dus de opdracht “Sla dit op!” Je kan diezelfde informatie ook opslaan via javascript cookies, je javascript slaat dan de informatie op in de local storage om deze het einde van een sessie te laten overleven. Ook dit is natuurlijk een opdracht vanaf de server om iets op de client op te slaan en valt duidelijk onder de cookie wet.

              Javascript moet dit wel expliciet opslaan, omdat er geen enkele garantie is dat een script zelf gecached wordt, individueel aangepaste scripts sturen is geen methode om iets op te slaan. Immers de browser die wordt gebruikt kan geen caching toepassen, of zelfs geen javascript ondersteunen (http://links.twibright.com/features.php). Of de cache kan klein zijn omdat het op een resource restricted device loopt, dan kan het zijn dat de cache geflushed is voor het volgende bezoek. Het lijkt mij vrij duidelijk, of de JS wordt opgeslagen is een client keuze en daarmee de verantwoordelijkheid van de gebruiker die voor die client heeft gekozen. Als je niet wil dat alles wordt opgeslagen kan je caching uitzetten: https://support.mozilla.org/en-US/questions/905902 Reuze handige optie voor webdevelopers en mensen met paranoia 😉 (had ik al gezegd dat dit opslaan een keuze van de client was)

              Het enige wat dan overblijft van het argument is dat ook toegang tot data op de client niet mag zonder toestemming. Alleen heeft het script wel toegang tot de data van de client? De DOM die het script inspecteerd is namelijk de webpage die naar de client is gestuurd en waar het onderdeel van is. Als je de webpage als een geheel bekijkt dan kijkt de pagina naar zichzelf en kijkt of hij ziet wat hij verwacht. Zo niet kijken dit soort scripts echt niet verder naar wat er dan wel staat, het is anders dus gemanipuleert dus zal wel advertentieblocker zijn.

              Je kan ook je script gewoon de hele pagina laten opbouwen. In het extreme: Standaard is de pagina dan een leeg frame met een script, dat script voegt de rest toe aan de DOM, hierbij wordt ieder onderdeel gecontroleerd of het goed in de DOM is terechtgekomen voor het volgende wordt toegevoegd. Als een onderdeel niet aanwezig is probeer je het opnieuw tot het wel gelukt is. Gebruik je een adblocker komt het script in een endless loop. En nog een mogelijk gemene loop ook, als je adblocker wel de download laat gebeuren maar niet de toevoeging in de DOM, dan schiet je dataverbruik de lucht in omdat je script herhaaldelijk de ad zal downloaden.

            • Ah, maar een cookie is bedoeld om gegevens op te slaan gedurende een sessie of zelfs langer. Een script slaat geen gegevens op maar voert gewoon een bepaalde actie keer op keer opnieuw uit. Een script houdt geen data vast maar een cookie wel. De gegevens in een cookie worden daarnaast naar de server verstuurd die daarop kan reageren. Een script draait alleen binnen de browser en bepaalt alleen wat er in de browser wordt weergegeven zonder feedback richting de server.

                • Arnoud, wat vat jij onder opslaan? Ik denk daarbij aan harddisk, niet aan in het werkgeheugen laden om uit te voeren.

                  Als je de instelingen aanpast in firefox volgens de link die ik hierboven heb geplaatst, dan wordt het script niet opgeslagen. Dat zijn browser instelingen, vandaar mijn conclusie dat het wel of niet opslaan van die scripts een handeling van de client is, niet van de server. De server weet zelfs helemaal niet of de client de scripts op zal slaan of niet.

                  De enig invloed die je vanaf server kant kan doen is aangeven dat het niet gecacht moet worden. Dat doe je bijvoorbeeld met een script wat veel wijzigt, maar waarvan de URL niet wijzigt. Als die gecachet wordt dan zal de wijziging niet opgepakt worden bij een volgend bezoek. Het is dus verstandig als de client zoiets serieus neemt en niet cachet, maar zelfs dan kan je een eigenwijze client maken die toch cachet.

                    • Cookies Server: Hier is de gevraagde data, er zit een cookie bij, svp opslaan voor later gebruik Client: slaat cookie op

                      Caching Server: Client hier is de gevraagde data Client: Laat ik die data eens opslaan voor het geval ik die later nog eens nodig heb.

                      Fundamenteel verschillend op het belangrijkste punt voor deze wetgeving: De partij die het opslaan initieert!

                      Bij een vervolg bezoek ook fundamenteel anders: Cookies De server stuurt code die vraagt om een eventueel aanwezig cookie om die uit te lezen.

                      Caching De client krijgt de vraag om een bestand kijkt in de cache en als die daar staat wordt die niet eens meer aan de server gevraagd. Als de hele pagina in de cache staat is het theoretisch zelfs niet nodig om uberhaupt nog contact met de server te hebben. De ultieme privacy 🙂

                      • Snap je punt, maar die data wordt toch altijd ergens opgeslagen? Hoe kan een browser een webpagina renderen als de data niet ergens staat, al is het maar gedurende deze browsersessie? Het werkgeheugen van de browser is óók opslaan volgens mij.

                        Verder dacht ik dat je tegenwoordig vanuit mag gaan dat een browser dingen cachet tenzij je headers als no-cache meestuurt, maar daar kan ik zo geen bron van vinden. Als cachen de default in de praktijk is, dan vind ik dat je mag zeggen dat de server het opslaan in de cache initieert.

                        • Daarom vroeg ik wat jouw definitie van opslaan is. In het werkgeheugen moet het immers altijd staan om een pagina te kunnen renderen. En het werkgeheugen kan zelfs bij geheugentekort naar disk geswapt worden. Alleen denk ik bij ‘opslaan’ toch echt aan iets meer permanents.

                          Als het werkgeheugen ook al opslaan is, dan zijn we inderdaad snel klaar. Behalve dan dat ik nog steeds niet ontdekt heb hoe dit uberhaupt een privacy issue is…

                          En cachen is vrijwel default vanwege de performance voordelen voor de gebruiker, maar niet universeel. Er zijn nog steeds browsers die niet cachen en je kan het ook nog steeds uitzetten in firefox en Chrome cachet niet in incognitomodus. Het is dus zeker geen gegeven dat er gecacht wordt. En als het gebruik van incognito modus toeneemt uit zorg om de privacy dan zal de caching zelfs afnemen.

                          • Het onderscheid tussen permanent opslaan op harddisk of in het werkgeheugen lijkt me niet zo relevant: apparaten staan steeds vaker altijd aan. Het lijkt me vooral van belang in hoeverre informatie wordt hergebruikt voor nieuwe pagina’s of bij (semi)automatisch veranderende pagina’s. Maar waar de grenzen nu precies (zouden moeten) liggen is me ook nog niet helemaal duidelijk..

                            • De scripts worden alleen uitgevoerd in de pagina waarmee ze worden gedownload. Behoudens de browser cache is het script weg als je de pagina sluit. Je moet dan dus niet alleen de PC aan laten staan, je moet ook de desbetreffende pagina open laten staan. Met de beste wil van de wereld kan ik dat niet als opslag zien.

                        • Het probleem is dat browsers zelf bepalen of ze dingen opslaan in een cache of niet en dat niet alle browsers de cache-instellingen van de server accepteren. Immers, HTTP is maar een standaard en makers van browsers kunnen zelf bepalen of ze bepaalde zaken wel of niet ondersteunen. Cachen is dus de praktijk maar de standaard om dit te blokkeren wordt niet altijd ondersteund. De server heeft daar dan geen keuze bij. Het is alleen de browser die dit volledig controleert.

                          Dat browsers deze cache-regels gewoon negeren heeft deels te maken met performance. De meeste browsers halen allerlei truken uit om er maar voor te zorgen dat pagina’s zo snel mogelijk worden opgehaald. Cachen is zo’n stap in een verbeterde performance en dus negeren sommige browsers de cache-instellingen zodat ze niet steeds dezelfde content op hoeven te halen. Dit gaat sowieso in 99% van alle sites alsnog goed want de meeste content verandert niet zo snel. En mocht het mis gaan dan krijgt de site de schuld, niet de browser…

                    • Dat is een goede vraag, maar voor mij is de browsercache in ieder geval genoeg.
                      Zou dat niet impliceren dat ELKE site de gebruiker vooraf toestemming moet vragen om getoond te worden volgens de cookiewet? Zelfs een site met alleen een HTML bestand en vijf GIF plaatjes? Omdat dat in de cache komt?

                      Ik zie geen verschil tussen een HTML bestand met en zonder Javascript-code.

                      • Ik werd net wakker en bedacht me ineens dat “normale” cookies natuurlijk wel mogen, dus je mag dingen opslaan zonder toestemming, mits functioneel.

                        Als het opvragen van een HTML pagina (met of zonder script, zonder cookies) echter als opslaan wordt beschouwd, zou dat kunnen betekenen dat je de kans loopt dat iemand gaat roepen dat een gedeelte daarvan niet functioneel is. Om dat risico af te wenden, dien je dan om toestemming te gaan vragen, ook (om zeker te zijn) bij een HTML bestand met vijf plaatjes.

                  • Nee, de cookiewet gaat over consent voor opslaan of uitlezen van informatie. Dit los van de privacy. Ook een silent install van een belangrijke update aan je OS vereist toestemming onder de cookiewet.

                    De privacy speelt pas bij de uitzondering voor analytics: als je de effectiviteit van je dienst wil meten én dat maakt geen inbreuk op de privacy, dan is geen toestemming nodig onder de cookiewet. Maar het is én, dus iets dat privacytechnisch probleemloos is maar niks met analytics te maken heeft, valt niet onder de uitzondering. Je kunt er dan alleen nog mee wegkomen als je het als technisch noodzakelijk kunt rechtvaardigen; daarom mogen .css bestanden zonder toestemming worden meegestuurd.

                    • Maar een anti-anti-adware script is net als analytics toch gewoon nodig om een goedwerkende site te krijgen? De sitemaker heeft immers bepaalt dat de site pas goed is indien de content van advertenties wordt voorzien, zodat hij er immers inkomsten uit verkrijgt. Het heeft verder niets met de privacy te maken. Het script controleert alleen of alle onderdelen van de site goed weergegeven kunnen worden en geeft een foutmelding indien dat niet het geval is.

                      Nu kun je je afvragen of een site ook goed kan werken zonder advertenties maar dat is dus niet het geval. Immers, die advertenties zorgen voor imkomsten die de site betaalbaar maken. Om die reden zijn de advertenties technisch noodzakelijk. Het script maakt geen inbreuk op je privacy, als je het op deze maniet beschouwt.

                      Het script meet in principe de effectiviteit van de site en past de site aan indien deze niet correct weergegeven kan worden. En correct weergeven betekent dus dat ook de advertenties zichtbaar moeten zijn.

                        • Nee, want tracking cookies is data. Een script is code. Die twee zijn totaal verschillend. Via tracking cookies verzamel je gegevens over de bezoeker, net als met andere invasieve privacydingen. De cookiewet is om dit tegen te gaan zonder toestemming van de bezoeker omdat deze verzamelde gegevens door de website voor allerlei doeleinden (mis)gebruikt kunnen worden.

                          Een script stuurt in principe niets terug naar de server maar controleert alleen of de inhoud van de site correct weergegeven kan worden. Dit is dus puur code bedoeld om de pagina correct weer te geven. En zoals gezegd, de advertenties zijn onderdeel van de inhoud en dienen dus ook gewoon weergegeven te worden. Er is met een dergerlijk script dus geen privacyschending omdat er niets wordt teruggemeld richting de server. Er wordt alleen bepaalde content niet opgehaald indien een adblocker aanwezig is.

                          Natuurlijk kan het zo zijn dat er scripts worden gebruikt die wel de privacy schenden door gegevens richting de server terug te sturen. Dan heb je een goed punt. Maar een script dat alleen controleert of alle content, dus inclusief advertenties, weergegeven kunnen worden is een functioneel script en geen privacy-gevaar. Het vervelende voor de gebruiker is alleen dat ze de inhoud niet kunnen zien omdat de adblocker op hun systeem een deel blokkeert en daarom dus alles wordt geblokkeerd.

                          Dus nee, een anti-adblocker bouwt geen profielen op, voert geen tracking uit en bewaart ook geen data, mits correct geschreven.

                          • Wim, jouw laatste zin vat prima samen wat er mis is met de redenatie meneer Hanff.

                            Maar als je kijkt naar de vraag die meneer Hanff gesteld heeft dan is alles meteen duidelijk: Zijn vraag is suggestief dat de server er verantwoordelijk voor is dat het script op de client wordt opgeslagen; of dat mag onder de richtlijn? Ik wil best geloven dat als de server daar verantwoordelijk voor was dat het niet mag volgens de richtlijn, maar dat is dus niet hoe het werkt.

                            Dat is hetzelfde als aan een imam vragen: De paus is moslim, mag hij varkensvlees eten. De imam zal zeggen nee, want dat is onrein. Maar we weten alemaal dat de paus Rooms Katholiek is en geen moslim. Vervolgens groots in het nieuws: Paus zondigt, eet varkensvlees!

                            • Maar meneer Hanff heeft wel gelijk als hij zegt dat de server bepaalt dat Javascript in de cache wordt opgeslagen! Om caching te voorkomen dien je het volgende op te nemen in de HTTP headers die bij het downloaden van het script worden meegegeven:

                              Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: 0

                              Alleen is een script code en geen data. Hanff heeft het over data die door de browser wordt opgeslagen maar dat is incorrect. Er wordt alleen code opgeslagen.

                              Een ander probleem is dat browsers deze caching-restricties ook gewoon kunnen negeren en het Javascript alsnog in de cache terecht komt ook al heeft de webbouwer dat nooit bedoeld. Daar valt verder niets aan te doen en dat wordt gewoon bepaald door de browser, die dergelijke functionaliteit lijkt te hebben. Vandaar ook dat je zoveel dingen in de header moet meegeven om caching bij de meeste browsers uit te schakelen.

                              Daarnaast kan de bezoeker ook gewoon handmatig het script opslaan op de eigen schijf. Dat is totaal niet te blokkeren omdat alles wat je van een site kunt downloaden kun je ook gewoon lokaal opslaan.

                              Waar het dan bij de cookiewet om gaat is in hoeverre de server kan doorgeven aan de client dat bepaalde gegevens opgeslagen moeten worden. Dat gebeurt dan in cookies of andere locale opslagruimtes. En daar moet dus toestemming voor worden gegeven. Maar een script hoeft niets op te slaan. Het wordt alleen uitgevoerd.

        • Het opslaan van JavaScript is een truukje van de browser, die op deze manier de gebruiker sneller van pagina’s kan voorzien omdat niet steeds hetzelfde bestand opnieuw gelezen hoeft te worden. Nu kan dat cachen door browsers vanaf de server wel enigszins geblokkeerd worden maar dat hoort gewoon niet de verantwoording te zijn van een sitebouwer! De bezoeker heeft nu eenmaal de pagina en het script opgehaald en daarmee dus zelf het script in de cache geplaatst. En sowieso heeft dat opslaan in de cache een technische reden: de pagina laadt dan sneller! En technische redenen zijn een goede reden om het toe te laten.

          Maar het is tevens de sitemaker die bepaalt wat de content is, en die heeft bepaald dat advertenties onderdeel zijn van de content. Wie dus de content wil hebben zal dus ook de advertenties ontvangen, of ze het nou leuk vinden of niet. Wie geen advertenties wil zal dan maar een andere site moeten bezoeken. Dus de sitemaker kan extra functionaliteit toevoegen aan het script om de content te blokkeren indien advertenties niet weergegeven kunnen worden. Daar hoeven ze ook totaal niets voor op te slaan op de server of in cookies of wat dan ook maar. Het script merkt op dat een deel van de content wordt geblokkeerd dus wordt de rest van de content niet meer weergegeven. En daarmee is het een technisch/functioneel geheel.

          Nu kun je argumenteren of advertenties eigenlijk wel deel van de content kan zijn. Velen vinden van niet maar veel websites halen een deel van hun inkomsten uit die advertenties. Voor de sitemakers is de advertentie dus onderdeel van de content omdat dit hen financieel voordeel oplevert. Door de advertenties wordt de efficienty van de site verbeterd omdat men hierdoor meer inkomsten binnenkrijgt die gebruikt kunnen worden voor het verbeteren van de website. En zo zou dit script onder de uitzonderingen van de wet kunnen vallen.

          Maar als bezoeker kun je ook gewoon besluiten om dergelijke ad-sites gewoon te boycotten. Dan lees je Dilbert maar niet. Sowieso vreemd dat mensen wel klagen over advertenties op websites maar de advertenties in de Telegraaf en andere kranten en tijdschriften en op televisie gewoon accepteren…

  11. De bovenstaande discussie versterkt mijn indruk dat de cookiewet een enorm gedrocht is, dat je niet op een manier kunt toepassen die zowel redelijk als duidelijk is. Mijn indruk is dat het “cookie-probleem” veel beter op een technische manier dan op een juridische manier opgelost kan worden. Met andere woorden: het gedrag van browsers moet verbeterd worden. Maar hoe?

    Mijn eigen instellingen zijn dat ik alle cookies en cache weg gooi bij het sluiten van de browser. Dat is een redelijk compromis tussen privacy en bruikbaarheid: sessie-cookies blijven bijvoorbeeld gewoon werken. Ik denk wel dat het beter kan: in deze set-up kunnen cookies en cache bijvoorbeeld “lekken” tussen verschillende sessies zolang de browser niet wordt gesloten.

    Ik zou beginnen met het definiëren van een sessie: een sessie bestaat uit pagina’s van het zelfde domein die in een aaneengesloten tijdsperiode open staan. Elementen van een pagina vallen onder de zelfde sessie als de pagina zelf, zelfs als die elementen van een ander domein komen.

    Cookies en cache worden dan opgeslagen binnen de context van een sessie: als de laatste pagina van de sessie wordt gesloten, dan worden bijbehorende cookies en cache automatisch verwijderd. Cookies en cache worden nooit gedeeld met andere sessies, zelfs niet als die andere sessies qua tijdstip overlappen.

    Om performance-redenen kan de gebruiker (met hulp van de browser-maker) een white-list maken van objecten die wel globaal (en persistent) gecached mogen worden. Idealiter gaat het dan om immutable objecten die voor iedere gebruiker het zelfde zijn (en dus geen tracking info bevatten); dit kan gehandhaafd worden door de secure hash van de objecten te controleren.

    Ik weet niet of ik met dit idee bepaalde toepassingen breek. Waarschijnlijk kan het problemen geven als er drie-partijen-interactie is, bijvoorbeeld bij PayPal, iDeal of DigiD. Je moet dan een “sessie” hebben waarin je als gebruiker tussen verschillende domeinen heen en weer beweegt. Dit kan wellicht goed gaan als alle informatie via URLs en POST-data wordt meegestuurd, maar ik weet niet of alle systemen zo zijn ingericht.

    • De cookiewet is ook een gedrocht. Maar het is geintroduceerd om misbruik van prive-gegevens in te dammen. Er zijn nu eenmaal genoeg mensen die niet willen dat adverteerders precies weten waar je naar zoekt.

      Zo ging ik recentelijk op zoek via Google naar een nieuw bureau en kwam daarbij bij verschillende websites. Een dag later ga ik online en kijk op nu.nl en andere nieuwssites en stom toevallig zijn de artikelen vergezeld van advertenties van Otto, met allemaal bureaus. Nou ja, toevallig? Niet dus. Vind ik het erg? Nee, want als software ontwikkelaar ben ik ondertussen wel blind voor advertenties. De Adblocker in mijn hoofd kunnen ze niet herkennen of uitschakelen! 🙂

      Toch kunnen dergelijke op maat gemaakte advertenties voor problemen zorgen. Zo was er b.v. de vader die via advertenties ontdekte dat zijn dochter zwanger was. Even vervelend kan zijn dat je op je werk advertenties voor sekspoppen te zien krijgt omdat je daar toevallig thuis op hebt gegoogled. (Wat dus mogelijk is als je op beide systemen met dezelfde GMail account inlogt!) En zo zijn er wel meer scenarios te bedenken waarbij je eigenlijk niet wilt dat derden prive-gegevens over jou bijhouden.

      Ik doe er zelf niet moeilijk om, simpelweg omdat ik vrijwel geen prive-informatie over mijzelf deel. Ik heb best veel SocialeMedia accounts maar daar is eigenlijk weinig informatie te vinden. Prive-gegevens moet je gewoon niet online zetten, indien je niet wilt dat de gehele wereld er van weet! Maar respect voor mijn privacy vind ik ook belangrijk dus de cookiewet probeert dat te regelen. Ondertussen is het wel een Monster van Frankenstein aan het worden. Mede ook doordat de regelmakers de techniek niet goed begrijpen.

      Zo kun je je afvragen of dit blog zelfs voldoet aan de cookiewet! Want wanneer ik mijn browser opstart en een comment wil plaatsen dan zijn mijn naam, adres en website al standaard ingevuld. Kortom, deze site bewaart mijn prive-gegevens! Foei, Arnoud! 🙂 Niet dat Arnoud daar veel aan kan doen, simpelweg omdat de browser een instelling heeft waarmee je de velden van een webform gewoon kunt opslaan binnen de browser zodat je die niet steeds opnieuw hoeft in te voeren. Maar in hoeverre is de sitemaker daar verantwoordelijk voor en moet een site daar niet een waarschuwing voor geven?

  12. Wat een loser die Alexander Hanff, ik vraag hem op twitter hoe ad-blockers een privacy issue zijn.

    Komt hij met een bizarre analogie van Metro medewerkers die je volgen en als je niet naar de advertenties je krant afpakken. Alsof iemand die je volgt hetzelfde is als een script die alleen checkt of de ads weergegeven worden of niet en op basis daarvan content laat zien.

    Komt hij vervolgens dat het behavioural profiling is, maar daarvoor is het toch echt nodig dat er wordt vastgelegd dat jij ads blokkeert en dat de scripts dan terug moeten rapporteren. Wat ze niet doen en hoe ze niet werken.

    Vervolgens krijg ik het ‘argument’ dat ik gewoon mijn werk moet doen zodat hij het zijne kan doen’ gevolgd door een twitter block. Wat een ongelofelijk stuk stront is dat zeg.

  13. Voor mij is het heel simpel: ik blokkeer advertenties om dat ik geen behoefte aan ze heb (flits! flits! schreeuw! koop nu! …wtf ik probeer een artikel te lezen hier, mag ik ff?) en al helemaal niet aan de malware die ze steeds vaker met zich meebrengen. Als je vervolgens niet wil dat ik je content te zien krijg dan mag dat van mij ook, ik zoek wel een andere site. De meeste newssites (waar dit probleem veel speelt) nemen toch elkaars content klakkeloos over dus voor elke blokkerende site drie andere (dikke doei!). In plaats van je tegen je lezers / gebruikers te keren zou je ook even kunnen nadenken waarom gebruikers die advertenties niet willen.

    We kunnen natuurlijk ook weer allerlei gedrochten als de cookiewet uit de kast halen maar dat lijkt mij een beetje verspilde moeite.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS