Tag: avg

About avg

Subscribe Feeds

FBI deelt voortaan uitgelekte wachtwoorden met Have I Been Pwned, mag dat van de AVG?

Geplaatst op in Innovatie, Security, 14 reacties

De FBI gaat uitgelekte wachtwoorden die het tijdens onderzoeken tegen gekomen is, in het vervolg delen met de website Have I Been Pwned. Dat meldde Tweakers onlangs. De wachtwoorden die de FBI met Have I Been Pwned deelt, zullen worden voorzien van een SHA-I en NTLM-hashparen, zodat ook HIBP-eigenaar Troy Hunt de wachtwoorden niet in plain text heeft. Wat de interessante vraag opriep: mag dat van de AVG?

De eerste vraag is dan natuurlijk, verwerkt HIBP dan persoonsgegevens? Want een wachtwoord is weliswaar persoonlijk maar zegt op zich niets over de persoon. Klopt, maar dat is natuurlijk gekoppeld aan een e-mailadres en dat is wél een persoonsgegeven (uitgaande van [email protected] mailadressen, over info@ heb ik het even niet).

Emailadressen worden verwerkt: als je in de dienst je mailadres opgeeft, meldt deze in welke breaches je opgenomen bent. Natuurlijk wordt het wachtwoord niet getoond. Zoals de site het uitlegt:

When email addresses from a data breach are loaded into the site, no corresponding passwords are loaded with them. Separately to the pwned address search feature, the Pwned Passwords service allows you to check if an individual password has previously been seen in a data breach. No password is stored next to any personally identifiable data (such as an email address) and every password is SHA-1 hashed.
Desondanks: ja, HIBT verwerkt dus persoonsgegevens want ze hebben een lijst met mailadressen met daaraan gekoppeld de informatie waar deze slachtoffer van datalekken zijn geworden. En dan krijg je dus de vraag of de AVG van toepassing is, omdat dat Hunt in Australië gevestigd is met zijn site.

Er zitten bergen mailadressen van Europeanen in die gelekte databases, waardoor je kunt gaan kijken naar artikel 3 lid 2 AVG. Want dat regelt situaties waarin de AVG van toepassing is ondanks dat de verwerkingsverantwoordelijke niet in de EU is gevestigd. Eis is dan dat

de verwerking verband houdt met: a) het aanbieden van goederen of diensten aan deze betrokkenen in de Unie, ongeacht of een betaling door de betrokkenen is vereist; of b) het monitoren van hun gedrag, voor zover dit gedrag in de Unie plaatsvindt.
Optie b (monitoren van gedrag) lijkt me vrij evident niet van toepassing, Hunt monitort helemaal niemand. Dus dan is de vraag of Hunt diensten aanbiedt aan deze betrokkenen (want goederen zijn er natuurlijk niet). Is die dienst dan de website, waarin je je mailadres invult en “ja” te horen krijgt, of de achterliggende dienst waarbij hij data verzamelt en koppelt ten behoeve van die website-dienst?

In het eerste geval geldt de AVG zonder twijfel, maar dan gaat het meteen goed met de grondslag en dergelijke: jij vraagt dan om die dienst (“Have I been pwned? :O”) en je krijgt die geleverd (“yes :(“) waarbij de verwerking best wel noodzakelijk is en bovendien voldoet aan dataminimalisatie.

In het tweede geval vraag jij nergens om – Hunt verzamelt immers zonder opdracht ieders gegevens uit allerlei lekkages en zet die in zijn database. Maar dan kun je meteen er achteraan stellen dat Hunt ook geen diensten aan jou levert, hij doet dat voor zijn eigen plezier. Pas wanneer jij gaat zoeken, is sprake van een dienst – en dan zitten we weer bij geval 1. Dus volgens mij gaat deze dienst goed, AVG-technisch.

Arnoud

Kan iemand mij uitleggen waarom ik het gerechtvaardigd belang van anderen aan en uit kan zetten?

Geplaatst op in Ondernemingsvrijheid, 16 reacties

Via Reddit:

Al een tijdje krijgen we in de koekjesschermen een andere keuze. Het gaat niet alleen meer om waar ik toestemming voor geef, maar ook om gerechtvaardigd belang. … Wat ik niet snap, is waarom ik dan in de cookiebanner naast de toestemmingsvraag ook een vraag krijg over legitiem belang. Er staat legitiem belang en dan met een slider ernaast. Alsof ik het legitieme belang van een bedrijf aan en uit kan zetten. Wat doet die slider daar?

Adverteerders zijn een jaartje of zo geleden ineens massaal van de toestemming afgestapt en naar legitiem belang gegaan. Waarom is me nog steeds niet helemaal duidelijk, maar ik vermoed dat men de bui wel zag hangen dat met cookiemuren afgedwongen toestemming niet rechtsgeldig zou zijn.

Legitiem belang of gerechtvaardigd belang is een andere grondslag: je zegt dan eigenlijk, ik mag dit gewoon want mijn belang weegt zwaarder dan uw privacy. Daar horen dan bepaalde privacybeschermende maatregelen bij. En de marketeers hebben dan het voordeel dat in overweging 47 staat dat “verwerking van persoonsgegevens ten behoeve van direct marketing kan worden beschouwd als uitgevoerd met het oog op een gerechtvaardigd belang.” Het jargon spreekt overigens van “legitiem belang” omdat de Engelse tekst ‘legitimate interest’ zegt.

Die slider heb ik ook altijd over zitten denken. Ik had altijd het beeld dat die er was omdat hij er bij toestemming ook stond, en dat daar verder niet over nagedacht is. Want het is niet logisch, dat je iemands belang aan of uit kunt zetten.

Als je even doorbladert in de AVG dan kom je uit bij het recht van bezwaar, artikel 21 AVG:

1. De betrokkene heeft te allen tijde het recht om vanwege met zijn specifieke situatie verband houdende redenen bezwaar te maken tegen de verwerking van hem betreffende persoonsgegevens op basis van artikel 6, lid 1, onder e) of f), van artikel 6, lid 1, met inbegrip van profilering op basis van die bepalingen. De verwerkingsverantwoordelijke staakt de verwerking van de persoonsgegevens tenzij hij dwingende gerechtvaardigde gronden voor de verwerking aanvoert die zwaarder wegen dan de belangen, rechten en vrijheden van de betrokkene of die verband houden met de instelling, uitoefening of onderbouwing van een rechtsvordering.
Bezwaar maken kan dus, maar het moet gaan om redenen vanwege zijn specifieke situatie, zeg maar persoonlijke redenen. En dan moet een afweging volgen: heeft de verwerkingsverantwoordelijke dwingende gronden om tóch door te gaan?

Maar voor direct marketing is het simpeler:

3. Wanneer de betrokkene bezwaar maakt tegen verwerking ten behoeve van direct marketing, worden de persoonsgegevens niet meer voor deze doeleinden verwerkt.
Je moet de slider dus zien als zo’n bezwaar tegen marketing. De slider op uit zetten is dus “I object”, ik maak bezwaar. Dat voelt ergens niet correct, UI-technisch gezien, maar het werkt wel.

Arnoud

AP geeft AVG-boete van 15.000 euro aan bedrijf dat ziektes registreerde

Geplaatst op in Ondernemingsvrijheid, Privacy, 3 reacties

De Autoriteit Persoonsgegevens heeft een boete van 15.000 euro opgelegd aan een bedrijf dat zijn systeem om ziekteverzuim te registreren slecht beveiligde. Dat meldde Tweakers onlangs. Ook verzamelde het bedrijf onterecht meer gezondheidsgegevens dan was toegestaan, zoals specifieke klachten en verloop van de ziekte. Opmerkelijk is vooral dat de boetes volgens de regels zouden neerkomen op respectievelijk 725.000 en 310.000 euro voor de twee overtredingen, maar gematigd worden tot 15.000 euro vanwege de beperkte omvang van het bedrijf.

Het wordt natuurlijk al heel lang geroepen: blijf van de medische gegevens van je personeel af. Daar heb je als werkgever niets mee te doen, de arts of verzekeraar meldt je wanneer meneer of mevrouw weer aan het werk kan en wat dan de beperkingen of benodigdheden zijn. Toch blijken hele horden werkgevers deze informatie nog steeds te noteren, dus het signaal van deze boete is ontzettend belangrijk.

Natuurlijk zijn er dingen die je als werkgever wel moet weten. Maar dat is een beslissing van de arts of het relevant is, en die zal het dan met je delen. Als werkgever mag je daar niet zelf informatie over bijhouden, eigen dossiers over opbouwen of wat dies meer zij. Ook niet als je denkt dat de werknemer simuleert en niet echt ziek is. Dat is en blijft een medisch oordeel.

Dit bedrijf hield een verzuimregistratie bij in een Google Drive bestand. En dat bleek zonder enige beveiliging toegankelijk via internet, logisch dus dat de AP daarover viel. Bovendien zag men dat in die registratie de reden van verzuim (over zowel de fysieke als mentale gezondheid), de prognose en de opmerkingen over de verzuimreden en prognose over deze werknemers) was opgenomen, wat natuurlijk in strijd is met de AVG.

Maar wat mag er dan wel? De AP citeert haar eigen richtlijnen, ik doe dat ook maar even:

De gegevens die volgens de beleidsregels ‘De zieke werknemer’ (2016, maar AVG-proof geschreven) wél mogen worden verwerkt zijn:

  • de werkzaamheden waartoe de werknemer niet meer of nog wel in staat is (functionele beperkingen, restmogelijkheden en implicaties voor het soort werk dat de werknemer nog kan doen);
  • de verwachte duur van het verzuim;
  • de mate waarin de werknemer arbeidsongeschikt is (gebaseerd op functionele beperkingen, restmogelijkheden en implicaties voor het soort werk dat de werknemer nog kan doen);
  • eventuele adviezen over aanpassingen, werkvoorzieningen of interventies die de werkgever voor de re-integratie moet treffen.
De gegevens die volgens deze beleidsregels niet mogen worden verwerkt, zijn onder meer:
  • diagnoses, naam ziekte, specifieke klachten of pijnaanduidingen;
  • eigen subjectieve waarnemingen, zowel over geestelijke als lichamelijke gezondheidstoestand;
  • gegevens over therapieën, afspraken met artsen, fysiotherapeuten, psychologen e.d.;
  • overige situationele problemen, zoals relatieproblemen, problemen uit het verleden, verhuizing, overlijden partner, scheiding e.d.
Het verschil tussen die twee zit hem in het belang voor het werk. Weten wat iemand niet meer kan kan en wanneer zhij weer begint, dat heeft een werkgever nodig. Weten waaróm iemand iets niet meer kan, dat is een ander verhaal. “Meneer moet na 30 minuten zitten een half uur staan”, daar kun je prima mee aan de slag als werkgever zonder dat je hoeft te weten of het versleten ruggewervels zijn of voorkomen van een migraine. Ook je eigen inschattingen “ze zegt migraine maar lijkt mij smoesje vanwege arbeidsconflict” horen niet in zo’n dossier thuis.

Tegelijk begrijp ik die werkgevers ook wel: het is heel logisch, ook vanuit betrokkenheid naar je personeel, dat je zulke dingen noteert. Dat wil je onthouden, je wilt inzicht en begrip. Maar omdat er ook werkgevers zijn die dit noteren om “zelf te beoordelen of je weer ziek bent” of vanuit het idee dat zij beter kunnen inschatten wat de werknemer nodig heeft, is dit wettelijk verboden.

Arnoud

Ben ik verwerker bij de accounts van mijn klanten?

Geplaatst op in Privacy, 7 reacties

Een lezer vroeg me:

Zoals heel veel SaaS-diensten bied ik accounts aan voor bedrijfsmatig gebruik: één account per gebruiker, maar gekoppeld via een bedrijfsabonnement. Ben ik nu verwerker voor de gegevens in die accounts?
Het valt me inderdaad op dat vele SaaS-dienstverleners denken dat ze verwerker zijn omdat ze persoonsgebonden accounts hebben. Dat is alleen te kort door de bocht. Mogelijk komt dit door een spraakverwarring: je verwerkt dan wel persoonsgegevens, maar je bent pas verwerker als je dat doet in opdracht van een ander (de verwerkingsverantwoordelijke).

Wanneer ik een dienst afneem, en daarbij zijn mijn persoonsgegevens nodig (bijvoorbeeld voor een account + facturatie, of voor het tonen van mij als gebruiker aan andere gebruikers) dan is de dienstverlener gewoon de verwerkingsverantwoordelijke. Hij bepaalt immers wat er gebeurt met die gegevens van mij: waar worden ze getoond, wie heeft er toegang toe en waar mogen ze worden ingezet.

Ik zou die dienst namens mijn bedrijf kunnen afnemen. Dan kunnen ook collega’s een account krijgen binnen het bedrijfsaccount, en normaliter betaal ik dan maar één keer. Dit verandert alleen nog niets aan de situatie voor verwerkerschap: de dienstverlener bepaalt nog steeds wat er gebeurt met al die persoonsgegevens, van zowel mij als van mijn collega’s. Hij blijft dan dus verwerkingsverantwoordelijke.

Een dienstverlener wordt verwerker wanneer het verwerken van de persoonsgegevens onderdeel is van de dienst, want het juridisch criterium is dat ik als klant doel en middelen vaststel. Het triviale voorbeeld is een personeelsadministratie: ik upload dan een set personeelsgegevens met bijvoorbeeld loongegevens, en de SaaS-dienst genereert loonstroken. Voor die set is men dan verwerker, want ik bepaal wat ik upload (welke personeelsleden, welke gegevens) en waarom (ik wil loonstroken).

De accounts om toegang te krijgen tot de dienst zijn volgens mij geen onderdeel van de dienst, zodat daarvoor geen verwerkersovereenkomst met de klanten nodig is. Zolang de leverancier/dienstverlener zelf bepaalt wat hij doet met die accounts, is hij daar zelf verwerkingsverantwoordelijke voor.

Arnoud

Foto’s van je kinderen op internet plaatsen versus de AVG

Geplaatst op in Privacy, 15 reacties

Gedaagde heeft beeldmateriaal (foto’s en filmpjes) op social media geplaatst van het minderjarige zoontje van eiseres, zo opende een recent vonnis van de rechtbank Overijssel. Dat mocht niet van de ex-partner. Want voor het plaatsen van foto’s van minderjarigen die de leeftijd van zestien jaren nog niet hebben bereikt, is toestemming van de wettelijk vertegenwoordiger vereist. Althans, ongeveer. En over die ongeveer wilde ik het even hebben.

Heel kort: de vrouw in de relatie had met een andere man een kind gekregen, waar de gedaagde (ik denk ook een man) later ouderlijk gezag over kreeg. Dit gezag bleef gezamenlijk toen de relatie uitging. En op enig moment daarna plaatste de gedaagde foto’s van het kind op Facebook. De eiseres was het daarmee oneens en stapte naar de rechter.

De rechter is er werkelijk in één alinea mee klaar: er is toestemming nodig van de ouders voor publicatie van foto’s van kinderen, die toestemming moet van beide ouders komen en die is er niet, dus die foto’s moeten weg. Dwangsom 50 euro per dag, maximum 2.500 euro, boem u kunt gaan.

Inhoudelijk denk ik weinig mis mee, het is al vaker bepaald dat foto’s van minderjarigen niet tegen de wil van (een van) de ouder(s) door de andere ouder mogen worden gepubliceerd. Maar ik zie hier een veel voorkomend misverstand, namelijk dat de AVG (en UAVG) zeggen dat je áltijd toestemming van de ouders nodig hebt voor publicatie. Dat is namelijk niet waar.

Het misverstand komt door artikel 8 lid 1 AVG, dat begint met

Wanneer artikel 6, lid 1, punt a), van toepassing is in verband met een rechtstreeks aanbod van diensten van de informatiemaatschappij aan een kind, is de verwerking van persoonsgegevens van een kind rechtmatig wanneer het kind ten minste 16 jaar is. Wanneer het kind jonger is dan 16 jaar is zulke verwerking slechts rechtmatig indien en voor zover de toestemming of machtiging tot toestemming in dit verband wordt verleend door de persoon die de ouderlijke verantwoordelijkheid voor het kind draagt.
En daarbij is dan artikel 6 lid 1 sub a AVG de grondslag toestemming. Snel lezend staat hier inderdaad dat toestemming bij internetdiensten door minderjarigen niet kan, dat moeten de ouders of verzorgers geven. Maar lees het nog eens: er staat niet dat verwerken alleen mag met zulke toestemming, er staat dat als je met toestemming werkt, die toestemming moet worden verleend door de ouders.

Niets houdt je dus tegen om te verwerken met een andere grondslag, zoals uitvoering overeenkomst of een eigen gerechtvaardigd belang. Een kind van dertien dat zijn naam invoert in een chatdienst, hoeft geen ouderlijke toestemming. Die naam (een persoonsgegeven) is nodig voor de dienst, je moet aangesproken kunnen worden door medechatters en daar is je naam het logische element voor.

In dit geval had de mede-ouder het wellicht kunnen gooien op dat gerechtvaardigd belang, kort door de bocht zijn uitingsvrijheid. Of dat was gelukt, weet ik niet – je moet als publicerende ouder rekening houden met de privacy van je kind, en hoe je dat doet bij Facebookpublicaties is mij nog niet duidelijk. Maar het is dus zeker geen geval “geen toestemming = mag niet”.

Arnoud

Facebook gaat de half miljard getroffen gebruikers niet informeren over datalek, nee die snapte ik ook niet

Geplaatst op in Privacy, 12 reacties

Facebook gaat de bijna 533 miljoen gebruikers van wie de data onlangs op een hackersforum is geplaatst, niet actief informeren over het datalek. Dat meldde Tweakers vorige week. Het platform zegt niet zeker te weten welke gebruikers ingelicht zouden moeten worden en dat de informatie toch openbaar online staat. Dat voelt een tikje absurd; de gebruikers die je moet hebben staan, eh, in die gelekte dataset. Wat is precies het probleem, of wat hebben de advocaten van Facebook nou weer bedacht als smoes om onder hun plichten uit te komen?

Vorige week verscheen een dataset met ongeveer een half miljard persoonsgegevens online, met daarin telefoonnummers, Facebook-id’s, volledige namen, locaties, voorgaande locaties, geboortedata, geslacht, relatiestatus, bio-teksten, datum van accountcreatie, werkgever en (soms) e-mailadressen. Vermoedelijk is de data verkregen door een fout in de ‘vriend toevoegen’-functie, waar tot telefoonnummers van vreemden voor nodig was. Gebruikers kunnen via tools als Have I Been Pwned zien of zij in de dataset staan.

Dit noemen we juridisch gezien natuurlijk een datalek in de zin van de AVG: grootschalig ongeautoriseerde publicatie van persoonsgegevens. Dat moet je melden bij de toezichthouder, en je moet alle betrokkenen informeren over dat hun data getroffen is, plus mogelijke gevolgen, maatregelen et cetera. En dat wil Facebook dus niet doen, want “the social media company was not confident it had full visibility on which users would need to be notified.” Dat voelt erg paarse-krokodil: ze staan dáár, die users.

Tevens stelt men dat je toch niets kunt doen tegen het lek, en de data is ook nog eens openbaar. Nee, daar snap ik nog minder van: dat is júist een reden om mensen te informeren. “Nee, tegen uw tumor is niets te doen en iedereen kan het zien, dus vandaar dat u nooit een diagnose kreeg”. Eh, kom nou.

Mededelen van datalekken moet, tenzij. Zo staat het in de AVG. En die ’tenzij’ is beperkt tot drie situaties:

  1. de verwerkingsverantwoordelijke heeft passende technische en organisatorische beschermingsmaatregelen genomen en deze maatregelen zijn toegepast op de persoonsgegevens waarop de inbreuk in verband met persoonsgegevens betrekking heeft, met name die welke de persoonsgegevens onbegrijpelijk maken voor onbevoegden, zoals versleuteling;
  2. de verwerkingsverantwoordelijke heeft achteraf maatregelen genomen om ervoor te zorgen dat het in lid 1 bedoelde hoge risico voor de rechten en vrijheden van betrokkenen zich waarschijnlijk niet meer zal voordoen;
  3. de mededeling zou onevenredige inspanningen vergen. In dat geval komt er in de plaats daarvan een openbare mededeling of een soortgelijke maatregel waarbij betrokkenen even doeltreffend worden geïnformeerd.
Situatie 1 is grofweg dat de data wel is gelekt maar in sterk versleutelde of gepseudonimiseerde vorm. Dan is het risico op misbruik minimaal immers. Maar dat is hier niet van toepassing.

Situatie 2 gaat over datalekken waarbij je kon ingrijpen om de gevolgen van het lek tegen te houden. Je passwords lekten, maar je reset snel alle wachtwoorden en je monitoring gaf aan dat er niet ingelogd was in de tussentijd.  Ook niet van toepassing, integendeel.

Situatie 3 is bij 533 miljoen mensen en alleen een telefoonnummer uit 2019 wellicht verdedigbaar. Die allemaal gaan bellen is te arbeidsintensief, dus dan zou een algemene mededeling (in de krant, of eh op Facebook) een betere optie zijn. Maar daar staat tegenover dat het Facebook-id in de dataset zit. Dus dan kun je in ieder geval de nog actieve gebruikers nazoeken en die een berichtje via het platform sturen. Benieuwd hoe veel er dan nog overblijven.

In ieder geval, ik kan vanuit AVG-perspectief helemaal niets met deze reactie.

Arnoud

Moet je ook een DPIA uitvoeren op interne systemen?

Geplaatst op in Ondernemingsvrijheid, Privacy, 6 reacties

Een lezer vroeg me:

Volgens de AVG zijn er een aantal criteria wanneer je een DPIA moet uitvoeren. Maar vallen interne systemen, zoals o.a. een DMS, e-mail, backups ed. ook onder deze ‘plicht’ ? Ik vraag dit omdat onze FG ook die systemen als “hoog risico” aanmerkt, wat enorme vertraging geeft.
Een DPIA of data protection impact assessment is een verplicht nummer voor verwerkingen van persoonsgegevens met waarschijnlijk een hoog risico voor de betrokken personen (artikel 35 AVG). Meestal gaat het dan om nieuwe technologieën, maar dat hoeft niet.

Om te bepalen of het risico hoog is, moet je volgens de AVG kijken naar “de aard, de omvang, de context en de doeleinden” van de verwerking. Er is geen expliciete uitzondering voor intern versus extern, wat dat ook zou mogen betekenen in de context van verwerken van persoonsgegevens.

De AP heeft een lijst gepubliceerd van verwerkingen die in ieder geval eerst aan een DPIA onderworpen moeten worden. Hieronder valt onder meer heimelijk onderzoek van personeel door werkgevers, grootschalige fraudebestrijding (concreet: AI-analyse van je klantenbestand), grootschalig monitoren van personeel of klanten, stelselmatig monitoren van dataverkeer anders dan voor security, uitgebreid profileren en ga zo maar door.

Ik zie wel hoe een “intern” gebruik van persoonsgegevens onder deze kopjes kan vallen. De kern is voor mij wel dat het vrijwel altijd gaat om “grootschalig” gebruik. Dus één werknemer tijdelijk volgen vanwege een vermoeden van lekken van bedrijfsgeheimen zou geen DPIA vereisen.

Het uitrollen van een nieuw e-mailsysteem zou voor mij ook geen DPIA nodig hebben, maar wél als je er productiviteitsdingen in gaat toevoegen en daarmee werknemers monitort op hun effectiviteit. Een nieuwe procedure voor backups van bedrijfsdata lijkt me op zich ook niet hogo risico, met backups ging je sowieso al om alsof het goud was.

Arnoud

Oh sjonge, optimaliseren van onze website is dus een boetewaardige cookietekst

Geplaatst op in Privacy, 12 reacties

De Franse privacyautoriteit CNIL heeft Google en Amazon een boete van respectievelijk 100 miljoen en 35 miljoen euro gegeven, las ik bij Nu.nl. Het boetebesluit is opmerkelijk omdat het gewoon recht voor z’n raap beboet wat veel mensen al lang zeggen maar bedrijven gewoon blijven doen: direct een tracking cookie zetten en ook nog eens in de cookiemelding alleen maar vage teksten als “By using this website, you accept our use of cookies allowing to offer and improve our services. Read More” te hanteren. Het blijft me verbazen, dat iedereen daar gewoon mee doorging.

Of nou ja, eigenlijk ook weer niet want iedereen doet het en er werd toch niet op gehandhaafd. Maar ik had denk ik wel ergens verwacht dat die vage teksten als “wij gebruiken cookies om uw bezoekerservaring te optimaliseren” wel zouden verdwijnen toen de AVG haar intocht maakte. Dat blijkt dus fors tegen te vallen.

De CNIL is de Franse toezichthouder, en legt dan ook de boete op voor de dienst Google.fr en Amazon.fr – aan de Franse dochter van Google en Amazon, omdat die daadwerkelijk in de EU gevestigd zijn. Zo concludeert men:

Therefore, the processing consisting of operations of accessing or entering information in the terminal of users of the Google Search search engineresiding in France, in particular for advertising purposes, is carried out within the framework of the activities of the company GOOGLE FRANCE on French territory, which is in charge of the promotion and marketing of GOOGLE products and their advertising solutions in France.
(Wat natuurlijk klopt, die Europese dochterbedrijven zitten er om advertenties te verkopen dus die tracking cookies draaien daar voor hún zakelijk belang. De juridische bedrijfsstructuur doet er dan gewoon niet meer toe.)

Maar dan de echte discussie, hoe moet je uitleggen wat je doet? Na eerst alleen maar “Beheer uw privacy klik hier” te hebben gehad, had Google bijvoorbeeld op zeker moment dit ingevoerd:

Google uses cookies and other data to provide, manage and improve its services and ads. If you agree, we’ll personalize the content and ads you see based on your activity on Google services like Search, Maps, and YouTube. Some of our partners also assess how our services are used. Click “More Info” to explore your options or visit g.co/privacytools anytime
Maar is dit genoeg? Nee, aldus de CNIL: hieruit haal je niet dat je gevolgd wordt over meerdere apparaten en diensten heen, dat sprake is van vérgaande personalisatie en vooral dat je dit alles kunt uitzetten. Ja, er staat “more info to explore options” maar dat is bij lange na natuurlijk niet een mogelijkheid om te weigeren. En laat de wet nu niet alleen een weigermogelijkheid eisen maar zelfs een vooráfgaande: je moet gewoon vrijelijk toestemming kunnen geven of niet.

Wie heel hard zocht, kon een opt-out mogelijkheid vinden. Alleen bleek daarbij dat daarna niet alle cookies daadwerkelijk werden verwijderd of op opt-out werden gezet, zodat het tracken vrolijk verder kon gaan.

Goed, en nu. Moet iedereen stoppen met die vage zinnen, en vooral met cookies plaatsen voordat mensen op ja hebben geklikt? Nou ja, wat denk je zelf. Maar ik weet ook wel dat de concurrent er gewoon mee doorgaat, dat deze zaak nog jaren gaat slepen en dat er dus bar weinig prikkel is om morgen over te stappen op een volledig compliant systeem. Dit is echt een probleem.

Arnoud

Ticketmaster krijgt boete van 1,4 miljoen euro van Britse privacywaakhond

Geplaatst op in Privacy, Security, 28 reacties

Het Britse bedrijf Ticketmaster heeft een boete gekregen voor een datalek in 2018, las ik bij Nu.nl. Door een kwetsbaarheid in de chatbot op de website konden derden toegang krijgen tot betaalgegevens van 37.000 creditcardhouders, en in theorie zelfs 9.4 miljoen mensen uit de hele EU. Opmerkelijk aan de zaak vond ik vooral dat die chatbot een ingekochte component was en dat de leverancier al enige tijd op de hoogte was van het lek.

Het boetebesluit legt uit dat in 2018 een aantal bank-klanten ontdekten dat hun creditcard frauduleus werd gebruikt, wat te herleiden was tot een aanschaf bij Ticketmaster. (Smoking gun: een testbetaling met gefingeerde expiry date dook met diezelfde datum op in het criminele circuit.) De site van Ticketmaster bleek gehackt en voorzien van malware die gegevens doorstuurde.

De hack bleek mogelijk door een ingezette chatbot van het bedrijf Inbenta. De bot was zo’n typische vraagbeantwoordbot om de menselijke helpdesk te ontlasten, en kwam gezellig mee op elke pagina in het besteltraject. Daardoor kon – na het compromitteren van de code – de bot ook gegevens lezen uit bestel- en betaalformulieren, wat dus de creditcarddiefstal mogelijk maakte. Inbenta was desgevraagd erg verbaasd:

The Javascript we created specifically for Ticketmaster was used on a payments page, which is not what it was built for. Had we known that script would have been used in that way, we would have advised against it, as it poses a security threat.

Deze werkwijze was verder in strijd met de PCI-DSS regels voor het verwerken van creditcardgegevens. Desondanks vond Ticketmaster dat niet haar maar Inbenta verwijten te maken waren, zij mocht contractueel rekenen op een veilige chatbot dus dan is het overmacht als de chatbot onveilig blijkt. Een argument dat ik vaak hoor: “In de verwerkersovereenkomst staat dat de leverancier garandeert veilig te zijn, we hebben de veiligheid dus geregeld”.

De ICO accepteert dat excuus volstrekt niet, en ik zou iedereen ook willen aanraden om wie dat argument gebruikt een stevige schrobbering te geven. Security is niet iets dat je contractueel afspreekt, dat is iets dat je praktisch regelt én verifieert. Security doe je.

Natuurlijk zijn superzerodayhacks altijd mogelijk, en ik kan best accepteren dat dat overmacht zou kunnen opleveren. Maar het ging hier om een simpele Javascript aanpassing waarmee betaalformulieren uit te lezen en te kapen waren, iets dat zeker weten in 2018 tot de gewone stand der techniek behoorde en waar dus gewoon beveiliging tegen hoort te zijn.

Maar maar maar, aldus Ticketmaster: wij hadden netjes compliance geregeld, kijk maar:

At §§8-9 of its Comments, Ticketmaster relies upon its receipt of security certifications provided by Inbenta. At §29.3 of the Comments, Ticketmaster emphasises Inbenta’s ISO 27001 certification. The Commissioner places little weight on the mere provision of such certifications by Inbenta as a mechanism of securing the chat bot in the circumstances. Further, ISO 27001 is an information security management standard, which does not apply directly to software development.

Een certificering is nog geen bugfix, laat staan een securitymaatregel. Een code review of een security audit was dat wel, maar daar had Ticketmaster nul moeite in gestoken. En dat wordt ze serieus kwalijk genomen:

Rather, the GDPR requires that each organisation assess the risks arising in the circumstances of their own implementation and put controls in place to protect the personal data that it processes. Ticketmaster has shown very limited knowledge at the date of the Incident of the risk of implementing third party scripts into a payment page, despite it being widely known and documented at that time. A fortiori, Ticketmaster has not evidenced that it deployed appropriate and proportionate controls to manage this risk.

Verder noemt de ICO dit een serieuze overtreding van de AVG: in theorie hadden 9.4 miljoen klanten hun betaalgegevens gestolen kunnen hebben, en Ticketmaster had geen enkele control in place om hier wat tegen te doen. (Zelfs passieve detectie door wekelijks zelf een nepcreditcard te proberen was er niet.) De boete komt uiteindelijk dus uit op 1.4 miljoen euro. Een terechte tik op de vingers, wat mij betreft.

En ik zeg het nogmaals, want ik weet dat er veel contractsjuristen, FG’s en ander AVG compliance volk meeleest: doe alsjeblieft méér dan alleen contractueel vastleggen dat de veiligheid op orde moet zijn. Zonder daadwerkelijk feitelijk handelen ben je gewoon niét AVG compliant, al staan er honderd garanties en heb je duizend certificeringen.

Arnoud

Is een SaaS dienstverlener vanwege de AVG verplicht escrow op te zetten?

Geplaatst op in Ondernemingsvrijheid, Privacy, 7 reacties

Een lezer vroeg me:

Strekt de AVG zover dat softwarepartijen verplicht zijn – in het kader van beveiligen van de continuiteit – een escrowachtige regeling aan te bieden waarbij software en hosting geborgd zijn na een faillissement of overname?
De AVG verplicht tot adequate maatregelen tot beschikbaar houden van persoonsgegevens zo lang als dat nodig is voor de toegezegde dienstverlening en de rechten van betrokkenen. Er is dus nergens een algemeen lijstje met wat je moet doen of hoe lang, je moet zelf beredeneren (al dan niet in een DPIA) wat er nodig is om aan deze eis te voldoen.

Een partij die een softwaredienst met persoonsgegevens aanbiedt, moet er dus voor zorgen dat die dienst blijft draaien zo lang als nodig. Escrow of een continuïteitsregeling is daarvoor een mogelijk middel. Maar als er andere manieren zijn om de klanten te blijven bedienen, dan is dat ook prima. Een offline backup die in noodgevallen naar de klanten gestuurd kan worden, zou ook kunnen werken.

Bij faillissement zal de dienstverlening gewoonlijk eindigen, hoewel dat niet wil zeggen dat de betrokkenen dan geen rechten meer hebben. Dus formeel zou ik zeggen dat er dan iets van continuïteit moet zijn, hoewel dat praktisch gezien lastig af te dwingen is want de organisatie is dan nou eenmaal failliet en dan houdt het gewoon op.

Het grote probleem met escrow is dat het daadwerkelijk uitvoeren pittig kan zijn: ga er maar aan staan om vanuit een broncodedepot een online dienst weer neer te zetten. Zat de database met gegevens bijvoorbeeld ook in het depot? Hoe oud was die databasedump dan eigenlijk?

Een overname is geen excuus voor welke wijziging in de dienstverlening dan ook. Daar moet de dienst dus gewoon doorlopen en moeten de gegevens gewoon beschikbaar zijn.

Het maakt natuurlijk ook nog uit of het softwarebedrijf een verwerkingsverantwoordelijke is of een verwerker. Als dat laatste het geval is, dan zal de afnemer van de dienst meer stappen moeten nemen om zich tegen uitval van die verwerker te wapenen. Escrow of continuïteit ligt dan meer voor de hand.

Arnoud