Online drukkerij Drukland meldt datalek met gehashte wachtwoorden

Drukland mailt klanten over een datalek waarbij e-mailadressen en gehashte wachtwoorden gestolen zijn. Het is niet bekend welk algoritme er is gebruikt. De online drukkerij is actief in zowel Nederland als België en contacteert klanten in beide landen.

De online drukker schrijft in de mail dat er een 'veiligheidsincident' is geweest bij het moederbedrijf van Drukland, Simian. Onder dit bedrijf vallen ook de drukwerksites Reclameland en Flyerzone. Het is niet duidelijk of ook deze winkels door het datalek zijn getroffen.

"Uit ons voorlopig onderzoek blijkt dat er mogelijk toegang is verkregen tot persoonsgegevens in ons klantendossier", schrijft Drukland. "Het gaat om gebruikersnamen (e-mailadressen) en gehashte wachtwoorden. De cybercriminelen hebben deze gegevens mogelijk ook ontvreemd."

Drukland geeft geen details over de aanval of met welk algoritme de wachtwoorden zijn gehasht. De site zegt het lek te hebben gemeld bij de Autoriteit Persoonsgegevens. Het platform waarschuwt voor phishing en raadt gebruikers die wachtwoorden hergebruiken aan om dat wachtwoord aan te passen. Drukland zegt ook maatregelen te hebben genomen, zoals het blokkeren van systeemaccounts en het resetten van alle wachtwoorden.

Bron: Getty Images

Reacties (53)

[g86]

Ook gemeld aan Tweakers redactie. Deze mail vanochtend ontvangen.

Meer info: https://www.drukland.be/page/veiligheidsincident
"Klanten die na 15-07-2026 een account hebben aangemaakt, zijn niet door het incident getroffen."


Belangrijke informatie over een datalek

Beste *****,

Onlangs is er een veiligheidsincident voorgevallen bij Simian B.V. (Simian), moederbedrijf van Drukland. Het is mogelijk dat hierbij persoonsgegevens betrokken zijn geraakt.

We begrijpen dat dit bericht vragen of zorgen kan oproepen. De veiligheid van jouw gegevens nemen we zeer serieus en daarom willen we je zo open en duidelijk mogelijk informeren over wat er is gebeurd, wat dit mogelijk voor jou betekent en welke maatregelen we hebben genomen.

Uit ons voorlopig onderzoek blijkt dat er mogelijk toegang is verkregen tot persoonsgegevens in ons klantendossier. Het gaat om gebruikersnamen (e-mailadressen) en gehashte wachtwoorden. De cybercriminelen hebben deze gegevens mogelijk ook ontvreemd. Wij hebben de Autoriteit Persoonsgegevens (AP) hierover geïnformeerd. Omdat het voorgaande mogelijk gevolgen voor jou kan hebben, informeren wij je over dit incident in deze e-mail.

Wat betekent dit voor jou?

Criminelen kunnen misbruik proberen te maken van deze gegevens. Bijvoorbeeld door oplichting of phishing.

Mogelijke risico’s voor jou zijn onder meer:

Phishing: je ontvangt e-mails, sms-berichten of telefoontjes die betrouwbaar lijken. Omdat de criminelen je gegevens hebben, kunnen zij de e-mail persoonlijk maken. Daardoor lijkt de e-mail betrouwbaar. Je krijgt bijvoorbeeld de vraag om op een link te klikken. Als je dit doet, kan je worden opgelicht;
Telefonische fraude: iemand doet zich dan bijvoorbeeld voor als een medewerker van onze organisatie. Krijg je de vraag om wachtwoorden te delen of iets te downloaden op jouw computer? Doe dit nooit;
Identiteitsfraude: iemand kan misbruik van jouw persoonsgegevens maken door zich als jou voor te doen;
Gerichte fraude: veel mensen gebruiken bijvoorbeeld hetzelfde wachtwoord voor verschillende websites. Dat vergroot het risico als deze wachtwoorden in verkeerde handen terecht komt;
Social engineering: pogingen om extra informatie van je te verkrijgen door vertrouwen op te wekken. Dat doet de crimineel door gebruik te maken van de gelekte informatie.
Wat heeft Simian gedaan in reactie op het incident?

Direct na het incident hebben wij een groot aantal technische en organisatorische maatregelen getroffen om verdere ongeautoriseerde toegang te voorkomen, waaronder:

Alle betrokken systeem accounts zijn geblokkeerd;
Wachtwoorden van alle gebruikers zijn gereset;
Toegang tot systemen zijn stricter afgeschermd;
Systeem wachtwoorden zijn vervangen.
Daarnaast blijven we de situatie nauwlettend monitoren en nemen we waar nodig aanvullende maatregelen.

Wat kan je zelf doen?

Wees extra alert op onverwachte e-mails, sms-berichten of telefoontjes;
Als je vaker dezelfde combinatie van gebruikersnaam (e-mailadres) en wachtwoord gebruikt, verander deze dan ook op andere websites en bij andere diensten;
Klik nooit op links en open geen bijlagen als je de afzender niet volledig vertrouwt;
Deel geen persoonlijke gegevens via e-mail of telefoon zonder dat je nagaat of je te maken hebt met een betrouwbare partij;
Neem bij twijfel rechtstreeks contact op met onze organisatie via de contact pagina op onze website;
Controleer regelmatig je bankafschriften en meld verdachte transacties direct bij jouw eigen bank.
Meer informatie

Zie voor meer informatie over identiteitsfraude en hoe dat tegen te gaan:

https://www.politie.be/informaticacriminaliteit/
https://www.belgium.be/nl...inaliteit/cyberveiligheid
Jouw rechten

Als betrokkene heb je privacyrechten, zoals inzage en correctie van persoonsgegevens die wij voor je verwerken. Ook kan je zelf een klacht indienen bij de AP. Zie voor meer informatie: https://www.autoriteitpersoonsgegevens.nl/.

Vragen of zorgen?
Heb je vragen of zorgen? Neem gerust contact met ons op via:

telefoon: 03 747 9001 (doordeweeks bereikbaar van 09:00 tot 18:00)
e-mail: [e-mail]
We doen er alles aan om onze systemen en jouw gegevens zo goed mogelijk te beschermen en houden je op de hoogte als er relevante nieuwe informatie is.

Met vriendelijke groet,
Team Drukland

[Reactie gewijzigd door g86 op 10 augustus 2026 19:51]

[tedades]

Ook deze mail heb ik ontvangen, voor de tellers kom ik dan nu uit op 16 datalekken. Mijn e-mail en wachtwoord voor Drukland was gelukkig uniek, maar toch. Er is iemand goed bezig met inbreken, ik vraag me af of we dit tegenwoordig meer te horen krijgen of dat mensen (met hulp van AI?) daadwerkelijk ook meer inbreken.

[g86]

Als je kijkt op ransomware.live dan weet je genoeg. Er wordt elke seconde gehackt en data gelekt. En de meeste hacks op die site kan je dus ook terugvinden op Tor via .onion. Het gaat alleen maar erger worden.

Bij Drukland.be was de login ook uniek, maar ik heb wel mijn account laten schrappen. Want mijn bestelling was ook eenmalig en dateert uit 2023.

[ZpAz]

Ja, AI is absoluut hier een speler. Maar meer 'economics of scale' dan 'master hacker'. Veel websites en services zijn gewoon niet goed beschermt. En botjes vanover de hele wereld struinen nu 24 uur per dag het internet af naar potentiele doelen en vallen ze automatisch aan.

[n9iels]

Het is niet bekend welk algoritme er is gebruikt.

We zijn anno 2026 gelukkig wel zo ver dat dat niemand meer MD5 of SHA1 gebruikt. Toch?...

[StarZ]

Ik heb wel bij bedrijven gewerkt die nog met oude algoritmes zaten. Het updaten was altijd een strijd omdat dat zou vereisen dat gebruikers een nieuw wachtwoord zouden instellen en dat was weer een extra stap voor de betaling dus moeilijk moeilijk. Hebben het uiteindelijk wel voor elkaar gekregen maar het was echt een strijd. Viel uiteindelijk reuze mee natuurlijk en blij dat we dat destijds gedaan hebben.

[latka]

Kan toch bij een reguliere login: voordat je hashed kijk je of het hashformaat wat je nu hebt oud is. Zoja, dan verifieer je nog eenmaal met de oude hash en overschrijft daarna de entry met de sterkere hash. Na een x aantal maanden heb je 80% van je gebruikers wel te pakken (of meer of minder afhankelijk van je site) en dan reset je de overgebleven oude stijl accounts.

[RobertMe]

Of je doet alle oude hashes nog eens hashen met een beter algoritme. Bij login doe je dan controleren of het zo'n "geupgrade" oud wachtwoord is en doe je eerst het oude hashing algoritme toepassen en gebruik je dat verder als "het wachtwoord" (dus nieuwe algoritme er overheen). Is die controle succesvol doe je het (daadwerkelijke) wachtwoord nog een keer hashen, puur op de nieuwe manier, en slaat dat op.

Dan heeft de gebruiker er echt geen last van (behalve eenmalig een net iets tragere login) doordat je WWs potentieel gaat resetten etc. En je hebt dan geen periode van maanden waarin alsnog de onveilige hashes in de DB staan.

[sourcecode]

als ik ga naar drukland.be/admin kom ik hier uit https://www.drukland.be/loginadmin
dan denk ik waarom maak je een login zo default ?

EDIT ze hebben de login verwijderd :)

En dan is de vraag

IDD of ze bcrypt gebruiken

[Reactie gewijzigd door sourcecode op 10 augustus 2026 21:46]

[elmuerte]

bcrypt met 10 rounds of (nog erger) pbkdf2 met 1000 rounds zijn niet veel beter.

[PdeBie]

Je moest eens weten. Of de salt gewoon in dezelfde tabel ernaast opslaan.

[RobertMe]

Het opslaan van de salt ernaast is echt totaal geen issue. Salting wordt gedaan om rainbow tables onmogelijk te maken. Als je duizenden/miljoenen hashes moet gaan genereren op basis van een unieke salt + random wachtwoord ben je nog steeds wel even bezig. En verschillende algoritmes / geaccepteerde manieren van opslaan doen de salt ook gewoon in het wachtwoordveld opslaan. Iets van $x$y$z waarbij x het algoritme / "versie" aangeeft, y de salt, en z de hash van wachtwoord + salt op basis van algoritme x.

[Argantonis]

Je bedoelt zoals gebruikelijk en veilig is?

[Little Penguin]

Ik zou er niet te vast op rekenen, er is genoeg oude software en veiligheid is regelmatig een ondergeschoven kindje.

Inmiddels zijn we wel voorbij het punt dat wachtwoorden niet meer hoofdletterongevoelig zijn (in het verleden was dat nog wel eens een punt, want ja als je dat niet hoeft te onthouden is het wel gemakkelijker voor de gebruiker - ook onveiliger, maar daar werd niet aan gedacht).

Idem-dito met wel/geen salt, tegenwoordig heb je meer nodig dan alleen een salt vanwege de toegenomen mogelijkheden tot paralleliseren, maar in het verleden was een salt al een significante verbetering. Een dom wachtwoord als 'password123' of namen van familieleden zijn met een salt al veel lastiger te achterhalen, maar ik geef ze niet graag de kost die echt nog domweg alleen een hash gebruiken (omdat er ook 20 jaar geleden niet nagedacht is over ook maar het simpelste wat gedaan kan worden om rainbow tables onbruikbaar te maken)...

En tegenwoordig moet je bcrypt, Argon2, PBKDF2 of vergelijkbare algoritmes gebruiken...

[Peatsmoke]

Het is wel Duitsland.

10 jaar geleden was daar de typemachine nog heel gewoon en nog steeds zie je bij veel contactadressen een faxnummer.

Inmiddels is men wel doordrongen van het feit dat ze op digitaal vlak jaren achterlopen en probeert men een inhaalslag te maken.

[LootersV]

Met een gehasht wachtwoord is de kans dat er iets uitlekt nog steeds pretty high..

[Yongshi]

Ligt eraan. Is het met een moderne hash en gebruiken ze goede salts? Dan is het niet zo een probleem. Sha1 zonder salts, ai, ai.

Vandaar dat er werd gebraagd om welk algoritme, want dan kan je beter het risico duiden. Maar ja dan help je de aanvaller wellicht ook weer...

[juiced01]

Ben daar klant (sinds 2021) maar geen mail ontvangen... Gelukkig bestaan er tegenwoordig password managers met unieke wachtwoorden

[tedades]

Bij mij zat hij in de spam folder, mail is verzonden van: [e-mail]

[juiced01]

Ah ja, hier ook in de spambox!

[psygarden]

We'll erg dat ze hiervoor een nieuw mailadres gebruiken dat bij niemand gewhitelist staat, gaat bij meer mensen in spam staan als iets anders!

Hier idem, bij spam.

[g86]

Mijn account bij Drukwerk.be dateert van 2023 en ik kreeg de mail wel.

[hackerhater]

Reclameland is getroffen. Ik heb de E-mail gehad.

[BvdW1978]

Hoe lang geleden moet je laatste transactie zijn om gewoon netjes uit het bestand gehaald te worden?

[SunnieNL]

Als jij niet gebruik maakt van je recht om vergeten te worden of het account niet op heft, kan dat best lang duren. Zeker als je akkoord bent gegaan met marketing.

[themadone]

En daarom lieve kijkbuis kinderen altijd non reversible encryption op je zooi, ooit gaan ze het leren.....

[RobertMe]

Encryptie en non-reversible zijn niet compatible met elkaar. Of het is onomkeerbaar en dan is het geen encryptie, of het is encryptie maar dan is het dus ook omkeerbaar. Encryptie en decryptie gaan immers hand in hand.

Als je het non reversible wilt hebben moet je dus hashes gebruiken. En dat is dus ook wat ze gedaan hebben. Het gebruik van "hashes" is dus 100% juist in deze. De vraag is alleen, zoals ook in het artikel staat, welk hashing algoritme er gebruikt is. Hopelijk is dat er eentje die heden ten dagen ook "veilig" is. Waarbij veilig dus neer komt op "niet eenvoudig te achterhalen door te brute forcen" (doordat het algoritme "zwaar" op de CPU en/of geheugen is waardoor het genereren van een enkele hash ook op moderne hardware tienden van seconden duurt, waarmee het genereren van 1 miljoen wachtwoorden ineens ~27 uur en 45 minuten gaat duren (0,1s per wachtwoord, 1 miljoen wachtwoorden is dan 100.000 seconden, oftewel 27,7777 uur))

[themadone]

Ok, en als je een key buiten je database hebt die je gebruikt om tot die hash te komen? Is het dan net zo "makkelijk" te kraken als je die key niet hebt? Want dan kan je op basis van passwords hashes creëren tot de zon stopt met branden, maar je mist dan die extra input, die kan je begraven in een keystore op het OS bijvoorbeeld zodat een database breach niets zeggende hashes oplevert?

Als je het correcte password zou raden kom je nog niet tot dezelfde hash zeg maar?

Of werkt dat ook niet? Oprechte interesse.

[RobertMe]

Gezien de stelligheid van je eerste reactie zou je het antwoord hier zelf op moeten weten?

En als je de encryptiesleutel buiten de database bewaard hoeft dat helemaal niet veiliger te zijn. We weten immers ook niet hoe dit lek heeft plaatsgevonden. Is er alleen toegang tot de database geweest middels, bv, SQL injection? Of hebben de hackers bv toegang tot de volledige server(s) gehad, SSH toegang dus?

En het veilig opslaan van een encryptiesleutel in een keystore zegt niks. Dat helpt voornamelijk tegen het lezen van de sleutel van de schijf. Maar die sleutel is semi continu nodig (want nodig bij inloggen, wijzigingen wachtwoord, ...). En gezien de beheerder niet bij elke inlogpoging expliciet de keystore gaat ontgrendelen zal dus of de sleutel voor de keystore "zijn ingeladen" of de keystore volledig open staan. Waardoor iemand met toegang tot de server... dus weer mogelijk toegang heeft tot de ontgrendelde keystore of de sleutel om de keystore te ontgrendelen/gebruiken.

[fre0n]

Maar gebruik je GPU's (meervoud, als in enkele honderden GPU's) dan is een miljoen binnen een fractie van een seconde gedaan

[Little Penguin]

Hashing is wat anders dan encryption en een hash is ook maar één kant op, het probleem is dat als het alleen maar een hash is (dus zonder salt en eventueel een pepper) het veel gemakkelijker is om met rainbow tables te bepalen welk wachtwoord bij welke hash hoort.

Daarom is dus ook een salt zo belangrijk (al jaren) en tegenwoordig is een simpele hash+salt ook niet meer voldoende en moet er gewerkt worden met een algoritme dat niet gemakkelijk te paralleliseren is (vanwege het feit dat tegenwoordig videokaarten heel veel hashing - inclusief salt parallel kunnen doen|). Denk hierbij aan Argon of PBKDF2 dat het hashen niet 1 keer doet maar tig keer en zo het vrijwel onmogelijk maken om voor ieder password op basis van standaard invoer + salt de mogelijke hashes te gaan berekenen...

[willemb2]

Geen mail ontvangen van drukland.nl. Account van eind 2024 bestond nog wel, maar wachtwoord was verlopen. Nieuw wachtwoord aanvragen levert een mail met een wachtwoord in plain text op i.p.v. de tegenwoordig gebruikelijke reset link.
In het 'Mijn account' menu ontbreekt een optie op het account te verwijderen. Maakt allemaal een beetje verouderde indruk.

[g86]

Inderdaad. Ik kreeg ook een wachtwoord in plain text per mail nadat ik wou aanmelden.
Account verwijderen via de site lukt niet. Ik heb dit gevraag per mail om dit te verwijderen conform de AVG/GDPR wetgeving.

Ik kreeg dit als antwoord van de klantendienst van Drukland.be. Maar een halve dag later kan ik nog altijd aanmelden.

Hi ***, bedankt voor je bericht.
We hebben je verzoek om je persoonsgegevens te verwijderen in goede orde ontvangen.
We verwijderen je persoonsgegevens voor zover we deze niet langer mogen of moeten bewaren op grond van de toepasselijke wet- en regelgeving. Zodra dit is verwerkt, is je verzoek afgehandeld.
Met vriendelijke groet,
***
Klantenservice

[Orthodroom]

Dat woordje ‘mogen’ is toch wel vreemd of niet? Je verzoekt nu immers om het te verwijderen.

En bij moeten kan ik mij niet voorstellen dat ze alles moeten bewaren. Voor de belastingdienst hoef je immers niet een wachtwoord te bewaren.

[clip87]

Gelijkaardige ervaring. mail met plain text pw Daarop stuurde ik ze volgend bericht:

"U neemt het toch niet zo nauw met cybersecurity; nieuw paswoord in plain text via email dat bovendien niet verplicht dient gewijzigd bij de eerste inlogpoging ??? Niet meer van deze tijd vrees ik. Ik vind ook geen link om mijn account te verwijderen ? Bij deze het vriendelijke verzoek mijn account en alle gerelateerde gegevens definitief te verwijderen en mij de verwijdering te bevestigen per kerende."

Inmiddels pw veranderd na aangelogd te zijn met het door hen toegezonden pw en dan mail verzoek gedaan om account te wissen. Aan hun antwoord te zien moeten we er dan maar van uitgaan dat het ook zal gebeuren:

"We verwijderen je persoonsgegevens voor zover we deze niet langer mogen of moeten bewaren op grond van de toepasselijke wet- en regelgeving. Zodra dit is verwerkt, is je verzoek afgehandeld."

Ook niet echt klantvriendelijk wat mij betreft.

[g86]

Ik heb iets gelijkaardig gemaild ivm die plaintext, maar op een hardere manier. Ik heb ook laten weten dat als ik nog kan aanmelden binnen de 24u dat ik klacht ga indienen. Want ik kan sinds gisteren nog altijd aanmelden op mijn account, terwijl ik vroeg om dat te wissen.

[g86]

@clip87 ik krijg nu als reactie:

We zijn momenteel alle verwijderverzoeken aan het verwerken. Daarvoor hebben wij 30 dagen. Wij pakken dit op.

[S-1-5-7]

Het is aantal datalekken vandaag de dag is echt absurd. Het zijn er zoveel dat er over veel niet eens wordt geschreven. Precies een maand geleden (10 juli) ontving ik er een Lidl, niets over gelezen, ondanks de tip (wat verder prima is). Vandaag deze van Roadsurfer.

Geachte heer, mevrouw, 

wij willen u informeren over een beveiligingsincident bij een externe softwaredienstverlener, waarvan wij de applicatie (Metabase) gebruiken voor de analyse van bedrijfsgegevens. Op 1 augustus 2026 hebben onbekende derden misbruik gemaakt van een tot dan toe onbekend beveiligingslek (een zogenaamde "zero-day"). Een dergelijke aanval maakt gebruik van een kwetsbaarheid die op dat moment noch bij de maker van de software, noch bij ons bekend was. 

Uw betaalgegevens en kopieën van uw rijbewijs zijn niet getroffen, en het beveiligingslek is inmiddels gedicht. 

De bescherming van uw gegevens heeft voor ons hoge prioriteit. Wij hebben onmiddellijk na kennisname gehandeld: 

- Op 6 augustus 2026 heeft de dienstverlener ons bevestigd dat het beveiligingslek is gedicht en de getroffen toegangspunten geblokkeerd zijn. 

- De dienstverlener heeft de bevoegde autoriteiten ingelicht en externe IT-forensische experts ingeschakeld. 

- Wij hebben daarnaast de getroffen toegangsgegevens en sleutels gewijzigd, actieve sessies beëindigd en alle accounts gecontroleerd en opgeschoond. 

- Wij hebben het incident gemeld bij de bevoegde toezichthoudende autoriteit voor gegevensbescherming. 

Om redenen van gegevensbescherming zijn wij verplicht u te informeren over de betrokken gegevens. Volgens de huidige stand van zaken hadden de aanvallers toegang tot uw naam, uw woonadres, uw geboortedatum en huurperiodes in verband met de huur of aankoop van een camper. 

Deze gegevens kunnen worden gebruikt voor gerichte fraudepogingen (phishing). Uit voorzorg raden wij u enkel de gebruikelijke voorzorgsmaatregelen aan: 

- Wees terughoudend bij onverwachte telefoontjes, e-mails of sms-berichten die betrekking hebben op uw boeking en u vragen om meer gegevens te verstrekken of betalingen te doen. 

- Open geen links of bijlagen in dergelijke berichten. roadsurfer zal u nooit telefonisch of per e-mail om wachtwoorden of volledige identiteitsgegevens vragen. 

Wij betreuren het ongemak en danken u voor uw begrip. Over belangrijke nieuwe inzichten informeren wij u uit eigen beweging. Voor vragen kunt u contact opnemen met ons team Gegevensbescherming via <knip>.

Met vriendelijke groet, 

Het gegevensbeschermingsteam van roadsurfer

[RobertMe]

Precies een maand geleden (10 juli) ontving ik er een Lidl, niets over gelezen, ondanks de tip (wat verder prima is).

Toch heeft Tweakers er, op 10 juli, over geschreven: nieuws: Hackers stelen data van Nederlandse en Belgische klanten Lidl-webshop...

[S-1-5-7]

Ah, check. Die had ik dan gemist...

[SunnieNL]

Is het aantal lekken vandaag de dag absurbt, of is het altijd zo geweest maar werd het of niet gemeld of niet door het nieuws opgepakt?

Kijkend naar de datalekken uit mijn verleden zijn het er wel wat meer, maar in het verleden is toch ook een hoop van mij gelekt wat alleen nooit zo in het nieuws is geweest.

(ik kan het zien omdat ik al jaren unieke emailadressen gebruik en de spam op heel veel mailadressen binnen komt)

[S-1-5-7]

Gemeld zou kunnen, maar ook ik gebruik al heel wat jaren unieke adressen en ik heb zelden zo vaak een adres moeten uitschakelen als nu.
En ik gebruik echte unieke adressen. Als ik pieter+tweakers@mail[.]xyz zie is het voor mij niet lastig te raden wat het adres bij Facebook zal zijn...

Ik zie geen rede waarom dit 'vroeger' niet nieuwswaardig zou zijn, en nu wel. Er worden nu dagelijks hele datasets gestolen, dat was vroeger echt niet zo.

[SunnieNL]

[e-mail] wordt ook door spammers direct afgekapt naar [e-mail] en daar voor de spam gebruikt.

Ik heb [e-mail], [e-mail], [e-mail], [e-mail]. Vroeger was dit ook nieuwswaardig, maar het werd niet gemeld door de bedrijven zelf. Nu zijn ze dat verplicht te melden. Daar zit nog bij dat ze moeten bepalen of het ook naar de mensen zelf gaat, wat al heel snel is als er persoonlijke informatie is gelekt.

En vroeger werden die hele datasets ook gestolen. Geloof me. Het was echt niet zo dat ze vroeger maar 1 mailadres gelekt kregen.

[S-1-5-7]

En vroeger werden die hele datasets ook gestolen. Geloof me. Het was echt niet zo dat ze vroeger maar 1 mailadres gelekt kregen.

Dat weet ik en zeg ik ook niet, toch?

Maar het is gewoon niet zo dat er dagelijks datasets werden gestolen. Dat de meldplicht er nu is, betekent niet dat het vroeger altijd in de doofpot kon worden gestopt. In veel gevallen werd het uitdelijk wel duidelijk waar de dataset vandaag kwam, alleen duurde het langer

[adje123]

De Lek bij reclameland is al vanaf 25 juli bekend. Ik heb het ook doorgegeven aan t.net maar die hebben er niks mee gedaan.