Als je een like knop op je site zet, ben je aansprakelijk voor wat Facebook daarmee doet

| AE 11422 | Ondernemingsvrijheid, Privacy | 26 reacties

De beheerder van een website die een plug-in van een derde partij op zijn site opneemt waarmee persoonsgegevens van de gebruiker worden verzameld en doorgezonden, is medeverantwoordelijk voor de gegevensverwerking. Dat meldde Tweakers gisteren. Het Hof van Justitie bepaalde dat namelijk (zaak C-40/17) in een Duitse kwestie over een modewebwinkel die Like-knoppen bij haar producten had staan. De Verbraucherzentrale NRW eV had daartegen bezwaar gemaakt en onder meer aangevoerd dat dit de webwinkel mede-verwerkingsverantwoordelijke maakt, in navolging van dit arrest uit 2018 over fanpagina’s. Het Hof bevestigt dat dit zo is, zodat je nu dus webwinkels kunt aanspreken voor wat Facebook doet met gegevens die ze met die Like-knop binnenhalen. Ben ik even blij dat ik al jaren toestemming voor het tonen van die knoppen vraag.

De standaardversie van zo’n Like knop is vrij agressief namelijk: het is niet alleen een knop die je naar een Facebook-formulier leidt, maar er zit een zooi javascript omheen dat automatisch al gegevens verzamelt en doorstuurt naar Facebook. Ongeacht of je erop klikt, ongeacht of je ergens toestemming voor af – zelfs ongeacht of je ingelogd bent bij Facebook. Waarom alle shops (en online diensten, massaal) dat zo accepteerden was me nooit helemaal duidelijk. Het lijkt mij niet zo fijn dat anderen meekijken over jouw webschouder naar jouw klanten, maar dat zal aan mij liggen.

In 2018 was er een uitspraak van het Hof over een fanpagina op Facebook, waar de beheerder als mede-verwerkingsverantwoordelijke werd aangemerkt. Die besluit immers zo’n pagina op te zetten, waar mensen lid van kunnen worden en zo gegevens achterlaten. Zonder die ingreep waren die persoonsgegevens rondom interesses over die pagina (zeg maar) er niet gekomen, dus daarvoor ligt de verantwoordelijkheid bij deze beheerder. Dat je als beheerder alleen anonieme gegevens krijgt van Facebook, maakt niet uit – in de definitie van gezamenlijk verantwoordelijke staat niet dat je beiden bij alle persoonsgegevens moet kunnen. En het is “mede” verantwoordelijkheid omdat ook Facebook zelfstandig beslist wat er gebeurt op zo’n pagina.

Het Hof trekt die lijn nu door: een webwinkel (of andere online dienst) die zo’n Like-knop invoegt op zijn eigen site (met plugin of handmatig gebouwd, maakt niet uit) die is mede-verantwoordelijk. Die beslist dat Facebook bij die bezoekersgegevens mag, en Facebook doet de rest. Beiden zijn daarvoor in gelijke mate verantwoordelijk – en dus ook aansprakelijk. Voor welk deel precies is nog een interessante vraag; de AVG zegt letterlijk dat je iedere verantwoordelijke voor het gehele schadebedrag kunt aanspreken (artikel 82 lid 4 AVG). Maar deze uitspraak is onder de Wbp (Richtlijn) gedaan en die is daar minder expliciet in.

Desondanks lijkt het me nu de hoogste tijd om die Like-knopjes (en je andere social sharing plugins) eraf te halen, of op zijn minst achter een toestemmingsknop te zetten. En doe dat alsjeblieft niet met een popup. Een simpele hover met uitleg zoals op deze site werkt prima en is AVG compliant. Wie daarna klikt en de plugin activeert, heeft toestemming voor die verwerking gegeven.

Arnoud

Deel dit artikel

  1. Woohoo!

    Hopelijk brengt dit een impuls mee om nog eens uit te kijken met al die tracking. En om toch eens beter na te denken over wat je allemaal wilt doen met eventuele data en hoe je dat uitlegt.

    Als je het niet durft of kan uit leggen, doe het dan misschien niet?

  2. Over de hover functionaliteit; Zoals iemand ook al bij het Tweakers artikel opmerkte; Dat werkt niet op touch devices. Daar zul je alsnog met een soort popup moeten komen om die melding te tonen. Tooltip/kleine popup, toch bijna hetzelfde.

    Ik denk dat je vooral de standaard “alle toestemmingen toegestaan” (ja…) popup bedoelt. Maar toch benoem ik het maar even.

  3. Dat een website-bezoeker toestemming geeft voor activeren van de like-knop en daarmee de verwerking, maakt nog niet dat de risico’s voor de website-exploitant op aansprakelijkheid voor de verwerking door Facebook daarmee verdwenen zijn. Als medeverantwoordelijke moet de website-exploitant immers zijn websitebezoeker vooraf volledig AVG-compliant informeren. En dat is lastig als je zelf niet precies weet wat er gebeurt en de achterliggende daadwerkelijke verwerker geen 100% AVG-compliant informatieve teksten beschikbaar stelt aan website-exploitanten.

    • Daar is nog een nuance in aan te brengen. De informatieplicht rust op degene die verantwoordelijk is. Je ziet in deze zaak dat de verantwoordelijkheid wordt gedeeld tussen de website-exploitant en Facebook. Grof gezegd: de exploitant is verantwoordelijk voor plaatsen van de knop en voor het doorsturen van de informatie naar Facebook, maar is niet verantwoordelijk voor wat Facebook verder met die informatie doet. De informatieplicht van de exploitant reikt dus tot het doorgeven van de informatie aan Facebook – informeren over verder gebruik door Facebook, moet Facebook zelf doen. Maar het onderbouwen waarom je de informatie aan Facebook geeft zal voor veel partijen lastig worden – de meesten hebben die knop nou eenmaal geïmplementeerd op hun website omdat hij bestaat, omdat het makkelijk is en omdat hij er leuk uitziet. Dat is geen onderbouwing waar je vanuit de AVG veel waarde aan kan hechten.

  4. De Duitse uitgever Heise (bekend van o.a. de C’T) had al jaren geleden geregeld dat zijn webpagina’s pas communicatiespartners aan webservers van sociale netwerken zou doorgeven nadat de gebruiker daarvoor via een aparte knop daarvoor toestemming had gegeven, omdat zij bezwaar hadden tegen het door webservers van sociale netwerken laten leegzuigen van de personal computers van hun communicatiespartners.

  5. Dit gaat niet alleen over facebook.

    Ik denk bv. aan de zeer vaak gebruikte google fonts. Als ze nodig zouden zijn kunnen ze perfect lokaal gehost worden, maar weinigen doen dit.

    Zelfde voor google analytics, zeer veel geplaatst, zelden nuttig gebruikt. De meeste zullen meer dan genoeg hebben aan een lokale versie van matomo of eenvoudigere tools.

    Nu alleen wachten of er iemand durft handhaven.

  6. Ik voorspel hele grote problemen met deze regels! En wel voor web developers, die veelal componenten gebruiken die door anderen gebouwd zijn en daarbij soms andere sites moeten aanspreken. Een link in je JavaScript naar b.v. https://html5shim.googlecode.com/svn/trunk/html5.js voor als HTML5 features wilt ondersteunen in oude browsers (Hoi, Arnoud! Check the HTML broncode van je site!) zorgt er natuurlijk voor dat mijn bezoek aan die pagina dus aan GoogleCode wordt doorgegeven. Google, dus. En dus weet Google dat ik de site heb bezocht op een bepaald moment dankzij de referer in de aanroep en dus welke interesses ik heb. Ook als ik geen Google account zou hebben!

    Maar hetzelfde geldt ook voor de vele andere JavaScript frameworks op het web. Bootstrap, Knockout, Angular, ReactJS, VueJS en veel andere scripts zijn vaak gehost op een externe server waar continu de meest recente versie staat met de juiste bug fixes en updates. De Content Delivery Networks dus, zoals de BootstrapCDN. Des te meer sites gebruik maken van deze CDN’s, des te meer privacy we verliezen. Duizenden sites die dezelfde CDN delen zijn dus al snel net zo erg als een Facebook like knop…

    Ja, natuurlijk… Dit zijn technische functies en zonder de CDN’s zouden veel sites geen updates krijgen als er problemen zijn binnen een framework. Maar iedereen vergeet dat die CDN’s geen cookie-popups of andere waarschuwingen zullen geven. We weten niet of ze gegevens verzamelen en zo ja, welke gegevens dat zijn. Zelfs de sitebouwers zullen niet weten wat de CDN eigenlijk doet. Ze weten alleen dat de CDN voor hen de scripts opslaat en niemand denkt er verder over na.

    We kunnen natuurlijk vragen of webbouwers hiervan bewust zijn. Zo is er ook wp-rocket.me die WordPress sites sneller laat laden en daarbij een commentaarregel toevoegt aan de broncode van de pagina. Een simpele plugin voor WordPress en mogelijk in gebruik door duizenden WordPress sites. En dus ook ideaal om gegevens over bezoekers te verzamelen! In ieder geval een IP adres en de interesses van deze personen, gebaseerd op de sites die ze bezoeken.

    En als webbouwer merk ik hoe eenvoudig het is om niet door te hebben dat frameworks linken naar externe sites. Op vacatureblad.nl bijvoorbeeld. Daar wordt Bootstrap gebruikt en dus een koppeling naar de BootstrapCDN. En daarnaast een link naar CloudFlare, een hele grote CDN, voor de JQuery code. Moet ik toch maar eens fixen als ik ooit verder ga met die site…

    En zo zijn er dus heel veel sites die ongemerkt je privacy kunnen schenden. Het probleem is alleen dat dit alles nodig is om de boel veilig te houden en om te zorgen dat de ontwikkelingskosten zo laag mogelijk blijven! Die CDN’s zijn zonder dat je het merkt opeens onderdeel van je site en POEF je bent verantwoordelijk als b.v. CloudFlare opeens gehackt wordt en een hacker exact weet welke sites je hebt bezocht omdat CloudFlare wel enkele miljoenen sites van content voorziet… Zou CloudFlare overigens niet een nog groter probleem kunnen zijn dan Facebook en hun like button? 🙂

      • Ja, dat klopt. Alleen, de meeste sitebouwers zijn daar te onervaren voor. Het wordt ze ook niet aangeleerd. Integendeel, vaak wordt een CDN geadviseerd aan beginnende bouwers en dit leren ze vervolgens niet meer af. Veel frameworks en ontwikkeltools bieden ook de CDN als default optie aan. Natuurlijk kunnen bouwers iets meer werk verrichten en dus de CDN’s vermijden. Maar ja, meer werk = meer kosten.

        • Tien jaar geleden zou ik je gelijk geven maar tegenwoordig is JavaScript best noodzakelijk voor veel websites. Dit omdat websites steeds dynamischer geworden zijn. Daarnaast is JavaScript erg handig om de gebruiker veel sneller ladende pagina’s te geven. Zo wordt b.v. JavaScript gebruikt om een website in meerdere secties te laden zodat je eerst een frame krijgt en binnen ieder frame kan weer een onderdeel geladen worden. Dit allen asynchroon waardoor zelfs grote webpagina’s veel sneller kunnen laden.

          Mooie voorbeelden hiervan zijn sites zoals GMail/GDoc en Outlook/Office maar ook veel andere sites. Je ziet ook regelmatig websites met “endless scrolling” waarbij genoeg content wordt geladen om de pagina te vullen en als je verder door scrollt wordt er automatisch meer content geladen. Dit is b.v. handig bij nieuwssites en zoekengines.

          Nee, JavaScript is tegenwoordig zo normaal geworden dat het Web eigenlijk niet meer zonder kan. Best jammer, maar helaas… Als je JavaScript in je browser helemaal uitschakelt dan zullen de meeste sites het niet of nauwelijks meer doen… Of gewoon erg traag worden…

          Dit blog werkt gelukkig nog wel zonder JavaScript… 🙂
            • Ze zouden dan nog veel sneller laden ook.

              En waar baseer je dat dan op?

              Ja, zonder JavaScript is de totale grootte van de data een stuk minder, maar het gaat niet om hoe snel een pagina laadt, maar om hoe snel de gebruiker het ervaart! Een pagina met veel content heeft nu eenmaal tijd nodig om te laden en vervolgens te renderen voor weergave. Door de pagina in kleine stukjes onder te verdelen krijgt de gebruiker alvast een deel te zien voordat de gehele pagina geladen is. De overige onderdelen worden dan vanuit Javascript geladen op de juiste locatie. De totale laadtijd is misschien trager, maar qua gebruikers-ervaring is het juist sneller. Het in stappen opbouwen van een pagina geeft de gebruiker meer het idee dat de pagina iets doet.

              Dat is ook het grootste probleem met pagina’s zonder Javascript en veel content. Dan ga je naar een pagina en is je browser bezig met laden. De pagina heeft misschien 5 secondes nodig maar na 2 secondes is de gebruiker het al zat, doen ze een refresh en begint het laden opnieuw. En uit frustratie gaat de gebruiker dan weg. Maar als je binnen 1 seconde al iets kunt weergeven, al is het maar een header, dan gaat de gebruiker rustig even wachten.

              Besef ook dat een website meer doet dan statische pagina’s laden. Veel websites moeten data uitlezen uit een database, berekeningen uitvoeren en andere zaken verwerken en hebben vaak te maken met meerdere gebruikers tegelijkertijd. Dat betekent dat er niet alleen tijd verloren gaat aan het downloaden en renderen van de pagina, maar ook aan het op de server samenstellen van die pagina! Iets wat veel handiger is als je de gehele pagina in meerdere requests kunt laten samenstellen in plaats van in 1 keer alles.

              Dat laatste is b.v. iets wat ik op een eigen site gebruik. Met C#/ASP.NET Core heb ik een MVC website waarbij de hoofdpagina gewoon enkele panels heeft waar de content via JavaScript wordt geladen. En als de gebruiker doorklikt dan wordt de inhoud van 1 panel aangepast zonder dat steeds de gehele pagina geladen hoeft te worden. De pagina is door diverse menu-opties redelijk groot en moet veel data beheren, maar door het Javascript reageert alles nog lekker snel. En hoewel ik hetzelfde had kunnen bereiken zonder Javascript, zou het eindresultaat een stuk trager worden omdat ik dan niet 1 panel opnieuw hoef te laden, maar steeds opnieuw alles zou moeten laden. Inclusief afbeeldingen, menu en andere zooi…

  7. Er zal een opkuis gebeuren en een aantal webbouwers zullen hun slechte praktijken moeten afbouwen. In WP is er bv. een redelijk goed update mechanisme en zo zouden de meeste plugins perfect zaken lokaal kunnen hosten. Dus mits verstandige keuze van plugins of andere faciliteiten kan je perfect werken zonder externe code sites.

    Diegene die echt noodzakelijk zijn (maar toon dat maar eens aan 😉 ), zullen wel met een verwerkingsovereenkomst komen of er komt een alternatief aanbod met verwerkingsovereenkomst.

    Het wordt tijd dat er een professionalisering van de webbouwers plaatsvind en dat deze rekening houden met de wetgeving, zoals in andere sectoren. De tijd van excuses en janken is echt wel gedaan.

  8. Aan de andere kant…. de wereld is tegenwoordig zo complex…. je kunt moeilijl verwachten dat iedereen weet wat iedere hardware of softwarecomponent nu eigenlijk doet.

    De halve wereld gebruikt de like knop. Die wordt legaal aangeboden. Moet je er dan, zelfs als websitebouwer, rekening mee houden dat dit niet zou mogen? Is dat wel redelijk?

    Moet de cafebaas er rekening mee houden dat er wel eens lood in het leidingwater zou kunnen zitten, en dus ook in de kopjes koffie?

    • Het zou me niet verbazen als een rechter (of de AP) de lat wat hoger legt voor een professionele websitebouwer, dan voor een amateur-blogger. Met de uitspraak die er nu ligt hoort iedere professional rekening te houden met de AVG-implicaties. (Niet alleen van Facebook, maar ook van advertenties, externe JavaScript bibliotheken, etc.)

      De cafébaas heeft de verantwoordelijkheid om zijn gasten een goed en veilig bakje koffie voor te zetten. Daarbij mag hij in eerste instantie vertrouwen op de garanties van zijn leveranciers. Maar als duidelijk is dat iets niet goed is (groen water uit de kraan), dan moet hij gepaste maatregelen treffen.

    • Ik denk dat je zou versteld staan waar ondernemers en dan zeker in de leefmiddelensector (incl. je cafébaas) aan moeten voldoen. Als die bv. een koffieapparaat op e-bay koopt (of gratis mag gebruiken) en dat geeft een kwaliteitsprobleem, dan heeft je cafébaas echt wel een probleem.

      Of de like knop in Europa legaal wordt aangeboden is een ander verhaal, om nog maar te zwijgen van de legaliteit van de vele javascripts die aangeboden worden. Ter illustratie: In de USA mag je vaak semi-automatische aanvalswapens kopen, maar ik zou niet proberen deze in Nederland te brengen.

      De uitspraak is trouwens op zich niet complex en eigenlijk zeer duidelijk.

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