Enorme taalmodellen moeten worden getraind met enorme datasets. Om die te verzamelen wordt op geen bron meer of minder gekeken: The Pile, zowat de grootste dataset van Engelstalige tekst die vandaag bestaat, tikt ongeveer 825 GB aan. De volledige Engelstalige Wikipedia maakt er deel van uit, voor 6.3 GB, oftewel 0.7% van de collectie. Andere databronnen zijn CommonCrawl , OpenWebText , maar er worden ook tekstfragmenten gebruikt afkomstig van Github, ArXiv, PubMed, StackExchange, OpenSubtitles, zelfs het Europees Parlement.

Veel van die datasets zijn met eenvoudige webscraping scripts verzameld. Of dat allemaal wel mag volgens copyright- en privacywetgevingen allerhande, is een ingewikkelde vraag met een nog ingewikkelder antwoord en dus maakt men daar voor het gemak in eerste instantie vaak abstractie van. Kwaliteitschecks en fijnmazige filters zijn tijdrovend als je ze accuraat wil maken, en in de wedloop om het grootste taalmodel sneuvelen die dus helaas ook maar al te vaak.

Gegeven de enorme verscheidenheid aan bronnen, websites, tekstformatteringen en dataverzamelingsmethodes, is het zo haast onvermijdelijk geworden dat in datasets van die grootteorde toch nog persoonsgegevens of auteursrechtelijk beschermde teksten terechtkomen – zelfs als men moeite doet om enigszins correct te handelen. Reden genoeg om zelf eens in zo’n dataset te duiken en te kijken wat we daarin terugvinden.

OSCAR

OSCAR is een meertalige dataset die regelmatig wordt gebruikt voor niet-Engelstalige taalmodellen. De Nederlandstalige subset ervan kan dienen als basis van een Nederlandstalige tekstgenerator. OSCAR is op zijn beurt afgeleid van CommonCrawl, een grootschalige dataset van scraped websites, waarvan de makers wel aangeven dat robots.txt en HTML no-follow specificaties gehonoreerd werden, maar waar verder weinig meer mee gebeurd is dan gegevensopslag. OSCAR groepeert die per taal, voegt wat extra preprocessing toe, en zet de tekstfragmenten in willekeurige volgorde, om zo copyrightproblemen te vermijden. We doen hier geen uitspraak over de vraag of dat wel voldoende is voor dat doel. Een bijkomend effect daarvan is wel dat de inhoudelijke relatie tussen opeenvolgende tekstfragmenten in deze dataset dus verloren is gegaan. (De laatste paper van de auteurs probeert daar alsnog een mouw aan te passen.)

We bekijken de Nederlandstalige gegevens uit de eerste versie van deze dataset uit 2019 (toegang tot versie 2021 of versie 2022 vereisen registratie of aanvraag). Deze is vrij beschikbaar in de dataset repository van Huggingface, dat ook een eerste preview van de inhoud voorziet. Bij Huggingface vermeldt men summier dat de dataset persoonlijke of gevoelige informatie kan bevatten, en dat de training van een AI-model op basis van deze dataset gevoelig kan zijn voor biases, zonder dieper in te gaan op deze problematiek. De verantwoordelijkheid hiervoor wordt bij de gebruiker van de dataset gelegd.

De Nederlandstalige subset van OSCAR bestaat uit 126.064.721 tekstfragmenten van één tot enkele zinnen lang, die we kunnen samengevoegen tot 1 tekstbestand met een grootte van ongeveer 40GB. In wat volgt doorzoeken we deze dataset naar gegevens die als persoonlijk of gevoelig beschouwd zouden kunnen worden. Het valt aan te nemen dat die gegevens grotendeels zijn gescrapet zonder medeweten van de originele auteurs of van de websites waarop ze oorspronkelijk gepubliceerd waren. We tonen telkens een selectie van wat we zoal terugvinden ter illustratie, maar om de mogelijke privacy- en copyrightproblemen niet erger te maken dan ze al zouden kunnen zijn, maskeren we in dit artikel de gevonden gevoelige gegevens alsnog en markeren we ze rood.

Gevoelige gegevens in OSCAR

Door gewoon reguliere expressies toe te passen, die je vaak kan copy-pasten van het internet, kunnen we al veel boven water halen. Om emailadressen te detecteren, gebruiken we een relatief eenvoudig patroon, waarmee we 685.968 potentiële matches terugvinden (let wel dat veel algemene emailadressen, bijvoorbeeld van helpdesks of infolijnen of grote organisaties, herhaaldelijk voorkomen):

grep -a -e "[a-zA-Z0-9._]\+@[a-zA-Z]\+.[a-zA-Z]\+" oscar_nl_full.txt

• Ik gooide enkele nieuwe data online! Wie zin heeft kan zich inschrijven door te mailen naar e*******s@gmail.com
• Ontdek hoe je een WordPress thema vindt dat echt bij jou past! www.speciaalgeselecteerd.nl jouw gids voor WordPress thema s Door: S******* v** N******** Datum: 1-1-2016 E-mail: s********@innonet.nl WordPress
• De hoofdleiding bestaat uit D***** V******, G***** G*******, M**** W****** en F***** V*** B*****, hen kan je contacteren via 0497****** (D*****), 0493****** (G*****), 0477****** (M****) en 0498****** (F*****). Een mailtje naar i***@c*********.be is ook altijd mogelijk. Zij zullen jullie graag helpen met vragen, opmerkingen of klachten.

Veel emailadressen lijken afkomstig van contactpagina’s op websites van bedrijven, organisaties, maar je herkent ook overduidelijk verenigingen, lokale initiatieven, jeugdbewegingen, en forumgebruikers die hun persoonlijke contactgegevens achterlaten, waaronder telefoonnummers. Het volgende patroon zoekt naar cijfercombinaties die eruit zien als een Belgisch telefoonnummer, in de meest voorkomende schrijfwijzen. (Het patroon is iets te algemeen opgesteld, met als nadeel dat we er ook onderdelen van niet-telefoonnummers mee vinden.) Dat leidt alleszins al tot 289.461 potentiële matches:

grep -a -P "(((\+|00)32[ ]?(?:\(0\)[ ]?)?)|0){1}(4(60|[789]\d)\/?(\s?\d{2}\.?){2}(\s?\d{2})|(\d\/?\s?\d{3}|\d{2}\/?\s?\d{2})(\.?\s?\d{2}){2})" oscar_nl_full.txt 

• Tijdens de openingstijden kan je via de Live Chat of via de telefoon 07******** vragen stellen aan één van onze medewerkers.
• […] Heeft u vragen over onze werkwijze, prijzen of materialen dan zijn we bereikbaar op de nummers 03/***.**.** en 03/***.**.**. Ook kunt u een e-mail sturen naar [email protected] of het contactformulier invullen.
• Op 22 september vertrekken we op speel-weekend naar Ronse. Wil je nog mee? Als de bliksem bellen naar R******* 0496/**.**.**
• Propere betonnen palen 8 stuks, geen beton/cement aan de onderkant van de paal- lengte 2.05m. Bieden vanaf €7/stuk. Tel 0478/******

Ook hier vinden we veel contactgegevens van bedrijven, maar een aanzienlijk deel zijn ook persoonlijke telefoonnummers afkomstig van berichten die mensen postten op online marktplaatsen of zoekertjeswebsites. Bankrekeningnummers, BTW-nummers e.d. duiken ook op tussen de gevonden data. Om te blijven focussen op persoonsgerelateerde data, gaan we nog op zoek naar Twitter of Instagram handles. Deze kunnen bijvoorbeeld afkomstig zijn van conversaties op Twitter en Instagram zelf, van internetfora waar mensen erover spreken, of van de footers van webpagina’s met links naar sociale media. Afgezien van enkele bedrijven wiens naam of product met een @ begint, gaan achter de meeste gevonden handles echte, actieve mensen of organisaties schuil. We vinden zo 131.364 potentiële matches:

grep -a -e " @[a-zA-Z0-9]\+" oscar_nl_full.txt

• Vandaag waren we op bezoek bij Leo Timmers, maker van Een huis voor Harry, het Prentenboek van het Jaar 2019! En we gingen Billy ontmoeten, de kat waar Harry op geïnspireerd is. Ik had dus de dag van m’n leven. @v*********** #cat #books #brussels #reading #catsofbrussels #eenhuisvoorharry 
• […] R***** twitterde dit naar mij en @p********, afgelopen zondagmiddag. We hadden het over de blogs die Ruud had willen schrijven die dag: drie stuks maar liefst. De blogs kwamen er inderdaad niet. Nooit meer. R***** overleed maandagavond [datum]. Ik heb een goede vriend verloren.
• Zeg @******** wat willen jullie nou in de omgangsvorm: ‘u’ of ‘je’? Maak een keuze! https://t.co/********
• @******** En niet alleen dat. Het kenteken *-***-** staat mooi op beeld. Kijk dus uit voor deze asociale weggebruiker, mede-weggebruikers. @ [datum]

Er duikt duidelijk een heel palet aan persoonsgebonden informatie in deze dataset op, zoals ook nummerplaten, berichten over ziekte of overlijden, politieke voorkeuren, informatie over wanneer personen waar geweest zijn, en nog heel wat meer. Met hetzelfde gemak vinden we ook beledigingen tegen personen terug, verwensingen allerhande, racistische fragmenten, … we kunnen alleszins heel lang bezig blijven als we hierop enige grip willen krijgen in zo’n dataset.

Een heel ander gevoelig onderwerp is erotische inhoud. Er zijn alvast 2.459.800 matches voor woorden die beginnen met “seks” of “sex” in dit eerste deeltje van de dataset. Voorbeelden daarvan geven we terwille van de goede smaak niet mee, maar u mag de auteur op zijn woord geloven dat de meeste gevonden tekstfragmenten niet van droog-wetenschappelijke papers of schoolse seksuele opvoeding afkomstig zijn. Op een totaal van 126 miljoen zinnen, kunnen we zo schatten dat zulke inhoud ongeveer 2% van het totaal uitmaakt in deze dataset. 

Kom ik er in voor?

Dat kunnen we gemakkelijk achterhalen:

grep -a -e "Joachim Ganseman" oscar_nl_full.txt  

• De 27e Internationale Olympiade Informatica vond plaats in Almaty, Kazachstan. De Belgische ploeg werd gevormd door Damien Galant (5e middelbaar), Robin Jadoul, Mattéo Couplet en Nico Ekkart (allen 6e middelbaar). Zij werden begeleid door Damien Leroy en Joachim Ganseman. […]
• […] De bouwstenen voor artificiële intelligentie (AI) liggen klaar, maar ze staan op los zand. Dhr. Joachim Ganseman van Smals Research bestudeerde de zwaktes van AI. In zijn artikel op de Research-blog bespreekt hij een aantal uitdagingen voor de toekomst.
• Joachim Ganseman wordt onderscheiden voor de ijver waarmee hij als jonge doctoraatsstudent de Belgische informatica-olympiade heeft gesticht, coördineert en communiceert in beide landshelften, met bijzondere inspanningen voor de toegankelijkheid voor alle leerlingen, ongeacht voorkennis.

In 7 tekstfragmenten komt mijn volledige naam voor, voornamelijk in verband met mijn engagement bij de Belgische Informatica-olympiade van 2011 tot 2018. Geen info die iets schandaligs of schaamtelijks bevat, integendeel, maar ik was niet op de hoogte. Als je ooit met naam en toenaam in de krant of op een website van een grotere organisatie hebt gestaan, lijkt de kans alleszins groot dat je naam in dat verband ook in de OSCAR dataset voorkomt. Het blijft dus erg belangrijk om in het achterhoofd te houden dat dat wat eenmaal op het internet staat, er erg moeilijk terug af gaat.

Misschien kan het een goed idee zijn om, naar analogie van Have I Been Pwned die je waarschuwt voor paswoordlekken, een gelijkaardige dienst te hebben bij dataset repositories waarmee gebruikers kunnen checken of hun persoonlijke informatie voorkomt in datasets? Tijd en middelen ontbreken om zoiets zelf verder uit te werken, maar we laten het hier staan als een interessante suggestie.

En dan?

We moeten nog vermelden dat de makers van de CommonCrawl en OSCAR datasets zelf niet Nederlandstalig zijn. Zij hebben dan ook niet onmiddellijk manieren ter beschikking om de verzamelde fragmenten in het Nederlands (en in de meeste van de andere 165 talen in OSCAR) op hun inhoudelijke merites te gaan beoordelen, en presenteren deze datasets “as is”.

Gegeven het feit dat persoonsgebonden gegevens gemakkelijk te vinden zijn op het internet voor wie een beetje zoekt – en zeker op sociale media of op marktplaatsen waar ze gretig uitgewisseld worden – is het niet verwonderlijk dat deze gegevens ook terechtkomen in datasets verzameld via webscraping, als er een breed net wordt uitgegooid en weinig wordt gefilterd.

Smals Research is een technisch team zonder juristen in haar rangen; we laten uitspraken over het wettelijke kader rond webscraping, auteursrechten, en de gebruiksvoorwaarden van websites, in een internationale context, dan ook liever over aan mensen die daar meer van kennen dan wij. Het is in onze sector wel algemeen bekend dat de persoonsgegevens van EU-ingezetenen beschermd worden door de GDPR. Dat houdt onder andere in dat zij de inzage en verwijdering van hun gegevens moeten kunnen vragen, en informatie moet kunnen krijgen over het gebruik ervan. Het wordt natuurlijk moeilijk om dat recht effectief uit te oefenen, als gegevens op elk moment in een externe database kunnen worden overgenomen, zonder medeweten van die persoon of zelfs van de website waarop ze gepubliceerd waren.

Wie van zulke datasets gebruik maakt om AI systemen te trainen, is technisch gesproken de daarin begrepen persoonsgegevens aan het verwerken, en lijkt zo alvast automatisch een verantwoordelijkheid te hebben ten aanzien van die betreffende personen. Het is daarnaast niet ondenkbaar dat een verkeerd of slecht getraind AI-systeem deze gegevens expliciet opneemt in het resulterend model, en ze aanwendt om bepaalde beslissingen te nemen, wat een risico op bias met zich meebrengt. Tot slot weet je nooit of er ergens een slecht beveiligde website gescrapet werd door de dataset-maker, waardoor er misschien login-gegevens of paswoorden voorkomen in de dataset.

Een alternatieve werkwijze

De onderzoeksgroep Computationele Linguïstiek van de Universiteit van Groningen bouwde een eigen variant van een Nederlandstalig GPT-2 model. Zij zijn natuurlijk wél Nederlandstalig, en waren ook selectiever in het kiezen van hun trainingsdata. In hun paper lezen we dat die bestaat uit de Nederlandstalige Wikipedia (2.0GB), een grote hoeveelheid E-books (6.5GB), een dataset van nieuwsartikels die weliswaar nog van 2007 dateert (2.9GB) aangevuld met artikels van andere nieuwswebsites (2.1GB). Na het wegfilteren van duplicaten is dat goed voor een trainingsdataset van 13GB aan Nederlandstalige tekst. Gegeven deze bronnen is het aannemelijk dat hun dataset alvast correcter geschreven Nederlands bevat van een inhoudelijk hogere standaard.

De eigenlijke dataset vonden we na een korte zoektocht niet onmiddellijk terug, dus het is moeilijk de inhoud verder te bekijken – wie weet waar ze ergens beschikbaar zou zijn, mag het steeds laten weten. Het valt alleszins te verwachten dat de inhoud van deze dataset minder problematisch zal zijn op het vlak van persoonlijke gegevens dan OSCAR. Langs de andere kant stelt zich, met een dataset afkomstig van krantenartikels en e-books, misschien wel nog een copyrightprobleem.

Kieskeurig zijn qua trainingsdata heeft weliswaar een keerzijde. Een generatief taalmodel getraind op een selecte dataset is gelimiteerder qua teksten die het kan produceren. Tekstfragmenten die lijken op sociale-media-posts zullen moeilijk gegenereerd kunnen worden door een model dat niet getraind werd op data afkomstig van sociale media, en een hoge aandeel e-books leidt ook tot prozaïscher teksten. Tot slot maakt het groot aandeel van oudere nieuwsartikels ook dat het getrainde model teksten “uit die tijd” zal produceren, en relatief minder woordenschat en zinswendingen kent over recente trends, technologische uitvindingen of politieke ontwikkelingen.

Conclusie

We hebben hier slechts één Nederlandstalige dataset onder de loep genomen, maar het spreekt voor zich dat dezelfde problemen zich stellen in gelijkaardige datasets voor andere talen.

Het valt op dat enkele eenvoudige filters, bijvoorbeeld om emailadressen, rekeningnummers, persoonlijke profielinformatie of andere persoonsgegevens te detecteren, al een heel deel van deze problematische inhoud zouden kunnen wegfilteren. Een sluitende garantie geven dat er niets fouts meer voorkomt is haast onmogelijk in datasets van deze grootteorde, maar hier hebben we toch kunnen illustreren dat er soms wel érg weinig moeite gedaan lijkt te zijn om de datasets een beetje op te schonen. 

Propere datasets maken, deze inhoudelijk onderzoeken en daarbij in de diepte graven, kost natuurlijk tijd en moeite – enkel om problematische stukjes weg te vijlen die in hun geheel maar een klein deeltje uitmaken van de hele dataset, wat dus waarschijnlijk ook maar een kleine impact zou hebben op het daaruit resulterende taalmodel. Het is moeilijk hard te maken dat zulk monnikenwerk zich economisch terugverdient, en garanties dat je effectief alles verwijdert zijn er evenmin.

Toch is het belangrijk dat er voldoende aandacht geschonken wordt aan de kwaliteit van de onderliggende datasets. Als dat niet werkbaar is vanwege hun grootte, moet je je minstens een idee vormen van de impact van mogelijke onregelmatigheden erin. Een data protection impact assessment is net daarvoor bedoeld, en is in sommige gevallen verplicht.

Het blind hergebruiken van een dataset die je zelf niet hebt samengesteld, is een slecht idee. Dat geldt bij uitbreiding eigenlijk ook voor het indirect gebruik ervan via een derde partij of een externe software-library. Dit is overigens een algemeen advies dat geldt voor elke toepassing van machine learning. Wie beter wil doen en ethiek wat hoger in het vaandel wil dragen, vindt goede startpunten in de paper Datasheets for Datasets en bij initiatieven zoals AI Now.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Als het doel is om een functioneel alternatief te voorzien voor gevoelige data, zijn tools voor de creatie van synthetische data bij uitstek geschikt. Ze kunnen immers meer dan enkel de bestaande gegevens door elkaar gooien: ze zijn gemaakt om de structuur van gegevens aan te leren, waarna je willekeurig veel nieuwe gegevens volgens dezelfde structuur kan aanmaken. In combinatie met generatoren voor totaal fictieve gegevens, hebben we daarmee alles voorhanden om niet alleen de originele gegevens te verbergen, maar ook om te zorgen dat wat in de plaats komt, realistisch oogt.

Dat betekent echter niet dat het een kwestie is van een druk op de knop. Eén en ander hangt af van allerlei randvoorwaarden en aannames over de inhoud en structuur van de gegevens. Afhankelijk van de beoogde toepassing of het doel, kan het nodig zijn om extra beperkingen en filters op te leggen, of misschien net om bepaalde delen van de gegevens buiten beschouwing te laten. In dit artikel kijken we vooral naar die praktische bekommernissen: wat kom je zoal tegen als data professional die synthetische data moet aanmaken?

Setup

Wie een dataset wil scramblen, heeft uiteraard toegang nodig tot de originele gegevens. Het spreekt voor zich dat het uploaden van gevoelige data naar een cloud service of zelfs het gebruik van een Docker container voorzien door een derde partij, slechts mogelijk is als er grondig is nagedacht over GDPR-compliance, eventueel een Data Protection Impact Assessments (DPIA) is opgesteld, en best ook met de DPO is overlegd. We doen zelf geen enkele uitspraak over de geschiktheid van eender welke tool vis-à-vis de GDPR-wetgeving. Voor al wat volgt gaan we ervan uit dat we werken met tabulaire, tekstuele of numerieke gegevens, die lokaal beschikbaar zijn – met andere woorden, een grote spreadsheet.

De markt

In een vorig artikel vermeldden we al enkele spelers vanuit de optiek van AI-projecten en software testing. Hier ligt onze focus meer op de privacybescherming en data science. Voor het analyseren en synthetiseren van tabulaire gegevens is er een heel sterk groeiende markt. Enkele interessante spelers zijn de volgende – en er zijn er ongetwijfeld nog veel meer:

• Mostly.ai
• YData
• Tonic
• Gretel
• Synthesized.io

Open source tools zijn er minder en zijn vaak afkomstig van projecten die op universiteiten zijn begonnen. Benerator vermelden we apart omdat deze al langer bestaat en ook een uitgebreid commercieel aanbod heeft. Jongere open source initiatieven zijn onder andere:

• Synthetic Data Vault (SDV)
• Mimesis
• Synthia
• Data Responsibly‘s DataSynthesizer
• MITRE’s Synthea / SyntheticMass (toegespitst op eHealth)

SDV is momenteel de populairste van de open source tools, en we gebruiken deze voor al wat volgt. In onze Quick Review vind je meer uitleg over deze tool.

Het stappenplan

Het plan van aanpak om synthetische data te produceren is bij de meeste tools heel gelijkaardig. We kunnen het onderverdelen in 6 grote stappen:

1. Upload en inlezen van de gegevens. Met name de tekst-encodering kan hier wel eens voor problemen zorgen als de gegevens uit oudere bronnen afkomstig zijn. Problemen hiermee moeten opgelost worden voordat men aan de volgende stappen begint.
2. Analyse en typering van de gegevens. Voor elke kolom: welke zijn de minima, maxima, de waarden die voorkomen, zijn er missende waarden, etc. Omdat de computer niet weet wat de achterliggende betekenis van de gegevens is, is het vaak nodig om in deze stap manueel correcties uit te voeren:
   • Niet alle getalwaarden kan je zomaar beschouwen als “hoeveelheden” die je vrij kan optellen of aftrekken. Sommige zijn categoriën, zoals NACE codes of postcodes, andere zijn misschien onderdeel van een datum.
   • Ontbrekende gegevens zal je in sommige gevallen kunnen gelijkstellen met 0 of met een reeds aanwezige default categorie, maar vaak wil je ze misschien beschouwen als een klasse apart. Een ontbrekende geboortedatum wilt immers niet zeggen dat iemand geboren is in het jaar 0.
3. Transformatie van gegevens. Hierbij worden o.a. ontbrekende gegevens afgesplitst, of categorische variabelen omgezet in een getal-encodering om compacter voorgesteld te worden. Deze stap gebeurt vooral achter de schermen, maar het is vaak mogelijk om manueel configuratie-opties toe te voegen: van sommige kolommen willen we bijvoorbeeld forceren dat de waarden altijd uniek zijn, andere kolommen willen we misschien negeren.
4. Een generatief model trainen. Dit kunnen zowel “klassieke” statistische modellen zijn als deep-learning varianten. Sommige modellen zijn enigszins in staat om diepere verbanden tussen de gegevens te reproduceren, maar dit blijft erg afhankelijk van de hoeveelheid gegevens en hun distributie.
5. Genereren van nieuwe gegevens. Bij gebruik van een generatief model staat er in principe geen limiet op de hoeveelheid gegevens die aangemaakt kan worden.
6. Evalueren en visualiseren van de resultaten. De meeste commerciële tools genereren een mooi eindrapport met daarin een verslag van het hele proces en enkele samenvattende grafieken die toelaten om in een oogopslag te zien of er anomalieën zijn, en of er nog andere correcties toegevoegd dienen te worden. Bij open-source tools is dat vaak beperkt tot enkele metrieken en moet je verdere gegevensanalyse zelf bijprogrammeren.

Gegevens

Wie de tools liefst niet uittest op eigen (gevoelige) data, vindt veel datasets op Kaggle. Zelf maakten we voor onze testen onder andere gebruik van een variant op de Adult Census Income dataset.

Praktische bekommernissen

Telgegevens

Sommige datasets bevatten tellingen. Dat kan het resultaat zijn van een COUNT() functie in de SQL-query voor data-extractie. Om dan een correcte inschatting te kunnen maken van de distributies van de andere variabelen, is het nodig om deze telling ongedaan te maken en de tabel te “unrollen”. Een nieuw gegenereerde tabel moet nadien natuurlijk terug “opgeteld” worden om terug in het originele formaat te staan. Op deze manier kan men desgewenst ook garanderen dat de resulterende tabel ook effectief hetzelfde aantal records voorstelt als in de originele database, zelfs al is er een ander aantal combinaties van variabelen. De kolom met de telvariabele wordt uiteraard niet meegenomen in het generatief model.

Behoud van alle mogelijkheden

Voor sommige toepassingen kan het nodig zijn dat een gesynthetiseerde dataset zeker ook alle mogelijke waarden bevat die voorkomen in de originele dataset – bij wijze van representativiteit voor de originele dataset. Maar met name als bepaalde waarden erg zeldzaam zijn, bestaat er een reëel risico dat ze niet genoeg doorwegen bij de training van het generatief model, waardoor ze achteraf bijna nooit gegenereerd worden. De meeste generatieve modellen laten het conditioneel samplen van gegevens toe: datapunten kunnen gegenereerd worden waarvoor de waarde van een of meerdere variabelen vaststaan. De distributie van de andere waarden volgt dan een conditionele distributie, gegeven deze vaste waarden. Doe dat voor elke waarde die voorkomt in de originele dataset, en men kan garanderen dat elke waarde (alleszins onafhankelijk) voorkomt. Dit vraagt weliswaar wat extra programmeerwerk om gedaan te krijgen, en bovendien impliceert dit ook dat een outputdataset een bepaalde minimumgrootte zal hebben.

Duplicaten en overlap

Het genereren van nieuwe gegevens gebeurt door te samplen uit een generatief model – te vergelijken met het trekken van een lottocombinatie. Zeker als er veel gegevens worden gesynthetiseerd, is het altijd mogelijk dat er twee keer hetzelfde tussenzit. Is dat ongewenst, dan moet een optie toegevoegd worden om duplicaten te verwijderen – en nadien opnieuw gegevens bij te genereren totdat de gewenste grootte opnieuw is bereikt. Eventueel kan men ook forceren dat gesynthetiseerde gegevens zeker niet mogen voorkomen in de originele dataset – dat de twee datasets dus volledig disjunct zijn. Dat laatste voegt echter weinig toe qua privacybescherming: zonder kennis van de originele dataset, kan men steeds bogen op een zekere plausible deniability dat een synthetisch record identiek zou zijn aan een record uit de echte dataset.

Trainingstijd

Zeker bij grote datasets met veel variabelen, en bij gebruik van deep learning tools kan het een lange tijd in beslag nemen om een generatief model te trainen. Dat maakt het moeilijk om iteratief te werk te gaan bij het verfijnen van de opties. Het kan nuttig zijn om tijdens de ontwikkeling, de dataset ten grondslag van de training te beperken tot enkele duizenden willekeurig geselecteerde records. Daarbij mogen we al wat hierboven al werd vermeld natuurlijk niet uit het oog verliezen – bijvoorbeeld, ook hier kan het nuttig zijn om een extra optie te hebben die garandeert dat een selectie uit de trainingset nog steeds minstens 1 datapunt bevat voor elke waarde van elke variabele.

Afhankelijke kolommen

Een kolom die volledig (lineair) afhankelijk is van een of meerdere andere kolommen, moeten we verwijderen en achteraf terug herberekenen. Dat is typisch het geval bij wiskundige afhankelijkheden: een kolom die een som is van twee andere kolommen, of een percentage van een andere kolom voorstelt. We kunnen best niet hopen dat een generatief model dat verband zelf aanleert. Het is veel zekerder om zulke afhankelijke kolommen gewoon te verwijderen uit de dataset, en nadat een nieuwe dataset is gegenereerd, deze kolommen terug te berekenen op basis van de gesynthetiseerde data en dan pas toe te voegen.

Constraints

Iemands geboortedatum valt altijd vroeger dan iemands sterfdatum. Dat is logisch, maar als men voor een fictief persoon een nieuwe geboortedatum en sterfdatum genereert uit het generatief model dat werd getraind op de distributies van alle geboorte- en sterfdata in een dataset, dan kan het voorvallen dat deze logische beperking niet altijd gerespecteerd blijft. Het kunnen opleggen van constraints – de ene variabele is altijd groter of kleiner dan een andere, of altijd positief of negatief, etc. – is een belangrijke feature. Eenvoudige beperkingen, zoals zonet aangehaald, zijn eventueel nog eenvoudig te implementeren door “rejection sampling”: voldoet een gesynthetiseerd record niet aan alle constraints, wordt het gedeleted en wordt een nieuw gegenereerd, totdat alle records voldoen. Worden de constraints ingewikkelder of strikter, dan kan het nodig zijn om zelf de nodige filters te programmeren, of om een post-processing stap te definiëren waarin correcties uitgevoerd kunnen worden.

Kolommen bevriezen

Willen we een dataset scramblen met een kolom geslacht en een kolom woonplaats, dan is het eigenlijk voldoende om enkel de kolom met woonplaatsen door elkaar te husselen om een goed gemengde dataset te bekomen. Het geslacht is daar onafhankelijk van, en kunnen we even goed negeren. Het bevriezen van kolommen, in feite gewoon het verwijderen voor de verwerking en terug eraan plakken na het einde, kan zo een grote tijdswinst opleveren. Het is weeral een kolom minder waarvan de distributie aangeleerd moet worden. 

Kolommen bevriezen, impliceert weliswaar een voorwaarde: ofwel dat de gesynthetiseerde dataset even lang moet zijn als de originele zodat de dimensies overeenkomen, ofwel dat de gegevens in de bevroren kolom(men) helemaal willekeurig verdeeld zijn, dus op geen enkele manier gesorteerd of gegroepeerd, zodat de bevroren kolom(men) zonder effect op de gegevensdistributie kunnen verkort of verlengd worden. Dat laatste kan echter moeilijk te bewijzen zijn.

Maar zeker als het de bedoeling is dat een gesynthetiseerde dataset even groot is als de originele, wat toch vaak voorkomt, is het een enorm grote tijdswinst als van een dataset met 60 kolommen, er slechts 6 moeten gesynthetiseerd worden om een voldoende gescramblede dataset te krijgen. Bovendien zal een generatief model met minder kolommen meestal ook accurater getraind kunnen worden, dus is het resultaat waarschijnlijk zelfs kwalitatief beter. Eventueel kan de synthetische dataset achteraf nog eens geshuffled worden om enige overgebleven structurele gelijkenis met de originele dataset te verbergen. 

Rapportering en grafieken

De gescramblede dataset moet nog vergeleken worden met het origineel, om te verifiëren dat de procedure wel goed verlopen is en of er bepaalde parameters beter aangepast zouden kunnen worden. Het visualiseren van datasets is een uitdaging op zich, waarbij rekening moet worden gehouden met het type van variabele en de waarden die ze kan aannemen. Boxplots zijn vaak een goede keuze voor continue variabelen, en staafdiagrammen voor categorische variabelen. Daarbij moet aandacht worden besteed aan de assen, die overeen moeten komen om in een oogopslag te kunnen vergelijken. Het kan nodig zijn hier en daar extra te groeperen of aggregeren om grafieken van complexe categorische variabelen overzichtelijk te houden. Voor de verbanden tussen twee variabelen kan men verschillende vormen van bivariate plots, heatmaps en correlatiematrices benutten. Werkt men in Python dan zijn matplotlib en seaborn nuttige grafische libraries.

Conclusie

Met synthetische data generatoren hebben we een krachtige tool in handen om data scrambling te kunnen doen. We kunnen er bovendien meer mee dan enkel de gegevens door elkaar haspelen: desgewenst interpoleren ze ook tussen minimum- en maximumwaarden, of tussen datums, en zo kunnen ze ook fictieve gegevens genereren volgens dezelfde structuur als de originele dataset. Het aanmaken van een echt goede synthetische dataset vergt vaak een iteratieve aanpak, om het achterliggend generatief model te finetunen.

We merken in de praktijk dat er heel wat extra checks en balances komen kijken bij het werken met echte datasets. Het is zelden zo dat een generatief model gegenereerd uit een willekeurige dataset met default parameters, vanaf de eerste keer optimaal is. Met name erg ongelijke distributies zorgen voor problemen in het leerproces en voor statistische instabiliteit in het resulterende generatief model. Bij wijze van voorbeeld: als een dataset slechts 1 persoon bevat met een zeldzame ziekte, en het is toevallig een 43-jarige Limburger, dan riskeren we dat het systeem leert dat alle personen met deze ziekte per definitie 43-jarige Limburgers moeten zijn. Bovendien merken we dat we de beste resultaten bekomen als een dataset weinig variabelen heeft, en voor elke waarde van elke variabele veel datapunten (rijen, samples). Dit alles maakt dat we de beste resultaten vaak bekomen door zoveel mogelijk kolommen te bevriezen, en het aantal te scramblen kolommen te beperken tot het minimum noodzakelijke om het doel van scrambling te bereiken. Die oefening kan voor elke dataset anders zijn.

Een vraag die regelmatig terugkomt is: kunnen we dezelfde analytics op de dusdanig gescramblede / gesynthetiseerde dataset loslaten en leidt dat dan tot dezelfde conclusies? Het antwoord is: het hangt ervan af hoe diep je wilt gaan. De structuur van de gegevens wordt in het generatief model immers approximatief aangeleerd. Daarbij merken we:

• De statistieken en verdeling van individuele variabelen (minimum, maximum, gemiddelde etc.) blijven meestal relatief goed behouden,
• De verbanden tussen twee variabelen (correlatie etc.) blijven matig behouden, en hoe gelijkmatiger en stabieler deze variabelen zijn verdeeld hoe beter dat dat lukt,
• De verbanden tussen meerdere variabelen (regressies etc.) blijven relatief slecht behouden of gaan verloren.

Voor complexe analyses zijn scrambled of synthetische data dus zeker geen drop-in replacement voor de echte data. Ze zijn wel erg nuttig voor het testen of ontwikkelen van data processing scripts of analyse-pipelines, omdat we wel een goed beeld hebben van welke waarden er allemaal voorkomen en in welk bereik deze vallen.

We hebben nog heel wat andere potentiële struikelblokken die we in de praktijk kunnen tegenkomen niet besproken. Er kunnen afhankelijkheden bestaan tussen rijen – bijvoorbeeld, een tabel die verschillende records bevat per persoon. Er kunnen ook verbanden zijn in de tijd – bijvoorbeeld datasets die bestaan uit opeenvolgende kwartalen, of datasets waarin de datums die voorkomen alleen maar werkdagen zijn en nooit weekenddagen, wat maakt dat je niet zomaar eender welke datum kan synthetiseren. Een dataset kan ook bestaan uit meerdere tabellen die met elkaar verbonden zijn. Zulke complexere problemen zijn mogelijk nog voer voor een vervolg-artikel later dit jaar.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Proliferatie & Exfiltratie

Zowel ondernemingen als overheidsdiensten hebben moeite om om te gaan met de relatief recente situatie waarbij de werknemers en delen van het (overheids-)bedrijf zonder toelating gebruik maken van allerlei diensten in de publieke cloud voor professionele doeleinden. Denken we maar aan het massaal gebruik van file sync & share oplossingen zoals Dropbox. Het CERN publiceerde bijvoorbeeld cijfers waaruit bleek dat er dagelijks 4500 verschillende IP-adressen naar Dropbox connecteren.

Maar naast Dropbox is er ook Box, OneDrive, Google Drive, etc. En om alles nog erger te maken zijn er nog andere types diensten in de publieke cloud die “illegaal” gebruikt worden door uw werknemers. Denken we maar aan maildiensten zoals Gmail voor particulieren en Hotmail. Dergelijke maildiensten worden vaak door werknemers gebruikt om even snel gegevens voor hen vanaf het hele internet toegankelijk te maken.

Het bedrijf of de overheidsdienst heeft er dan ook vaak geen flauw benul meer van

1. waar overal ter wereld haar gevoelige data gekopieerd staan (geografische fragmentering),
2. welke set cloud service providers daarvoor gebruikt wordt (proliferatie diensten),
3. welke personen toegang hebben tot deze gegevens.

Laat ons even ingaan op dit laatste aspect. Zelfs een toegewijde medewerker, we noemen hem gemakshalve Vladimir, gebruikt zonder toelating een dergelijke dienst. Vladimir heeft helaas niet steeds de hoogste vorm van security awareness en zal uit gemakzucht/efficiëntieredenen/werkdruk dan ook niet het sterkste paswoord kiezen om de bedrijfsgegevens in de cloud te beschermen. Of misschien is Vladimir zich er niet eens van bewust dat hij gevoelige gegevens in de publieke cloud plaatst of dat dit een probleem vormt. Wanneer een hacker het paswoord van Vladimir te weten komt, kan deze zich dus zonder probleem een lange tijd onopgemerkt toegang verschaffen tot bedrijfsdata. De impact hiervan is des te erger gezien Vladimir gebruikmaakt van automatische synchronisatie zodat de meest recente versie van elk van zijn documenten quasi onmiddellijk in de publieke cloud terechtkomt.

Het noodlot slaat toe voor onze toegewijde medewerker Vladimir en in het kader van de besparingen wordt hij ontslagen. Is dit zijn dank voor jarenlange hondstrouwe dienst? Hij besluit wraak te nemen… Hoewel Vladimir geen toegang meer heeft tot de bedrijfsinfrastructuur, heeft hij nog steeds toegang tot heel wat gevoelige bedrijfsgegevens in de cloud… Dit opent deuren naar zowel de onderwereld als naar de concurrentie. Of smijt hij de gegevens toch maar gewoon op straat? De volgende morgen leest de CEO in de krant dat confidentiële gegevens van haar bedrijf door Jan en alleman te downloaden zijn… Naast de directe financiële impact is er ook een enorme imagoschade. De aandelen kelderen…

Maar Vladimir had nog andere collega’s die op een gelijkaardige manier van publieke clouddiensten gebruik maken. Ook collega Korneel gebruikte automatische synchronisatie, zodat hij steeds een kopie van zijn gegevens in de cloud heeft. You never know…. Maar onbekenden hebben ook toegang gekregen tot de account van Korneel. Ze hebben via de webinterface van de dienst malware geüpload naar de account van Korneel, die vervolgens dankzij het synchronizatieproces op de bedrijfs-PC van Korneel gedownload werd.

Na een grondige scan naar aanleiding van het incident met Vladimir wordt malware gevonden op de PC van Korneel. Het blijkt de mogelijkheid te bezitten om data naar buitenlandse servers te sturen. Doordat de malware gebruik maakte van encryptie heeft het bedrijf geen enkel idee welke gegevens er zo gestolen zijn. Via de logs kan ze enkel vaststellen dat er inderdaad ettelijke gigabytes aan data gestolen is. De incidenten worden uitgebreid belicht in de media. Het bedrijf is genoodzaakt de boeken te sluiten.

Samengevat kan het gebruik van publieke clouddiensten het risico op dataexfiltratie aanzienlijk vergroten. In bovenstaand scenario werden verschillende vormen van dataexfiltratie gebruikt.

Buitenlandse Spionage

Overheden maar ook bedrijven zijn zeer geïnteresseerd in datgene waar de concurrent mee bezig is. Dit gaat doorgaans om zaken van economisch of militair belang. Dat dit niet enkel iets is uit de koude oorlogsperiode bleek nog na de onthullingen vorig jaar door Snowden, waaruit zou blijken dat onder meer de Duitse Bondskanselier Merkel afgeluisterd werd. Een paar jaar terug was er ook nog het ECHELON schandaal, waarbij volgens de geruchten de Verenigde Staten via de vergaarde informatie contracten van Europese bedrijven konden afsnoepen. Er zijn daarnaast nog tal van andere voorbeelden te geven van (vermoedelijk) overheidsgestuurde cyberspionage.

Via het PRISM-programma kreeg de Amerikaanse geheime inlichtingendienst NSA toegang tot gegevens in datacenters van onder meer Microsoft, Facebook, Apple, Google (zie onderstaande figuuur), terwijl de Britse zus van de NSA, genaamd GCHQ, toegang had tot de datacommunicatie op bepaalde belangrijke glasvezelkabels.

Dus ook al heeft het (overheids)bedrijf perfect waterdichte securitymaatregelen getroffen, waarbij er een eveneens perfecte security awareness heerst bij het personeel, dan nog zijn er onzichtbare maar toch zeer massieve lekken mogelijk wanneer met externen gecommuniceerd wordt of wanneer het door een cloud-dienst opgeslagen is.

Zowel de cloud service providers als hun overheden trachten uiteraard potentiële klanten gerust te stellen.

Individuele cloud spelers publiceren hun veiligheidsmaatregelen. Maar hoe weten we wat er echt onder de motorkap gebeurt? In een audit-rapport zullen wij alvast niets lezen over toegang door de staatsveiligheid. Verder bouwen de grote (Amerikaanse) cloudspelers datacenters in Europa om haar Europse markt gerust te stellen. Los van het feit dat we geen garantie hebben dat de data niet naar elders op de planeet doorgestuurd wordt, vallen deze bedrijven nog steeds onder de Amerikaanse jurisdictie (lees: de Patriot Act), waardoor ze gedwongen kunnen worden persoonsgegevens aan de Amerikaanse autoriteiten te bezorgen. Dit is natuurlijk een doorn in het oog voor deze bedrijven, gezien het resulteert in een grotere terughoudendheid om van haar diensten gebruik te maken. Microsoft startte daarom een juridische strijd tegen de Amerikaanse overheden om data in haar datacenter in Dublin niet af te hoeven geven. Ze werd daarbij gesteund door onder meer Apple, Verizon en Cisco. Toch oordeelde de rechtbank vorige maand dat Microsoft geen gelijk had.

Overheden trachten weliswaar de publieke opinie en het buitenland te sussen. Helaas kan aan de oprechtheid van deze uitspraken getwijfeld worden, en daar is met de recente spionageschandalen en juridische uitspraken des te meer reden toe.

De macht van de cloud provider

Een dienst in de publieke cloud is vaak goedkoper, garandeert hoge uptimes alsook een hoge graad van security en je beschikt steeds over de meest recente versie, en dat alles aan lage kosten. Maar tegelijkertijd is het ook een dienst waar je minder vat op hebt vergeleken met on-premise installaties. Dit manifesteert zich op verschillende vlakken:

• De publieke cloud is niet transparant. We weten niet steeds wat er technisch onder de moterkap gebeurt en wie er exact toegang tot de gegevens heeft. En dit kan wel eens tot onaangename verrassingen leiden. De cloud dienst Code Spaces pakte bijvoorbeeld tot voor kort uit met haar full recovery plan, maar dat bleek toch niet zo waterdicht te zijn als beloofd. Hackers waren erin geslaagd de virtuele machines en data die door Amazon gehost werden te verwijderen. Code Spaces moest haar activiteiten noodgewongen staken. Veel data zijn verloren. De klanten van de dienst hebben pech…. Dergelijke shut-downs zijn natuurlijk des te dramatischer naarmate de cloud-dienst meer geïntegreerd is met andere diensten die het eigen bedrijf gebruikt.
• Natuurlijk kan het één en ander contractueel vastgelegd worden, maar we hebben weet van een contractclausule – die stelde dat data de EU niet mag verlaten – unilateraal door de cloud provider gewijzigd werd. Policies lijken dus soms zomaar en te allen tijde wijzigbaar door de cloud provider. Wanneer dit juridisch aangevochten wordt, staat er wel een leger advocaten gereed.
• Bovendien veranderen cloud-diensten constant. Zo kan de user-interface van de ene dag op de andere zonder voorafgaande waarschuwing veranderen, wat uiteraard weer aanpassingspijnen met zich meebrengt. Erger is het wanneer bepaalde functionaliteiten of API’s (waar andere applicaties dan weer gebruik van maken) veranderen of zelfs verdwijnen. We krijgen dan wel een boodschap dat we ons maar moeten aanpassen tegen een door de cloud provider gedicteerde datum.

Een aantal populaire softwarepakketten die traditioneel volledig on-premise (server of PC) geïnstalleerd werden evolueren nu richting de publieke cloud, waarbij de on-premise versie minder of zelfs helemaal niet meer ondersteund dreigt te worden. Denken we maar aan het softwarepakket Adobe Creative Suite, dat uitgedoofd is en vervangen werd door Adobe Creative Cloud, wat volledig in de publieke cloud draait. Wil je je gevoelige gegevens bewerken met een actuele versie van het toonaangevende grafische pakket, dan ben je verplicht dit in de publieke cloud te doen. Maar ook Microsoft lijkt in eenzelfde richting te evolueren met haar SharePoint, waarbij het onduidelijk is of ze SharePoint on-premise op termijn nog zal aanbieden. Ook voor haar office toepassingen propageert Microsoft vooral sterk haar publieke cloud oplossing (Office 365). Bedrijven die van dergelijke diensten gebruik willen (blijven) maken riskeren dus de keuze om hun gevoelige gegevens al dan niet intern te houden te verliezen.

De cloud is een logische stap in een het proces van economische schaalvergroting, waarbij er slechts enkele enorm grote spelers overblijven die m.b.v. extreem doorgedreven schaalvoordelen alle concurrentie uitschakelen. Daarmee slagen ze er in hun eigen macht te consolideren en in toenemende mate de spelregels te bepalen, wat niet altijd in het voordeel van de klant is.

Conclusie

Deze tekst ging uitsluitend in op een aantal negatieve aspecten van de publieke cloud met betrekking tot gevoelige data. Dit neemt uiteraard niet weg dat er ook heel wat positieve aspecten aan het cloud gebeuren zijn. Toch worden maar al te vaak de negatieve onderbelicht of, sterker nog, gewoon onder de mat geveegd. Het blijft dan ook de verantwoordelijkheid van het (overheids)bedrijf om telkens goed de afweging te maken tussen het kostenvoordeel enerzijds en risico anderzijds.

Dit artikel is deels gebaseerd op de infosessie “Gevoelige Overheidsdata en de Cloud” die gegeven werd op 3 april 2014. De integrale presentatie kunt u hieronder bekijken. De presentatie met de bijhorende demofilmpjes zijn hier te downloaden.