Ga er maar aanstaan als deskundige: moet die broncode opnieuw geschreven?

Deskundige vereist voor beoordeling gebrekkige broncode, meldde ITenRecht onlangs. In een automatiseringsgeschil tussen softwareontwikkelaar Capgemini en haar klant Equihold (die de software wilde inzetten bij onder meer FC Barcelona) ontstond discussie over de kwaliteit van de tot dan toe gemaakte broncode. Een mooi voorbeeld van hoe de rechtspraak omgaat met inhoudelijk diepgaande issues. Ik las laatst weer dat rechters moeten leren programmeren omdat ze anders dit soort zaken niet kunnen doen. Onzin, wat mij betreft. Daar heb je deskundigen voor. Maar bij deze zaak denk ik dan wel, blij dat ik die deskundige niet ben.

In 2002 ontwikkelde Equihold een sportapplicatie met de naam 1-2 Focus. Deze applicatie was geschreven in de programmeeromgeving en programmeertaal VB6. In 2004 besloot men deze om te werken naar Microsoft .NET, waarna men in 2005 een raamovereenkomst sloot met Capgemini om het werk te laten doen. Ik zal u de verdere tijdlijn besparen, maar in 2010 eindigde het feest met een brief aan Capgemini met als titel “1-2Focus; developed by Capgemini A Showcase of Bad Practices”.

Wat was er nu precies aan de hand met die broncode? Helaas is dat in het arrest niet in detail te achterhalen. We moeten het doen met uitspraken als

Volgens [B] , een voormalig werknemer van Equihold, heeft de broncode niet de gewenste laagstructuur, bestaat deze uit onnodig veel regels en is deze onsamenhangend. Zijn conclusie is dat de broncode van zo bedroevende kwaliteit is dat het volledig herschrijven daarvan onvermijdelijk is. SQMI is volgens [appellant] een gerenommeerde en onafhankelijke partij die een onderzoeksmethode gebruikt die is ontwikkeld door het Institute for Software Quality (IfSQ). Het rapport SQMI concludeert dat de broncode een hoog aantal ‘defect indicators’ heeft, dat de onderhoudskosten van de software onnodig hoog zijn en dat de software ongeschikt is als platform voor verdere ontwikkeling. Graham Bolton, oprichter van IfSQ en directeur van SQMI, (verder Bolton) voegt daar in een schriftelijke verklaring aan toe dat het verbeteren van de geconstateerde gebreken meerdere jaren in beslag zou nemen, en zelfs meer tijd zou kosten dan het geheel opnieuw schrijven van de applicatie.

Capgemini kon daar echter een ander rapport tegenover stellen dat juist aantoont dat de onderhoudbaarheid marktconform is.

Dan krijg je dus de situatie dat partijen elkaar tegenspreken, en dat je als rechter dan moet vaststellen wat er nu waar is. In een geval als dit is dat erg lastig, allereerst natuurlijk omdat broncode op kwaliteit toetsen sowieso ingewikkeld is (de een z’n ***var is de ander z’n nachtmerrie) maar ten tweede omdat dit om zo’n grote codebase gaat dat er een hele partij werk in gaat zitten. Oh ja, en omdat er natuurlijk niet echt objectieve standaarden zijn om codekwaliteit vast te stellen.

Een belangrijke factor in het geschil was de onderhoudbaarheid: kun je op lange termijn hiermee door, ook (denk ik) met een andere onderhoudspartij dan Capgemini zelf. Bij grote applicaties is langdurig gebruik te verwachten, dan heb je andere verwachtingen qua onderhoud en aanpasbaarheid voor de toekomst dan bij een snelle app voor een event begin volgend jaar.

Dus, ik gooi hem eens in de groep, voor al die IT-ers die denken dat rechters meer verstand van software nodig hebben: hoe zouden jullie bij deze berg aan code objectief vaststellen of de kwaliteit voldoet aan de contractuele eis van ‘high quality software’?

Arnoud

“Camera met gezichtsherkenning meestal niet toegestaan”

Het gebruik van camera’s met gezichtsherkenning is, zo las ik bij Security.nl meestal niet toegestaan voor bedrijven. Dit volgt uit een recente publicatie van de Autoriteit Persoonsgegevens. De privacytoezichthouder gaat daarom sectoren die dergelijke camera’s vaak gebruiken voorlichting geven over de regels. De Algemene verordening gegevensbescherming (AVG) verbiedt in beginsel het gebruik van biometrische gegevens om iemand te identificeren, maar het gebeurt vaak aldus de toezichthouder: Winkels gebruiken gezichtsherkenningscamera’s om winkeldieven op te sporen, terwijl bedrijven in de beveiliging, beurslocaties en pretparken de technologie inzetten voor toegangscontrole.

Het onderwerp is al wel vaker langsgeweest, eind vorig jaar blogde ik over gezichtsherkenning inzetten om een lokaalverbod te handhaven en eerder die sportschool die ’s nachts mensen met gezichtsherkenning binnenliet. De kern van het probleem is dat biometrische gegevens als bijzondere persoonsgegevens gelden, en je daar dus van af moet blijven. Gebruik je foto’s van mensen om ze te herkennen, dan tellen die foto’s als biometrische gegevens (een gewoon kiekje is dus geen biometrisch persoonsgegeven). En dan mag je ze dus niet gebruiken.

Dat ‘herkennen’ moet je breed opvatten: het gaat niet alleen over matchen tegen een database met NAW-gegevens of iets dergelijks. Ook enkel geautomatiseerd constateren “die was hier gisteravond ook” of “die lijkt op foto 31337 uit ons bestand overlastplegers” is al een vorm van ‘herkennen’, waarmee je camerabeelden tot bijzondere persoonsgegevens verworden.

Enige ruimte wordt gegeven door de uitzondering uit artikel 29 Uitvoeringswet: identificatie van de betrokkene die noodzakelijk is voor authenticatie of beveiligingsdoeleinden. En natuurlijk, het doel van deze identificatie (inclusief de 31337-constatering) is voor beveiliging, je wilt overlastplegers, lokaalverbodshouders et cetera niet binnen hebben. Maar is er een nóódzaak? Die vraag is veel lastiger want dat is een hele hoge lat.

Kort gezegd moet er dan geen ander middel voorhanden zijn dat ongeveer zo effectief is, en de maatregel moet ook proportioneel zijn. De AP gaat zelfs nog een stapje verder:

Het moet daarbij wel gaan om een zwaarwegend algemeen [italics AE] belang. Dat is bijvoorbeeld de beveiliging van een kerncentrale. Maar de beveiliging van bijvoorbeeld een supermarkt is niet zó belangrijk dat u daarvoor biometrische gegevens mag verwerken.
Dat algemeen belang haal ik zo niet uit de Uitvoeringswet, maar het is natuurlijk waar dat beveiligen van één winkel geen algemeen belang dient. Ik had zelf altijd het idee dat ook een individueel belang goed genoeg kon zijn (dit is weer die discussie over legitiem belang, geloof ik), maar dat het misgaat op wat ik de innovatieparadox noem.

De innovatieparadox uit de AVG luidt: nieuwe maatregelen voldoen nooit aan de noodzakelijkheidseis omdat er altijd bestaande maatregelen zijn die goed genoeg zijn. Zet een portier neer die het verbod handhaaft, beveilig je supermarkt met detectiepoortjes, doe toegangscontrole met tickets op naam, et cetera. Natuurlijk zitten daar kosten aan, maar zeker in het begin zitten die er ook aan camera-identificatie – aanschaf, onderhoud, testen en beveiligen bijvoorbeeld. Dus “dit is veel goedkoper” is geen argument.

Oftewel: hoe betoog je dat een nieuwe manier van persoonsgegevens verwerken acceptabel is, als deze net zo duur is en zich nog niet bewezen heeft in de praktijk?

Arnoud

Moet je als programmeur verstand van rechten hebben? #legaltechtuesday

Vorige week blogde ik Moet je als jurist leren programmeren? en dat gaf vele leuke reacties, waaronder via Linkedin de vraag:

Vice versa, zou je ook kunnen stellen dat software ontwikkelaars enige basiskennis van de juridische praktijk moeten hebben ?
Grappig genoeg hoor je die een stuk minder vaak. Maar de observatie is een hele scherpe, ik denk zeker wel en zelfs méér kennis dan omgekeerd juristen van het programmeerveld.

Dit omdat software steeds vaker gewoon juridische dingen oplost, denk aan het bestellen van producten, het maken van afspraken, het vastleggen van contracten etc. Vaak zie je dat het daar juridisch nét rammelt, of naar Amerikaans voorbeeld gebouwd wordt. En dat is niet alleen irritant voor juristen die het toevallig zien (ik heb tegenwoordig speciale sloffen waar mijn tenen in kunnen krommen) maar ook gewoon kostbaar voor je klant.

Simpel voorbeeld: vrijwel iedere websitebouwer die een bestelformulier of aankoopscherm bouwt, zet daar een vinkje bij waarmee de algemene voorwaarden kunnen worden aanvaardt. Doet iedereen, zal wel moeten en de documentatie legt het ook niet uit. Maar het is fout: zo’n vinkje is helemaal niet nodig om mensen aan je voorwaarden te binden.

Over de AVG en hoe dat uitpakt, daar kan ik een boek over schrijven, zo veel fouten worden daarin gemaakt. Toestemming vragen waar dat niet hoeft, privacyverklaringen laten accorderen, plugins van derden neerzetten en denken dat dat zomaar mag, zo kan ik nog wel even doorgaan. Handig om te weten.

Maar het kan ook subtieler. Denk aan een site waar mensen dingen mogen posten. Natuurlijk kun je dan claims krijgen wegens bijvoorbeeld auteursrechtinbreuk, en daar moet je dan wat mee. (Ook trouwens met privacyclaims en andere dingen.) Maar dat betekent niet dat je zomaar alles weghaalt. Je houdt rekening met de rechten van je gebruikers, zoals wanneer ze een parodie posten of een citaat gebruiken en meer niet. Weten dat dit kan, lijkt me wel het minste dat je van een developer kunt vragen.

Natuurlijk hoef je als ontwikkelaar zeker niet een mr-titel te hebben. Ik denk dat het niet goed mogelijk is om én het IT-veld én het juridische veld allebei goed bij te houden, op het niveau dat beiden eisen als je het echt goed wil doen. Maar de basiskennis, ja die moet er zijn. Programmeren doe je niet in een vacuüm waar anderen juridische lucht in pompen.

Arnoud

Wat mag een werkgever met Sinterklaascadeaus in coronatijd?

Een lezer vroeg me:

Als FG bij ons bedrijf vroeg ik me af hoe we moeten omgaan met Sinterklaas in deze coronatijd. Traditioneel koopt iedereen cadeautjes voor elkaar (lootjes trekken), en koopt de werkgever ook nog iets van een chocoladeletter. Dat mensen elkaars postadres krijgen lijkt me niet de bedoeling, maar mag de werkgever het allemaal opsturen namens de collega’s? Of denk jij dat er toestemming nodig is?
Het is inderdaad zeer niet de bedoeling dat collega’s elkaars postadres (huisadres) krijgen zodat ze Sinterklaascadeaus kunnen opsturen.

Een werkgever mag zijn personeel natuurlijk cadeautjes geven, zeker rond de feestdagen. De AVG vindt het prima als je die dan opstuurt in een tijd van pandemie en/of thuiswerken. Dat valt gewoon onder goed werkgeverschap, oftewel uitvoering van de arbeidsovereenkomst. En als je een wat preciezere FG bent, dan gooi je dit op eigen gerechtvaardigd belang. Dat betekent praktisch gezien alleen dat werknemers bezwaar kunnen maken.

Vaak zie je dat zulke cadeau’s ingekocht worden bij een organisatie die ze ook verstuurt. Dan krijg je altijd de discussie of die organisatie verwerker of verantwoordelijke is. Ik zou daar niet te veel tijd aan besteden maar vooral afspreken dat deze organisatie geen eigen reclame gaat sturen naar het personeel, iets waar zulke clubs nog wel eens een handje van hebben.

Als de werknemers surprises voor elkaar maken, dan ontkom je er niet aan dat dit centraal verstuurd wordt vanuit de werkgever. Het lijkt me te ingewikkeld dat iedereen elkaars adres krijgt, behalve als er bezwaar is en dat getoetst wordt in alle vrijheid en weet ik veel. Doe jezelf en iedereen (behalve de office manager) een pleziertje en laat de office manager dat centraal doen.

Tentamenvraag: is Sinterklaas (een zzp’ende acteur die je daartoe inhuurt) een verwerker of een verwerkingsverantwoordelijke voor wat betreft de Grote Boek-informatie die de werkgever over de collega’s verschaft?

Arnoud

 

Wat kan ik als mijn werkgever mijn bsn en medisch dossier lekt?

Een lezer vroeg me:

De laptop van mijn leidinggevende is recent gestolen. Helaas was het systeem niet versleuteld, waardoor gevoelige persoonsgegevens (zoals mijn naam, geboortedatum, BSN, handtekening en medische gegevens) door de dief te lezen zouden kunnen zijn. Ik ben netjes geïnformeerd en het lek wordt gemeld, maar ik vind dit niet genoeg. Wat kan ik juridisch doen tegen mijn werkgever?
Allereerst: erg jammer en vervelend dat er anno 2020 nog steeds werkgevers zijn die dus dit soort gevoelige gegevens rondsjouwen zonder zelfs maar full-disk encryptie. Het is erg pijnlijk om daar via een datalekmelding achter te moeten komen.

De procedure is zo te lezen netjes gevolgd: de werknemer moet worden geïnformeerd en de AP ook, want de gegevens zijn zeer gevoelig en misbruik daarvan kan zeker tot schade bij de werknemer(s) leiden. Ook als het maar een handjevol mensen was – BSN en medische gegevens tellen als zeer gevoelig ook bij kleine hoeveelheden.

Dat wil niet zeggen dat de kous daarmee af is. De werknemer kan desondanks immers schade lijden door het lek, en volgens de AVG is de werkgever daar gewoon voor aansprakelijk stellen.

Het lastige hierbij is natuurlijk aan te tonen wat je schade is, zeker als er nog geen kwaadwillend gebruik van je gegevens is gemaakt. En bij diefstal van een laptop is de kans reëel dat dat ook niet gaat gebeuren; waarschijnlijk herinstalleert de dief Windows en verkoopt hij het ding tweedehands. Je kunt dan natuurlijk gaan monitoren op misbruik maar je zult waarschijnlijk niets tegenkomen.

Het gaat me wat ver om te zeggen dat een werkgever maar gewoon een bedrag moet geven bij wijze van forfaitaire schadevergoeding. Maar zonder concreet aangetoonde schade kan de werknemer verder niet zo veel. Bij financiële gegevens zou je nog kunnen eisen dat de werkgever een monitoringdienst betaalt om op het ahem “dark web” te kijken of je creditcard daar opduikt, maar voor bsn’s of medische dossiers is er niet echt zo’n markt.

Arnoud

Juinen heeft jou nodig om de nummer één AI wereldstad te worden!

Alles is in Juinen, is al veertig jaar het motto van dit trotse dorp. En nadat in 2019 dit land besloot miljarden te investeren in kunstmatige intelligentie (ook wel AI), dacht men: waarom is niet ook AI in Juinen? Precies op tijd voor de World City AI Ranking, waar tot ieders verbazing dit vaak klein ingeschatte plaatsje genomineerd was tussen technologiereuzen als Singapore, New York en Nairobi. Gaat het ze lukken om vanaf 1 februari genoeg AI-initiatieven te ontplooien die ook nog eens aan wet- en regelgeving voldoen? Ik heb jou, praktijkmens met affiniteit voor AI, regulering en compliance, daarbij hard nodig.

Jaja, dit gaat natuurlijk over mijn nieuwe cursus “AI in de praktijk: compliance en governance” die als elearning van start gaat per 1 februari. In tien hoofdstukken neem ik je via e-learning op unieke wijze mee in de materie, toets je interactief je niveau en werk je met échte casussen (en dus ook échte AI) om je begrip en beoordelingsvermogen te vergroten.

Compliance en AI, geloof me het is inhoudelijk leuk. Kijken hoe je transparante besluitvorming met een algoritme (sorry programmeurs) realiseert, hoe je datasets op bias naloopt en hoe je omgaat met de milieu-impact van AI. Maar ik snap best dat het saai is om alleen abstracte cases te oefenen.

Daarom deze game-opzet met Juinen: jij gaat als AI Compliance Officer van de gemeente aan de slag, en je krijgt cases van burgers en bedrijfsleven. Of van de gemeente zelf, in bijvoorbeeld deze interactieve video-oefening waarbij je de burgemeester en wethouder moet overtuigen van het belang van het juridisch borgen van AI.

Doe je mee? We beginnen 1 februari, eigen tijd maar elke week moet je wel je casus af hebben anders komt Juinen niet op nummer 1.

Arnoud

Is het ethisch hacken om het Twitterwachtwoord van Trump te raden?

De Nederlandse ethische hacker Victor Gevers heeft vorige week naar eigen zeggen het Twitter-account van Donald Trump gehackt. Dat meldde Tweakers vorige week. Het wachtwoord (maga2020!) was eenvoudig te raden, zegt Gevers tegen Vrij Nederland. VN zegt ook dat er sterke aanwijzingen zijn dat Gevers achter een beruchte tweet van de president zat. Het gaf de nodige discussie over ethisch hacken, dingen mogen veranderen en hoe publiek je mag gaan met zo’n ontdekking.

Victor Gevers was ook een van de hackers die in 2016 in wisten te breken op het account van Trump. Daarom kreeg deze inlog zo veel aandacht, hoewel er ook twijfel is over de echtheid. Twitter zelf zegt geen rare inlog te hebben gezien, en bij een screenshot van Gevers dat het interne profiel van Trump toont, ontbreekt het Amerikaanse vlaggetje in de biografie-regel. (Mogelijk kwam dat door de gebruikte browser/OS combinatie.)

Maar dat even terzijde. Stel inderdaad, je weet het wachtwoord van zo’n prominent account te raden en je ziet dat ook alle beweerdelijke extra maatregelen (zoals 2FA) er niet zijn. Wat mag je dan doen? Nou ja, het slachtoffer en/of de dienstverlener informeren natuurlijk, dat past volledig binnen de heersende spelregels voor ethische hackers.

Ermee naar buiten treden is een ander verhaal. Natuurlijk, bij responsible disclosure hoort ook een melding op zeker moment zodat het publiek ook weet wat er mis is. Maar dat is omdat het publiek getroffen kan zijn door het lek dat jij als ethisch hacker had ontdekt. Of omdat ze moeten weten dat die dienstverlener zat te prutsen. Bij een probleem als dit zie ik geen reden om met (responsible) disclosure te dreigen.

Wel is het natuurlijk zo dat het zeer groot nieuws is dat dit oppermachtige Twitteraccount zó slecht beveiligd is. Dan kun je prima naar de pers stappen en melden dat je dit nieuws ontdekt hebt. Ook als je het zelf hebt gemaakt, dat nieuws. Een journalistieke hack is niet hetzelfde als een ethische hack.

Arnoud

Moet je als jurist leren programmeren? #legaltechtuesday

Code as law. Met dat mantra is de toon gezet: steeds vaker speelt software en online dienstverlening een steeds belangrijker rol in de juridische praktijk. Software maakt beslissingen, software selecteert of wijst af. Of functioneert anderszins op onnavolgbare wijze. Ga er maar aan staan met een juridische analyse of claim: de mindset die hoort bij software en ICT ontwerpen, is een hele andere dan die hoort bij een aansprakelijkheidsstelling formuleren of een dagvaarding opstellen. Vandaar dat je steeds vaker leest dat advocaten en juristen moeten leren programmeren. Maar is dat wel echt zo nuttig?

Vooropgesteld: programmeren is gewoon leuk. Het is puzzelen, in logische volgorde instructies uitwerken en rekening houden met randgevallen waar niemand aan gedacht heeft. Wie wel eens een Lego Mindstorms robot heeft ingesteld, begrijpt meteen wat ik bedoel. (Zoekt u nog een Sint- of Kerstcadeau voor uw kind of neefje/nichtje?)

En het mooie is, programmeren lijkt ergens wel op contracteren of juridisch puzzelen. Want ook daar moeten logische stappen genomen worden, hindernissen geëlimineerd, randzaken ingeperkt en risico’s afgedekt. Dat het bij programmeren gaat om het risico dat een temperatuursensor 4000 graden aangeeft en bij contracteren dat een opdrachtnemer ziek wordt, dat is een inhoudelijk detail.

Toch zijn er ook wel verschillen. Juristen leren denken binnen het redelijke en billijke (art. 6:2 en 6:248 BW, bijvoorbeeld). Als een uitkomst al te bizar is, dan weet iedere jurist dat deze kan worden bijgesteld. Een boeteclausule die op zes ton uitkomt voor een overtreding van een half uur, dat wordt gegarandeerd gematigd. Bij de menselijke rechter inderdaad, want het contract komt op zes ton. En als je dit in software doet, dan komt daar ook gewoon spijkerhard zes ton uit. Computers zijn niet redelijk, zij rekenen alleen maar.

Deze verschillen maken dat het best interessant kan lijken om als jurist een cursus programmeren te doen. Als jurist en programmeur kan ik u vertellen: dat is ook zeker de moeite waard, alleen moet u wel vooraf bedenken wat u zou willen kunnen. Je hebt namelijk programmeren en programmeren: gaat het om het begrijpen van de basics, wilt u doorgronden hoe algoritmes (stappenplannen) opgebouwd worden en welke valkuilen daarbij komen kijken, wilt u een juridische dienst of app opzetten of iets anders? Dit zijn namelijk zeer verschillende cursussen.

Voor mij staat voorop dat de skill van het programmeren zelf niet zo heel belangrijk is. Programmeren is namelijk geen handeling op zich, zoals bijvoorbeeld schilderen of fotograferen. Het is een activiteit binnen een groter kader, namelijk applicatie- of dienstontwikkeling. Onderhoud en meegaan met nieuwe ontwikkelingen zijn essentieel. Tenzij je het dus houdt bij Mindstorms robots. Maar programmeren is niet iets dat je leert en daarna altijd onder je riem hebt; je moet het altijd bijhouden en opnieuw toepassen.

Wat je wél kunt leren van een korte cursus, zijn algemene skills en vaardigheden uit dit digitale domein. Een specifieke skill is bijvoorbeeld hoe je een groot algemeen probleem opdeelt in kleine blokjes, en daarna ieder deelprobleem oplost op een manier dat het aansluit bij het vorige en het volgende deelprobleem. Ook helpt programmeren u data beter te begrijpen – een waardevolle skill als u met zogenaamde artificial intelligence aan de slag gaat. Want u kunt wel om een verkeerde komma heen lezen in een dossier, uw robot paralegal slaat onverbiddelijk op hol van zo’n onnozele fout. Ook leert u door programmeren meer projectmatig denken, want software ontwerpen is te groot om even snel op een middag te doen.

Een alternatief dat steeds meer aan populariteit wint, is het zogeheten no-code programmeren. Hierbij hoeft de programmeur geen details van programmeertalen te kennen, maar heeft zhij een visuele interface waarmee dingen aan elkaar te knopen zijn. De computer heeft de benodigde programmeercode op de achtergrond paraat, maar valt u daar niet mee lastig.

Een heel simpel voorbeeld? Probeert u dan IFTTT (if this then dat) eens, een dienst waarmee u van alles aan elkaar kunt knopen. Van agenda’s tot e-mail tot Onenote of zelfs uw wasmachine, als die dat ondersteunt. Dat vereist enig logisch nadenken over wat u precies wilt, en vooral: omzetten naar specifieke, concrete instructies. Zo zou ik op warme dagen graag willen dat mijn zonwering op tijd dicht gaat. Vertalen naar instructies: Als de temperatuur om 13uur boven de 26 graden is, doe dan de zonwering omlaag. Tenzij in mijn agenda “afwezig” staat. Tenzij het regent. Tenzij … kijk, daar voelt u al een programmeur in uzelf omhoog komen.

Overweegt u programmeerervaring op te doen? Vraag u dan eerst af wat u eigenlijk zou willen bereiken. Koop een Mindstorms robot, puzzel met een no-code dienst zoals IFTTT en ga eens puzzelen wat uw eigen robot paralegal zou moeten doen. En beslis daarna.

Arnoud

Mag je contactgegevens via WhatsApp doorgeven of is dat ook al een AVG probleem?

Een lezer vroeg me:

Er zijn beperkingen bij het doorgeven van het e-mailadres aan derden. Maar contactgegevens doorgeven via WhatsApp is een standaard feature. Het zijn weliswaar geen e-mailadressen, maar kan dat volgens de wet zo maar?
Voor het doorgeven van e-mailadressen, 06-nummers en alle andere contactgegevens van personen (ook indien voor zakelijk contact) gelden gewoon dezelfde regels. Dat zijn immers allemaal persoonsgegevens onder de AVG.

Het maakt niet uit of je handmatig een 06-nummer in een e-mail plakt en deze zo doorgeeft, of dat je in de WhatsApp applicatie voor de optie “Contactpersoon toevoegen” kiest, een gegevenssetje kiest uit de lijst van je Android/Apple adresboek en deze in mooie layout laat verschijnen bij de ontvanger. In beide gevallen gebeurt hetzelfde: de contactgegevens komen bij de ontvanger.

Of dat mag, hangt allereerst af van of het delen onder de AVG valt. Die kent immers een uitzondering voor huishoudelijk of zuiver persoonlijk gebruik (artikel 2 lid 2c AVG). In principe geldt die alleen als je de gegevens voor jezelf houdt, maar in zeer beperkte kring delen kan vaak nog net. Als de buurvrouw mijn nummer aan de overbuurman geeft omdat die een afspraak wil om een pakketje bij me te halen, dan zie ik dat als buiten de AVG.

Als het onder de AVG valt heb je een grondslag nodig. Dat zal vaak toestemming zijn (“geef mijn nummer maar aan Jaap, hij mag me altijd appen voor een offerte”), maar dat is niet de enige. Uitvoering van een overeenkomst kan ook (“Jaap is mijn accountant, app hem maar over de jaarcijfers zodat we het contract kunnen finaliseren”). En wellicht kom je er ook met een eigen gerechtvaardigd belang (“Jaap vindt het vast fijn als Pieter hem appt hierover”).

Ik lees vaak dat men zegt, als je WhatsApp (of vergelijkbare applicatie) gebruikt dan ben je akkoord met de voorwaarden en dan mag iedereen je dus appen. Dat argument volg ik niet. Ten eerste staat dat niet in de voorwaarden van WhatsApp, en ten tweede kunnen die voorwaarden geen toestemming afdwingen voor levenslang gecontacteerd te worden door eender wie.

Het maakt dus niet uit hoe je iemands contactgegevens deelt. De kern is dat je het alleen moet doen als het netjes is om te doen.

Arnoud

Met één klik je privacyvoorkeuren juridisch bindend doorgeven, gaat dat ooit lukken?

Met de Global Privacy Control in je browser kun je straks met één muisklik instellen of je gevolgd en geprofileerd wil worden, las ik bij Ars Technica. Deze nieuwe optie, die echt niet hetzelfde is als de keihard gefaalde Do Not Track instelling in je browser (waarmee je met één muisklik kon instellen of je gevolgd en geprofileerd wilde worden), zou wel eens een heel groot dingetje kunnen gaan worden omdat zowel de GDPR als de Californische Consumer Privacy Act (CCPA) dergelijke instellingen juridisch bindend zouden verklaren. Vooralsnog zit de optie alleen in Brave en DuckDuckGo, Mozilla (van Firefox) houdt het bij een braaftaalpersverklaring en van Chrome is nog niets vernomen. Maar laten we optimistisch blijven en eens kijken hoe bindend dit is.

Beetje flauw natuurlijk om zo negatief over DNT te doen, want dat was een goed idee. Sowieso is het natuurlijk heel raar dat mensen gevraagd moeten worden of ze gevolgd en geprofileerd willen worden, want dat is geen beslissing waar je gewone mensen mee lastig moet willen vallen. Dat is gedrag dat we ofwel maatschappelijk aanvaardbaar vinden of niet, en dan verbied je het dus – of niet. En nee, het is geen kwestie van uitleggen of verwachten dat mensen de tijd nemen dit te begrijpen.

Maar goed, als het dan kennelijk gevraagd moet worden dan lijkt me een instelling in de browser heel wat beter dan iedere website zijn eigen supertrage popup met misleidende “eigen instellingen”-knop. Dat was ook waar DNT voor bedoeld was, en wat GPC ook moet gaan doen. DNT werd echter rijkelijk vroeg (2009) voorgesteld, en sneuvelde een stille dood omdat bedrijven geen zin hadden het te ondersteunen.

GPC zou een succes moeten worden omdat het wordt gepresenteerd als de implementatie van de GDPR en de Californische tegenhanger CCPA. Beiden kennen immers een juridisch kader voor toestemming geven (en intrekken) en wat daarbij komt kijken, dus als je GPC nu zo bouwt dat het een GDPR-compliant toestemming of intrekking geeft, dan moet je als bedrijf daar wat mee. Zou je zeggen, want de belangen zijn zo groot dat ik 100% verwacht dat advertentiebedrijven smoesjes zullen blijven verzinnen waarom je de AVG toch echt anders moet lezen.

In Californië pakken ze het harder aan. In een uitvoeringsregeling gekoppeld aan de CCPA staat expliciet dat bedrijven moeten luisteren naar browsergeconfigureerde toestemming:

The CCPA includes a mechanism for solving the one-by-one problem. The regulations interpreting the law specify that businesses must respect a “global privacy control” sent by a browser or device. The idea is that instead of having to change privacy settings every time you visit a new site or use a new app, you could set your preference once, on your phone or in a browser extension, and be done with it.
De AVG kent zo’n uitvoeringsregeling niet, en het is ook niet echt de Europese stijl van wetgeving dat we keihard opschrijven dat een bepaalde instelling of knop de wettelijke manier is om iets voor elkaar te krijgen. Wel zou de EDPB (de samenwerkende toezichthouders) een richtsnoer kunnen publiceren (artikel 70 AVG) waarin zonder veel mitsen en maren staat dat GPC rechtsgeldige toestemming (of weigering daarvan) oplevert en dat een bedrijf niet mag eisen dat je de eigen interface gebruikt. Een richtsnoer is geen wet maar je moet van goede huize komen wil je er zomaar van af kunnen wijken.

Uiteindelijk staat of valt dit natuurlijk met de handhaving. Zolang er geen concrete en directe prikkel is om je site aan te passen, zal GPC net zo hard sneuvelen als DNT. Maar ik begrijp niet waarom dit allemaal zo lang moet duren; we weten wat de eisen voor toestemming zijn en hoe dit kan worden gehandhaafd.

Arnoud