United Consumers stuurt klanten honderden e-mails met privégegevens - update

Energiemaatschappij United Consumers heeft zeker 6500 klanten elkaars energieverbruik, postcodes en e-mailadressen gestuurd. Dat gebeurde in een e-mail waarbij waarschijnlijk een verkeerd invoerveld is gebruikt. Klanten krijgen honderden e-mails in hun inboxen.

Dat blijkt uit berichten van verschillende Twitter-gebruikers. Zij melden dat zij honderden e-mails hebben ontvangen die bedoeld zijn voor andere klanten. Het gaat om een melding dat het maandelijkse energiegebruik van huishoudens klaarstaat. De mails zijn aangeduid met een bepaalde postcode. Naast de e-mailadressen en postcodes zijn ook de huisnummers en de klantnummers van de getroffenen uitgelekt. De klantenservice erkent het probleem en zegt dat er een melding wordt gedaan bij de Autoriteit Persoonsgegevens. Inmiddels zouden er geen nieuwe mails meer verstuurd worden.

Volgens een woordvoerder van het bedrijf is er onlangs een aanpassing gedaan aan de custom software die het bedrijf zelf heeft gemaakt voor het versturen van automatische energieoverzichtnotificaties. "Daarbij is vergeten het 'Aan'-veld na iedere mail leeg te maken", zegt de woordvoerder. "De eerste klant kreeg daarom een bericht met maar één e-mailadres erin, maar de tweede zag er twee, de derde drie, enzovoorts." Sommige klanten kregen daardoor tientallen of zelfs honderden e-mails. United Consumers zegt dat de eerste mails om 10.15 werden verstuurd. Het bedrijf kreeg al vrij snel daarna klachten en stopte het systeem vervolgens.

Volgens de woordvoerder werden de mails verstuurd naar een batch van 2865 klanten. In theorie zou er dus één klant 2865 e-mails hebben kunnen ontvangen. In de praktijk ligt dat aantal lager, omdat het proces vroegtijdig is gestopt. Toch zijn er verschillende klanten die aangeven dat er méér gebruikers zijn getroffen. Zo zegt één gebruiker op Twitter dat hij in één e-mail 6500 adressen kan zien. Volgens de woordvoerder van United Consumers klopt dat aantal niet. "We zijn nog bezig met het onderzoek. We zijn van plan alle klanten te informeren en gaan dit melden bij de Autoriteit Persoonsgegevens."

Update, 13.02: Artikel is bijgewerkt met de reactie van United Consumers.

Reacties (106)

Gisteren een SMS ontvangen met een korte uitleg.
Vandaag een duidelijke mail met uitleg ontvangen van UC:

Beste ...,

Hartelijk dank voor uw bericht.

Op dinsdag 25 februari 2020 is er helaas een fout opgetreden in ons mailsysteem, waardoor u mogelijk meerdere e-mails met klantgegevens van andere klanten heeft ontvangen. Het gaat hierbij om een notificatie dat het energie verbruiksoverzicht klaarstaat in ‘Mijn UnitedConsumers’. Het betreft ca. 3000 deelnemers. De e-mails bevatten persoonlijke gegevens. Mogelijkerwijs zijn ook uw gegevens bij andere klanten terechtgekomen. Het betreft de volgende gegevens:

• Postcode.
• Huisnummer.
• E-mailadres.
• Deelnemernummer.

Wij willen u graag geruststellen dat derden niet kunnen inloggen in uw account.

Wat kunt u doen?
Technisch gezien is het helaas niet mogelijk om de mailing ongedaan te maken. Daarom vragen wij u vriendelijk om de e-mails welke niet voor u bestemd zijn, te verwijderen.

Welke acties hebben wij ondernomen?
Toen we achter deze fout kwamen, hebben we het mailproces direct stopgezet. Hierdoor hebben we de schade kunnen beperken. Uit ons onderzoek blijkt dat de interne storing het gevolg is van zowel een menselijke, als een technische fout. Onze systemen zijn daarom direct aangepast, zodat we deze fout in de toekomst kunnen voorkomen.

Onze oprechte excuses
Met het hele bedrijf zijn wij bezig geweest om al onze getroffen deelnemers op de hoogte te stellen via sms, telefoon of per post.
Via onze website blijft u op de hoogte van de laatste ontwikkelingen.

Heeft u nog een vraag?
Onze klantenservice beantwoordt uw vragen graag. U bereikt ons per e-mail ...

Hopende u hiermee voldoende te hebben geïnformeerd.

Met vriendelijke groet,

Er staat overigens niet in in de mail dat/of ze de Autoriteit Persoonsgegevens informeren/geïnformeerd hebben.

[Reactie gewijzigd door Anoniem: 120539 op 26 februari 2020 14:43]

_{"Daarbij is vergeten het 'Aan'-veld na iedere mail leeg te maken", zegt de woordvoerder. "De eerste klant kreeg dus een bericht, maar de tweede kreeg er twee, de derde drie, enzovoorts."}

Volgens mij is dit niet correct. Als het 'Aan'-veld na iedere mail niet leeg wordt gemaakt dan ontvangt klant 1 juist elke opvolgende mail die er uit gaat. (of zie ik het verkeerd?)

Ja je hebt gelijk! Ik heb het verkeerd opgeschreven, het gaat inderdaad niet om het aantal mails dat klanten 1, 2 en 3 krijgen, maar het aantal e-mailadressen dat ze daarin zien. Excuses!

nee, niet

edit:
inderdaad!

als de volgende geadresseerde aan de lijst met 'aan'-adressen wordt toegevoegd.
mail 1 → klant 1
mail 2 → klant 1, klant 2
mail 3 → klant 1, klant 2, klant 3
enz....

zo krijgt iedere klant eerst de mail voor zichzelf, en vervolgens ook nog alle mails die daarna voor andere klanten wordt aangemaakt.

edit: excuus, ik heb nog een bakkie koffie nodig. @BSOD005 je hebt helemaal gelijk!

[Reactie gewijzigd door NovapaX op 25 februari 2020 13:41]

Ja, dat was zijn constatering ook .

Oja, inderdaad. Toont maar weer aan dat het verwoorden van (resultaten van) algoritmes in gewone taal nogal voor verwarring kan zorgen.

Ik vermoed dat de woordvoerder niet geheel bekend is met de logica, en ook maar weer via-via een andere manager van de automatiseringsafdeling het probleem doorgespeeld heeft gekregen.

Ik heb niet het aantal mails geteld dat ik heb gehad, maar in het "to" veld van mijn mails staan bijna 6700 namen en emails. (Topic op GoT)

122 mails volgens gmail bij mij.Wel meer in het "to"veld.

Dus jij hebt vast een laag huisnummer. iets in de 1- reeks?

Er zit nu een developer bij United Consumers met tranen in z'n ogen, op kantoor bij de manager, aan het uitleggen is hoe dit heeft kunnen gebeuren. Kleine dingetjes waarschijnlijk; nieuwe automatisch mail functie; cc gebruikt in plaats van ieder mailtje los te verzenden; of `$emails` gebruikt in de foreach loop ipv `$email` in het to veld...

Het is inmiddels duidelijk hoe het gebeurde (zie artikel). Tl;dr: custom software voor mailings, foutje gemaakt (to-veld werd niet geleegd), in tests viel het niet op, doorgezet naar productie.

hahahaha, in tests viel het niet op. Geniaal. Indien getest zou dit direct zijn opgevallen.

Dit is ongetest doorgezet, óf men heeft niet getest op de manier waarop het zou worden toegepast in productie, wat in feite betekent dat het niet getest is. Pijnlijk hoor.

[Reactie gewijzigd door Oyxl op 25 februari 2020 13:59]

Vermoed dat ze het maar op 1 "testklant" hebben getest.
Dus netjes 1 mail.

Precies. Even snel een gebruiker testen, ja het werkt, doorsturen maar. Oepsie.

Dit krijg je met afgeraffelde testprocedures en/of engineers die geen creatief denkvermogen hebben.

Of managers die pushen op het snel afmaken van een stuk code en je als ontwikkelaar welgeteld één uur geven voor het testen...

Dit soort fouten ligt veelal niet aan de testers en ontwikkelaars zelf, maar aan de laag daarboven die onder tijd/gelddruk besluiten minimaal/niet te testen.

Dit is zeker een valide opmerking. Ik heb in omgevingen gewerkt waar dit de norm is en in omgevingen waar men wel bewust omgaat met testen.

nog waarschijnlijker: een slecht opgebouwde testset met 1000 virtuele klanten - waarbij ze alle 1000 klanten hetzelfde mailadres hebben gegeven.
Testen van mailfunctionaliteit gaat wel vaker fout want ketentest is moeilijk.

Vreemd als programmeur ga je toch geen variable += (append gebruiken) als je elke keer een nieuwe verzender Wil hebben. Dan pak je gewoon variable =.

Dat ben ik helemaal met je eens, maar dat is vrij makkelijk achteraf te stellen, op basis van één regel. Wellicht gaat het hier om een database query naar een array/hashtable, op basis waarvan een loop gemaakt wordt en is de engineer in kwestie aldoende net even te creatief geweest. - ik probeer aan te geven, we zien de rest van het script niet.

Dát vind ik persoonlijk helemaal niet erg. Ik maak geregeld dat soort stomme fouten. Gewoon denkfoutjes die je moet bugfixen. Maar mijn fouten komen niet bij de klant. Period.

[Reactie gewijzigd door Oyxl op 25 februari 2020 15:50]

Gewoon na elke iteratie alle waardes op 0 zetten. Wel zo netjes. En had dit soort fouten voorkomen.
Een beetje ontwikkelaar doet dit standaard.

't Zit er dik in dat ze een externe bibliotheek gebruiken voor het verzenden van emails. En zulke bibliotheken moeten natuurlijk de mogelijkheid ondersteunen voor meerdere TO's, dus die hebben vaak een 'addTo'-achtige methode (en wellicht geen 'setTo' die alles overschrijft).
En misschien was dat hier ook wel nodig om te gebruiken, om per klant meerdere mailadressen te hanteren.

Maar als je dan je mail-objectje hergebruikt omdat je - behalve de ontvanger - dat ding verder prima kon hergebruiken en dat dan vaak beter is voor de performance, dan moet je er inderdaad wel aan denken dat als je zo'n 'addTo'-methode gebruikt, dat je 'm dan wel steeds leeg moet maken...

Een flink aantal jaar geleden heeft een collega deze fout ook gemaakt toen er nog gewerkt werd met een custom mail class. De 'to' method voegde intern een to adres toe aan de lijst. Geen probleem als je elke iteratie een nieuwe instantie van de class maakt. Doe je dat niet, dan krijg je exact dit probleem.

Dat is dan toch gewoon niet optimaal nagedacht over het gebruik van de API. Je kan niet alles bedenken dat klopt. Maar op zijn minst een addTo en SetTo.

Dat had met fatsoenlijk testen gewoon naar boven moeten komen hier is helemaal geen excuses voor behalve pruts werk. Het OTAP straat zal vast door 1 persoon gedaan worden daar.

[Reactie gewijzigd door HKLM_ op 25 februari 2020 12:36]

Het is een simpel foutje maar de gevolgen zijn groot. Met wijsheid achteraf de developer(s) afbranden is nogal gemakkelijk, er kunnen allerlei redenen voor zijn dat dit heeft kunnen gebeuren.

Het is een simpel te testen foutje. Daar ligt hier het probleem. De fout is zo gemaakt, het achterhalen van die fout is óók zo gedaan. Mits er goed wordt getest.

Het kan natuurlijk wel zo zijn dat de engineer niet ook de eerste tester is. (Wat ik op z'n minst bijzonder wil noemen, maar het komt voor bij sommige bedrijven).

[Reactie gewijzigd door Oyxl op 25 februari 2020 15:49]

Normaliter test je in kleine stapjes; mede om te voorkomen dat je testfunctionaliteit zelf ook super complex wordt en/of je dan niet kunt zien waar e.e.a. misging.
Bovendien wil je ook dat je tests (relatief) snel klaar zijn in je pipeline; en dan is testen of naar 2865 gebruikers mailen inderdaad goed gaat niet heel handig En ja, dit was op zich wel te zien met maar 2 gebruikers

Het zou dus zomaar kunnen dat hier (misschien zelfs met allerlei variaties) steeds naar 1 gebruiker werd gemailed; en dat ging prima.
En er is dan blijkbaar niet aan gedacht om naar meerdere klanten achter elkaar te sturen.

Echt vreemd vind ik het niet dat je daar niet aan denkt.

En misschien is er wel aan gedacht, maar dan met assertions dat gebruikers 1, 2, 3 en 4 inderdaad mail kregen, maar dan niet dat die 4 er allemaal precies 1 kregen.

Het is natuurlijk goed mogelijk dat hier wat beter getest had kunnen worden... Echer is het wel lekker makkelijk om te roepen 'moet je maar goed/beter testen'; maar er zijn grenzen aan hoeveel je praktisch gezien kan testen, hoeveel daarvan relevant is (of iig lijkt) en hoeveel edge cases je uberhaupt kon voorzien.
Ik ga er iig niet vanuit dat jij alle code test met het scenario dat er een 'bit flip' in je computer plaatsvindt? Of bij functies die een berekening op een 64-bits integer doet alle 2^64 integer-waarden invoeren en controleren of de uitkomst goed is?

Je maakt een paar goede punten, maar geen van die punten zijn van toepassing op dit specifieke geval. Dít specifieke geval was super makkelijk te testen en, in ieder geval voor dit deel, ook makkelijk als test te omschrijven.

Vervolgens haal je er wat zaken bij die, wederom, niet van toepassing zijn op dit specifieke scenario. Je zegt notabene zelf dat het makkelijk te testen is met 2,4 etc, personen (testaccounts w/e). Hoe complexer de materie, hoe moeilijker te testen en hoe groter het risico dat er onder water iets fout kan gaan. Dit is geen complexe fout. Dit is een denkfout die er 100% uit hoort te komen bij je tests.

Een bedrijf kan zich niet verbergen achter incompetentie wanneer het gaat om het delen van privacy gevoelige informatie.

Dit is geen complexe fout.

Nee, dat zijn de meeste fouten niet. Ik word in deze threads altijd zo moe van mensen die denken perfect te zijn. De definitie van een fout maken is dat er iets gebeurt dat niet de bedoeling was. Maar het gebeurt. Ook jij hebt wel eens iets laten vallen in je leven. Zo moeilijk zijn ledematen niet; een kind kan ze gebruiken. Moeten we jou nu ook af gaan branden omdat je te incompetent bent om iets vast te kunnen houden? Of ooit een verkeerde afslag nam op de snelweg? Of een ingredient voor het avondeten vergeten bent mee te nemen uit de supermarkt?

Nu zal ik je een superduperbizar geheimpje vertellen: de meest domme foutjes komen niet alleen voor bij die onbenullige dingen, maar ook bij het werken met computers én zelfs bij het testen daarvan. Stom he?! In een vliegtuig heb je meerdere backupsystemen, uitgebreide checklists voor alle problemen, verplicht onderhoud op vaste intervallen, jarenlange training van piloten én periodieke hercontroles en om er nog wat zekerder van te zijn zetten we twee van die mensen in de cockpit, en nog steeds storten vliegtuigen neer. Waarbij de piloot net zo dood is als de passagiers, dus die maken heus niet uit onbenulligheid die fouten.

Mijn punt is: fouten zijn een feit van het leven. Dat jij stellig bent dat dat geen valide factor kan/mag zijn is beyond me. En dan hebben we het nog niet eens gehad over andere factoren zoals tijdsdruk, budget, te weinig FTE's etc., maar uiteraard zijn die tot op zekere hoogte wel te verwijten.

Prachtig punt, nu even terug naar het punt waar ik in aangeef dat ik elke dag domme fouten maak, maar dat deze door testen van mijn materie nooit bij de klant terecht komen.

Serieus, mooi dat je er een heel epistel over schrijft, alleen ik vermoed dat het niet op mij slaat

En ja, als je serieus denkt dat je mag goed praten wat hier niet is getest, tja, dan ben ik inderdaad enorm superieur.

P.S. Steeds meer vliegtuigen storten neer door een afname aan onderhoud en, je raad het al, testen.

[Reactie gewijzigd door Oyxl op 25 februari 2020 19:43]

Je maakt je hier enorm druk... Iedereen maakt fouten, anders zou alle software bug vrij zijn.
Ja, dit was mogelijk makkelijks te achterhalen en ja, dit heeft grote gevolgen. Maar mensen maken nu eenmaal fouten.

Ik kan me niet herinneren dat ik ooit bugvrije applicaties heb geschreven.

Of er zitten bepaalde handmatige stappen in het proces waarbij het risico geaccepteerd is dat het fout kan gaan... Vaak met de aanname dat de gebruiker wel weet wat die doet. Toch niet.

Als ze weten wie dit gedaan heeft... meestal is het gewoon een enorme puinzooi achter de schermen bij dat soort bedrijven

Het kan ook zijn dat er druk van bovenaf komt om een deadline te behalen, waardoor testen niet volledig worden uitgevoerd en/of dat er door de druk fouten worden gemaakt. De hoge omes bij vele bedrijven hebben er meestal geen kaas van gegeten, maar zetten wel een deadline en dan kan het makkelijk misgaan....

Misschien dat de communicatie naar een goedkoop webdevelopment bedrijf in India ook niet vlekkeloos verliep

Ja dat grapje heb ik zelf ook een keer gehad. De mail ging echter wel naar mijn eigen mailbox...

Wanneer er alleen één developer op het matje wordt geroepen dan is er iets mis met de cultuur. Lijkt mij dat daar een gezamenlijke verantwoordelijkheid voor is onder een aantal medewerkers.

Tenzij er maar 1 developer is natuurlijk, genoeg organisaties waarbij er maar 1 dev is die voor dit soort dingen 'verantwoordelijk' is.

Ach dit hebben we allemaal toch wel eens gedaan. Ik wil in ieder geval. Shit happens. Uitleggen, oplossen, correcties sturen en door. Kijk er zit een verschil in het vrijgeven van data zoals in dit geval ook gebeurde en het doorsturen van foutieve gegevens, waar het in mijn geval destijds om ging (niet resetten van waardes bij het opstellen van de volgende gegevens die gemaild werd). Dus de laatste kreeg een mail met alle opgetelde gegevens van de voorgaande mailtjes.

Tjah. Tegenwoordig met die hele AVG en dat moeten melden is het wel problematischer geworden als je eens een foutje maakt 😬.

Natuurlijk, ik verwijt niemand iets, maar schets puur de situatie zoals ik me die voorstel. Een fout is zo gemaakt, zelf met uitgebreide geautomatiseerde tests en dergelijke.

Wat je zegt is wel waar; de AVG heeft iedereen 'aware' gemaakt en nu zijn dergelijke dingen ineens nieuws. Terwijl enkele jaren geleden je hier niets van zou horen, dan was het slechts vervelend en wellicht opvallend.

Iedereen kan een foutje maken. Niks aan de hand. Balen dat een aantal klanten er last van heeft gehad. Oplossen en door.
Iemand afbranden op een foutje levert voor niemand iets op.
Vier je fouten!

deze case is echt een schoolvoorbeeld van het ontbreken van een functionele tester.

(cq. dit is waarschijnlijk alleen "technisch getest" (1 testgevalletje erdoor), nagelaten is de gehele functionaliteit kritisch te bekijken/te valideren door een (goede) functioneel tester.

Ik heb hier ooit gesolliciteerd en daarna besloten om er niet te gaan werken. Ze werken er nog met ASP.NET forms en ik geloof dat ze 3 teams hebben met senior, medior en junior. Maar weet het niet zeker meer.

Niet dat het iets uit maakt want kan in elke taal fout gaan natuurlijk.

[Reactie gewijzigd door jeantje op 25 februari 2020 12:58]

Wellicht dat dit kleine artikel een beetje een idee kan geven waar het voor is
https://stackoverflow.com...he-runat-server-attribute

United Consumers is geen energiemaatschappij. Ze regelen als groep wel kortingen op energiecontracten, maar ook Telecom, etc.

Bij telecom en zorg klopt dat ja. Maar bij Energie en gas zijn ze wel echt apart.
https://www.unitedconsume...kt/energieleverancier.jsp

En mocht mijn email adres erin staan incl. Postcode (en mogelijk meer) gaan ze daar ook wat aan doen? Kan ik schadeloos gesteld worden als een bedrijf zo slordig mijn gegevens lekt wat mogelijkerwijs in de toekomst mij schade zou kunnen doen? Dit niet enkel mbt united consumers maar meer als een algemene vraag

Wat is je schade precies dan? Zodra je dat in euro's uit kunt drukken, dan kan dat inderdaad. Maar daar zit ook gelijk het probleem: Wat is je schade?

Dat is net wat er nu sinds AVG veranderd is: louter het feit dat je gegevens gelekt zijn is schade. Je hoeft geen materiele schade aan te tonen. NL had daar niet zo lang geleden ook de primeur mee:
https://www.nu.nl/interne...-voor-overtreden-avg.html

Hoewel de uitleg zoals beschreven in dit artikel complete ongeanuanceerde larie is komt het wel neer op het volgende. De AVG regelt niks met betrekking tot wanneer er sprake is van schade. Wel dat het schade begrip “ruim” uitgelegd dient te worden. Hoe ruim, en welke kaders, daar regelt de AVG niks over. Ook de Europese toezichthouder niet. Daar blijft dus speelruimte over voor de nationale rechter om daar iets van te vinden, met in het achterhoofd houdende dat de term “schade” niet eng toegepast dient te worden.

De gelinkte zaak is van een paar gemeenten die bewust iemands persoonlijke gegevens uitwisselden. Dat riekt naar eigengerecht en zwart maken. Een rechter zal dit waarschijnlijk heel anders wegen dan een geval waarbij een bedrijf dit eenmalig en per ongeluk doet. Er zitten ook alleen maar nadelen voor het bedrijf aan dus je hebt zelfs kans dat de rechter de ontstane negatieve aandacht in de media al genoeg straf vindt.

Die man is een notoire trol. Hij wob't veel en dient dan schadevergoedingen in als de gemeente door de overdaad aan verzoeken niet reageert. Zie hier voor meer info over hoe dat werkt.

Dan stuurt een ambtenaar zijn naam intern door en zegt hij daar 'psychische schade' van te hebben ondervonden. Overduidelijke bait, hoe een rechter daarin mee is gegaan begrijp ik echt niet...

Wettelijk gezien zal hij gewoon gelijk hebben, dus de rechter zal wel moeten. Maar volledig eens, dit is gewoon misbruik.

Wettelijk gezien had het niet mogen gebeuren, maar hij heeft blijkbaar aangetoond dat hij 'schade had'. Dat verwart me vooral.

Mee eens

Owja, dat heb ik toen wel gelezen inderdaad. Dus potentieel gaat het hier nu over 6700 x €500 = €3.350.000

Dat is een mooi bedrag in ieder geval! Ben benieuwd of er Tweakers zijn die dit gaan proberen.

@Ypho misschien?

Die schade hoef je niet zo hard te maken als je misschien denkt kijkende naar recente rechtspraak

Heb je misschien een voorbeeldje?

Mwah… Je moet in Nederland al blij zijn als je je duidelijk aantoonbare schade vergoed krijgt, bij een zaak waarbij de schuld overduidelijk is. Dus ik ben ook benieuwd waar je aan denkt?

De schade van gelekte een gelekt e-mailadres is dat je spam ontvangt lijkt mij. Ik heb 3 email adressen. 1 spam adres, 1 normaal adres en 1 adres voor belangrijke zaken. Deze laatste was altijd spam vrij, totdat er bij een datalek mijn e-mail gelekt werd. Nu heb ik opeens elke dag 20 spam berichten, waardoor belangrijke mail die als false-positive in m'n spambox komt niet meer opvalt. Het lekken van een e-mailadres geeft dus wel degelijk schade.

Daar had ik inderdaad niet bij stil gestaan, en dat vind ik nou een mooi voorbeeld van schade.

Maar wat is dan de schade in euros?
Je moet een nieuw emailadres aanmaken en overal je mailadres wijzigen? Dat is dan in feite je schade. Het kost tijd maar het feit dat je emailadres nu niet meer spamvrij is levert je geen verdere schade op.

Ik heb altijd geleerd dat tijd geld is.
Dus dat het tijd gekost heeft om alles over te zetten en weer een nieuw mailadres aan te maken, moet dan wel in geld uit te drukken zijn toch?

Schade hoeft niet altijd in directe euro's te zijn. Kijk eens naar de vele rechtszaken waarbij de dader een schadevergoeding moet geven aan het slachtoffer, zonder dat hij/zij er financieel op achteruit is gegaan.

Dat is vooral in Amerika ja en gaat over strafrechtelijke zaken.
Hier krijg je een kleine schadevergoeding als je zwaar fysiek letsel hebt maar verder krijg je in NL amper iets.
Wil je hier een civiele rechtzaak starten voor een schadevergoeding dan zal je hem moeten onderbouwen.
En een rechter ziet je aankomen: ' ja ik moest een nieuw emailadres aanmaken en mijn emailadressen overal aanpassen.' Ik denk niet dat je iets krijgt.

Wat is je schade precies dan? Zodra je dat in euro's uit kunt drukken, dan kan dat inderdaad. Maar daar zit ook gelijk het probleem: Wat is je schade?

Wat is jouw schade als jouw naakt fotos worden gepubliceerd zonder jouw toestemming?

Dat vind ik dus een hele goede vraag. Ik kan hem niet beantwoorden, jij wel?

Wat is jouw schade als jouw naakt fotos worden gepubliceerd zonder jouw toestemming?

Dat vind ik dus een hele goede vraag. Ik kan hem niet beantwoorden, jij wel?

Het nadeel is dat de schade al gedaan is, maar de impact pas later bekend wordt. De schade is dat er gegevens uitgelekt zijn die tegen je gebruikt kunnen worden, op allerlei manieren.

Zoiets kan ook direct (psychologisch) schade doen. Iemand kan onzeker worden omdat er foute fotos uitgelekt zijn, of wellicht relaties verliezen (partner, vrienden). Dit soort dingen kunnen in de toekomst altijd weer terugkomen. Wellicht worden je kinderen geconfronteerd omdat een klasgenoot jouw naaktfoto's heeft gevonden. Wellicht vind een nieuwe partner je verleden niet leuk of wordt hij/zij daar onzeker van en kost het een toekomstige relatie. Hoe dan ook, de kans op schade is groot. Dat weten mensen en dat heeft vaak direct al een groot psychologisch effect: jouw foto's staan online en je weet niet of, wanneer en hoe het tegen je keert. Dat alleen al valt bij mij onder schade.

[Reactie gewijzigd door Zenomyscus op 26 februari 2020 12:54]

Enkel als jij kan aantonen dat je financiële schade hiervan ondervind, dan kan je een zaak starten

Dat is simpelweg onwaar. De AVG beschrijft zoals materiële als immateriële schade.

[Reactie gewijzigd door WouterL op 25 februari 2020 12:58]

Juist. En heb je enig zicht op jurisprudentie in NL over immateriële schade.

TL;DR?

Samengevat: valt enorm tegen.

Dat is de strekking juist van mijn verhaal. Ja die zijn er dus wel: twee recente voorbeelden ten opzichte van praktisch nul voor de AVG. Een kanteling op dit punt lijkt dus plaats te vinden. Ik ben je een exacte bronvermelding verschuldigd, maar ik houd ze beroepsmatig goed in de gaten. Het zijn trouwens geen grote bedragen.

[Reactie gewijzigd door WouterL op 25 februari 2020 13:47]

Dan moet je die immateriele schade nog wel in geld kunnen uitdrukken, anders heb je niks.

Dat is dus niet het geval. In beide gevallen is een bedrag “met de natte vinger” uitgekeerd. Je hoeft er dus niet per se immateriële schade uit te kunnen drukken in geld.
In de Deventerse gemeente zaak werd uiteindelijk 500 euro uitgekeerd. Het precieze tot stand komen van dit bedrag is zwaar onderbelicht in deze zaak en wordt ook niet als “deal breaking” geacht. De schade vergoeding wordt “redelijk” geacht.

[rant]Hypocriet dat je eventuele schade vergoed wil hebben, maar wel in een publieke post verraadt dat je daar klant bent. Zo belangrijk is het kennelijk niet voor je.[/rant]

En mocht mijn email adres erin staan incl. Postcode (en mogelijk meer) gaan ze daar ook wat aan doen?

Wat er in de mails staat is het volgende:
In het To: veld staat een hele rits namen en e-mail-adressen.
Wat je dus al hebt zijn de adressen die bij een naam horen. Soms staat daar ook een bedrijfsnaam bij bijvoorbeeld, of meerdere namen uit een gezien.
Waar een mail-lijst op zichzelf niet zo veel zegt, is een mail-lijst waarbij je de juiste aanspreekvorm gebruikt ineens een stuk waardevoller.

Daarnaast is in het subject een zin als "Bekijk uw energieverbruik van januari voor 1000AA- 1", waardoor je ook ziet voor welk adres de oorspronkelijke mail bedoeld was. Niet heel lastig om uit te zoeken wie daar woont.

In de body van de mail staat het 'deelnemersnummer'; ook dat is handige informatie. Gericht phishen wordt daarmee een heel stuk makkelijker, je hebt inmiddels al heel wat informatie en kan bij het contacteren van een slachtoffer al behoorlijk betrouwbaar overkomen.

Alle links in de mail zijn gelukkig universeel; er zijn geen auto-doorlog-links gebruikt.

IANAL maar klinkt als dat je dan een civiele zaak moet aanspannen tegen het bedrijf waar de gegevens zijn gelekt waarbij jij in eerste instantie moet aangeven wat je (im)materiële schade is. En de rechter zal dan bepalen aan de hand van het weerwoord van het bedrijf of een schadevergoeding op zijn plaats is.
Maar het aantonen van de schade die je hebt geleden zal nogal lastig zijn want hoe bepaal je dat en hoe toon je aan dat je een, bijvoorbeeld, een jaar na dit lek alsnog er last van krijgt. Wie zegt dan dat er ergens anders niet ook data gelekt is oid?

for each (user in allusers)
sendusermailto(allusers)

Altijd leuk, testcode in de productie

Elk bedrijf dat echte data in zn testssets gebruikt wat niet degelijk corrupt is gemaakt zou zich moeten schamen (en opgedoekt moeten worden) xD het zal hier niet het geval zijn geweest maar het komt idd voor.

Het ging hier om testcode die mogelijk achtergebleven was in de productiecode...
Maar wat je hier aangeeft kan ook. Dat een test daadwerkelijk data is gaan verzenden. Zou alleen wel knap stom zijn om een volledig werkende mailserver aan een testomgeving te hangen. Maar het kan. Zeker voor een finale e2e test.

Wat de testdata betreft... In basis is het niet toegestaan om productiedata te gebruiken voor testen, tenzij je op enige manier aannemelijk kunt maken dat dit nodig is. En helaas is dat heel gemakkelijk aannemelijk te maken.... Dat gebeurt dus ook volop. Als bedrijven die dit doen daadwerkelijk op zouden moeten doeken zouden er weinig bedrijven overblijven en zouden de meeste overheids instanties trouwens ook meoten sluiten... Heb aardig wat bedrijven/instanties van binnen gezien als tester en tot op heden nog niet één bedrijf dat helemaal geen productie data gebruikt t.b.v. testen. Gelukkig wordt het wel steeds beperkter (ook steevast één van mijn speerpunten).

Hij bedoelde het natuurlijk niet zo met het opdoeken, het was eerder grappig bedoeld denk ik (aan de "xD" te zien geloof ik)...

Als bedrijven hiervoor al moeten opdoeken zou het idd niet best aflopen .
Is ook wel wat scheef als dat zou kunnen, want als ze gewoon willens en wetens meerdere malen prijsafspraken maken (aka philips en partners) dan krijgen ze gewoon een niet-al-te-hoge boete, want de overheden willen juist voorkomen dat de boete het bedrijf de nek omdraait.

Maar het is ook wel leuk er over te fantaseren vind ikzelf, want sommige bedrijven verdienen het gewoon niet om overeind te blijven na al hun ge-kut. (om het maar even kort maar krachtig te zeggen)

Amen to that.... Met name die laatste opmerking.... Ik heb eigenlijk nog maar weinig bedrijven/instanties gezien waar écht met productiedata getest moest worden. Toch gebeurde het letterlijk overal.... Daar zou wat mij betreft best strenger tegen opgetreden mogen worden... Dus opdoeken als je zo met je data blundert? Voorlopig geen optie. Maar an sich vind ik het helemaal; geen gek idee.

Altijd leuk, testcode in de productie

't Kan natuurlijk zijn dat ze het in hun testomgeving met een lijstje van slechts 1 of 2 accounts hebben getest en die loop niet opviel

Tot wat jaren terug was ik hier klant, je kon toen gewoon inloggen met je klantnummer en postcode. Volgens mij kon je dat toen ook niet wijzigen. Echt supersafe ook

edit: typo

[Reactie gewijzigd door evan_nl op 25 februari 2020 12:57]

Kan dat nu niet meer? Heb geen gegevens om dat te reproduceren, maar dat zou wel een probleem zijn...

Ik ben nu geen klant meer maar heb nog even in mijn oude mail terug gezocht. Daar kom ik het volgende tegen uit juli 2016. Tot die tijd was het inloggen met klantnummer en postcode dus de enige methode:

Beste XXX

Wij willen uw persoonlijke gegevens graag nog beter beschermen. Daarom vragen wij u nieuwe inloggegevens in te stellen. In plaats van uw deelnemernummer en postcode gaat u in het vervolg inloggen met een inlognaam en wachtwoord op Mijn UnitedConsumers. Uw inlognaam is meestal gelijk aan uw e-mailadres.

Stel uw nieuwe inloggegevens in
Klik op onderstaande button. Hierna wordt u stapsgewijs uitgelegd hoe u uw nieuwe inloggegevens kunt instellen. Dit neemt slechts een paar minuten in beslag.

vandaag de dag is het gewoon met e-mail en WW. en dit is nu een jaar of 3 al zo. daarvoor was ik nog geen klant bij hun.

Ik heb persoonlijk 3248 mail adressen in de CC in één van de 3 e-mails die ik heb ontvangen. De rest niet eens gekeken omdat het laden op mijn telefoon te lang duurt. Benieuwd naar het staartje dat dit krijgt.

Lekker goed onderzocht artikel. Sinds wanneer is United Consumers een energiemaatschappij?
Het is gewoon een referral toko die geld verdient als je via hun een product afneemt bij een 3e partij.

Technisch gezien levert de netbeheerder jou de energie; alle overige partijen (die we als energiemaatschappijen zien) doen dat dus niet, maar kopen alleen in en verkopen dat aan jou.
Vanuit dat licht bezien is UC niet anders; ik heb een contract bij hen, en krijg een factuur van hen.

Ik kan het niet zo goed zien, maar krijg wel heel erg het idee dat UC meer een soort reseller is van een bestaande energiemaatschappij waarbij de facturatie uiteindelijk via UC gaat.

Maar ja dat maakt ook allemaal niets uit en heeft ook niets te maken met het nieuwsbericht zelf dat ze een hele berg privé-gegevens hebben gelekt. Zulke partijen krijgen van mij wel dikke minpunten en kleine kans dat ik daar dan nog zaken mee doe in de nabije toekomst.

Met energie doen ze het wel iets anders. https://www.unitedconsume...kt/energieleverancier.jsp

Bij zorg telecom etc. Zijn ze wel een soort reseller.