Kaartjesdienst Omapost laat namen van drie klanten naar alle anderen uitlekken

De Nederlandse dienst Omapost heeft per ongeluk notificaties gestuurd naar de verkeerde gebruikers. De dienst stuurde de namen van drie personen naar mogelijk tienduizenden verkeerde afzenders. Volgens Omapost ging het om een test die verkeerd ging.

Met Omapost kunnen gebruikers fysieke kaartjes per post naar anderen sturen. Ook kan via de app een notificatie worden gestuurd naar iemand die jarig is. Bij een test op maandag verstuurde Omapost per ongeluk de namen van drie personen naar verkeerde ontvangers.

Omapost zegt tegen Nu.nl dat het kan gaan om tienduizenden ontvangers. Daarbij zijn de verjaardagen van de personen zelf niet verstuurd. De notificatie werd gestuurd 'op de dag dat een gebruiker vorig jaar een kaart verstuurde', zegt Omapost tegen Nu.nl. Dat hoeft niet per se een verjaardagskaart te zijn.

Volgens Omapost ging het om een fout. De personen waarvan de naam werd verstuurd, waren niet gekoppeld aan een andere gebruiker. Omdat zo'n koppeling ontbrak, werden de namen naar alle gebruikers van de dienst gestuurd.

Omapost zegt dat het melding van een datalek heeft gedaan bij de Autoriteit Persoonsgegevens.

Reacties (69)

[Neus]

Waarom is dit een datalek? Er is gewoon iets fout in hun software en deze heeft automatisch notificaties verstuurd; dat is toch geen lek?

[Frituurman]

Zodra er persoonsgegevens van iemand (die daar geen toestemming voor heeft gegeven) onbedoeld naar een andere persoon of instantie worden gestuurd, moet dat gemeld worden en valt het onder 'datalek'.

Bij een datalek gaat het om toegang tot of vernietiging, wijziging of vrijkomen van persoonsgegevens bij een organisatie zonder dat dit de bedoeling is van deze organisatie. Of zonder dat dit wettelijk is toegestaan.

Bron...

[Reactie gewijzigd door Frituurman op 28 juli 2024 02:43]

[DeDooieVent]

Zoals je contactenlijst bij Whatsapp bijvoorbeeld? Ik heb nog nooit iemand horen vragen of ik het erg vond dat mijn naam en telefoonnummer met Facebook wordt gedeeld, en eigenlijk vind ik dat wel erg.

[Frituurman]

Dat is niet onbedoeld en daar heb je waarschijnlijk, door het accepteren van (gewijzigde) voorwaarden, toestemming voor gegeven. Denk daarbij aan de Human Cent-I-pad

[Arnoud Engelfriet]

Dat heb je niet en WhatsApp heeft geen toestemming om dit te doen. Sterker nog, vanwege aansporingen van onze eigen AP heeft WhatsApp het nu anders gebouwd: niet je adresboek wordt geupload maar een hash van je adressen, zodat ze kunnen vergelijken met hun eigen bestand (X heeft al een WhatsApp account, Y kennen we niet) maar de adressen van onbekenden niet kunnen hergebruiken.

Humancentipad was geen legal advice.

[sir_knudde]

Heb je een verwijzing voor me waar ik meer informatie kan vinden over het hashen van de contacten door Whatsapp?

[Arnoud Engelfriet]

nieuws: WhatsApp slaat telefoonnummers niet-gebruikers gehasht op na kritiek CBP

[Verwijderd]

Ik wist niet dat ze dit hadden doorgevoerd. Bedankt.

Wel jammer dat dat uiteraard weer pas gebeurd nadat alle schade al is gedaan en bijna iedereen WhatsApp heeft.

[Robbaman]

Maar... een telefoonnummer is (wereldwijd) maar maximaal 15 cijfers ofzo. Om hier een rainbow-table van te maken lijkt me een eitje.

Wat hebben ze hier nog aan toegevoegd om dit te voorkomen dan?

[Mushroomician]

Wat het AP vergeet is dat een hash van een telefoonnummer is nog steeds een uniek gegeven is, en dus een persoonsgegeven.

Het is misschien niet (direct) omkeerbaar, maar dat neemt niet weg dat het wel uniek en dus herleidbaar is.

Vb. Persoon A upload hash xyz,
persoon b upload hash xyz.
xyz is dus een relatie van beide = pers. gegeven

En daarbij, aangezien alle wereldwijde mobiele telefoonnummers ongeveer 10^8 aantallen zijn per land, is het ook niet moeilijk om deze alvast van te voren te hashen, en dus ook de hash reversen mogelijk maakt.

Edit:
In Nederland zijn alle mobiele telefoonnummers tussen 06-00000000 en 06-99999999 dus 99999999 stuks. (100 miljoen -1)
Veel meer dan het aantal mensen en zelfs deze kun je allemaal in een paar minuten hashen op een beetje computer.

Edit2:
Ik heb net in 106 seconden op één core (i7) (zonder multithread dus) alle Nederlandse mobiele nummers in het 06-xxxxxxxxx domein gehashed:

from hashlib import sha256
import time
def test():
lowest = 600000000
highest = 699999999
start = time.time()

while lowest <= highest:
hashed = sha256(("0"+str(lowest)).encode('utf-8')).hexdigest()
lowest +=1

end = time.time()
print((end-start) + "seconds elapsed")
test()

_{(tabs zijn verdwenen in commentopmaak)}

Het hashen is gewoon een extra stap waardoor het oke lijkt voor mensen die het niet begrijpen, maar heeft dezelfde waarde als een plain-text telefoonnummer.
Dat/als het AP nu zwijgt zegt ook wat over hun expertise.

[Reactie gewijzigd door Mushroomician op 28 juli 2024 02:43]

[Arnoud Engelfriet]

Dat vergeten ze helemaal niet. Het is WhatsApp helemaal niet verboden om deze persoonsgegevens te verwerken, ze moesten het alleen op de veiligste/minimaalste manier doen. Het is toegestaan om in een adresboek te kijken of je daar mensen uit kent, zodat je die kennissen uit kunt nodigen in jouw game of dienst. Je mag alleen niet kijken naar mensen die je niet kent.

Een hash is een beveiligingsmaatregel om dergelijke dataminimalisatie door te voeren. Het anonimiseert zeer zeker je data niet - dit is de grootste fout van veel partijen die stellen dat ze "geanonimiseerd" met persoonsgegevens werken.

Je kúnt prima en legaal werken met een hash ipv de ruwe gegevens. Je moet het even onderbouwen en analyseren maar het kan. Je moet alleen niet denken dat een hash je ontslaat van de AVG.

[DeDooieVent]

Maar ik heb zelf helemaal geen whatsapp en ook nooit iets geaccepteerd. Dat is toch krankzinnig?

[Fluttershy]

Het is ook niet jouw contactenlijst die naar FB gaat maar die van je vrienden.

Daar staan gegevens in die onder hun beheer vallen en waar zij de voorwaarden voor accepteren.

[Verwijderd]

En gezien zij dan je gegevensverwerker zijn zijn zij volgens de AVG verantwoordelijk (als je een bedrijf was). Maar de meeste mensen gaan natuurlijk niet hun vrienden aanklagen.

Wat mij betreft is WhatsApp gewoon bewust nalatig. Zij verwachten dat je met iedere contactpersoon in je telefoon een verwerkersovereenkomst hebt. Wat natuurlijk niet zo is. Is ook niet nodig: gezien ik een prive persoon ben en hier geen zakelijke overeenkomst is. De overeenkomst tussen een gebruiker en WhatsApp is echter wel zakelijk.

In mijn ogen is WhatsApp dus de verwerker en zouden zij dit niet mogen doen zonder de expliciete toestemming van de personen die het betreft (je contactpersonen). Je mag dit niet afschuiven op een privé persoon.

[Fluttershy]

En gezien zij dan je gegevensverwerker zijn zijn zij volgens de AVG verantwoordelijk (als je een bedrijf was). Maar de meeste mensen gaan natuurlijk niet hun vrienden aanklagen.

Ik heb een eenmanszaak op mijn naam staan; moet ik nou bij iedere update van Whatsapp een melding doen van een datalek als bedrijf zijnde?

[DeDooieVent]

Nu betreft het in mijn geval een door mijn werkgever verstrekt mobiel met als doel hier ook mail op te ontvangen, tenminste dat was een aantal jaar terug de intentie. Ik constateer echter dat iedereen ook whatsapp heeft geïnstaleerd.

Mijn werkgever betreft een vrij groot adviesbureau en heeft voor de invoering van de AVG een speciaal team. Ik heb melding gemaakt van het feit dat mensen eerst hun contactlijst met exchange synchroniseren en vervolgens deze lijst met whatsapp delen.

Naar mijn idee is dit een lek, want, we vragen geen toestemming aan onze ocntacten om hun gegevens te delen met facebook, maar we doen dit massaal.

Mijn werkgever stelt echter dat Whatsapp door iedereen wordt gebruikt en dat is dan het antwoord waar je het mee moet doen.

Ik vind dit zo ongelofelijk merkwaardig, enerzijds moet ik door allemaal hoepels springen door die AVG maar anderzijds deelt iedereen kennelijk persoonlijke gegevens van klanten en leveranciers, en dan krijg je als redenatie "iedereen gebruikt het"

heel merkwaardig

[MacBreQ]

Zoals hierboven al verduidelijkt: WhatsApp (cq. Facebook) verwerkt geen telefoonnummers. Client-side hasht de Whatsapp client alle contactnummers naar hashes. Deze hashes, die (aannemelijk) niet terug te draaien zijn naar telefoonnummers, worden vervolgens naar de servers van Whatsapp verstuurd, waar gekeken wordt welke contacten wél (hash komt in hun database voor, icm telefoonnummer van die Whatsapp-gebruiker), en welke niet Whatsapp (hash komt niet voor in database) heeft.

[Frituurman]

Sorry.. ik lees dit nu pas. Je zei:

Zoals je contactenlijst bij Whatsapp bijvoorbeeld? Ik heb nog nooit iemand horen vragen of ik het erg vond dat mijn naam en telefoonnummer met Facebook wordt gedeeld, en eigenlijk vind ik dat wel erg.

Daarbij ging ik er vanuit dat jij je lijst onbedoeld (blijkbaar) vanuit Whatsapp met Facebook deelde. Nu zeg je dat je geen WhatsApp hebt. Dus wel Facebook? Wie heeft jouw gegevens gedeeld? Tsja.. iedereen die bij een app toestemming geeft om in je 'Contacten' te kijken, het te wijzigen, etc. doet daar aan mee, natuurlijk. Dan kun jij wel geen WhatsApp hebben of Facebook, maar als iemand anders zijn of haar contactenlijst met jouw gegevens daarin deelt, dan is het kwaad al geschiedt. Ik ben juridisch niet helemaal onderlegd (op wat arbeidsrecht in 2001-2005 na), dus daar kan ik niet echt over oordelen. Het oogt 'schimmig'.

@Arnoud Engelfriet En mijn verwijzing naar Human-Cent-I-Pad was ook een grapje, geen juridisch advies. Ik ben ook geen jurist, zit slechts in het testvak. Maar er zit wel een kern van waarheid in de kleine lettertjes lezen, natuurlijk.

[wankel]

Nu zeg je dat je geen WhatsApp hebt. Dus wel Facebook?

Sorry dat ik de thread kaap, en zout leg op een misschien ongelukkig geformuleerde vraag. Hoezo de conclusie "dus wel Facebook", als iemand geen WhaatsApp heeft?

Ik sluit me helemaal aan bij dedooievent en andere klagers: ik ben er niet van gediend dat mijn persoonlijke contactgegevens worden gedeeld met willekeurige monopolisten in de VS en in allerlei datasets terechtkomen.

Dat er blijkbaar tegenwoordig hashes geupload worden is natuurlijk too little, too late om de schade ongedaan te maken.

Die bedrijven hadden nooit aanspraak mogen maken op de persoonlijke contactlijsten van gebruikers van hun software. Ook niet onder het mom van: "Maar dat maakt het zo makkelijk, anders kunnen we niemand onze software door de strot duwen."

- edit- Bedankt voor de toelichting :-)

[Reactie gewijzigd door wankel op 28 juli 2024 02:43]

[Frituurman]

Ik las zijn bericht verkeerd, vandaar dat ik ook 'sorry' zeg. En ik stel niet dat hij wel Facebook heeft, maar ik vráág het. En geef later ook nog de mogelijkheid dat het dus door andere gebruikers kan komen die toestemming geven om hun contactenlijst te delen. Ik zeg verder ook niet dat ik het oneens ben met hem. Ik noem het zelfs schimmig.

[DeDooieVent]

ik heb geen Facebook en geen Whatsapp, maar whatsapp is van facebook en door al dat gedeel kan men een aardig beeld krijgen wie ik ben, dit is tegen mijn explicite wens in.

[TimDJ]

Het probleem is dat je vrienden jou naam en telefoonnummer delen met Whatsapp

[FreshMaker]

Dan mag je in principe een aangifte wegleggen hierover, tegen de betreffende persoon in kwestie.
Maar dan moet je wel consequent zijn, en iedereen daarin meenemen, dus ook tante Toos, en opa Henk

Of het nuttig is
( of er moeten er meer zijn, die dit gaan doen )

[Verwijderd]

Wat mij betreft is WhatsApp gewoon bewust nalatig. Zij verwachten dat je met iedere contactpersoon in je telefoon een verwerkersovereenkomst hebt. Wat natuurlijk niet zo is. Is ook niet nodig: gezien ik een prive persoon ben en hier geen zakelijke overeenkomst is. De overeenkomst tussen een gebruiker en WhatsApp is echter wel zakelijk.

In mijn ogen is WhatsApp dus de verwerker en zouden zij dit niet mogen doen zonder de expliciete toestemming van de personen die het betreft (je contactpersonen). Je mag dit niet afschuiven op een privé persoon.

Ik denk dat je de rechtzaak wint. WhatsApp kan ook heel makkelijk hun beleid aanpassen: alleen telefoonnummers accepteren van mensen die zélf al WhatsApp hebben. Maar dat is natuurlijk niet wenselijk voor hun expansiedrang. Alhoewel de penetratiegraat nu wel zo hoog is dat ze er mogelijk mee in zouden stemmen.

Edit:
Ik lees net in de reactie van Arnoud Engelfriet hieronder dat exact mijn voorgestelde wijziging dus al is doorgevoerd. Uiteraard nadat practisch iedereen al WhatsApp had...

Arnoud Engelfriet in 'nieuws: Kaartjesdienst Omapost laat namen van drie klan...

[Reactie gewijzigd door Verwijderd op 28 juli 2024 02:43]

[wnwiigrtz]

Je hoeft als contactpersoon zelf geen toestemming te geven. Als iemand anders dat doet en jij staat in zijn/haar adresboek dan gaan jouw naam en telefoonnummer gewoon de Facebook-database in.

[don spike]

Dat is niet onbedoeld en daar heb je waarschijnlijk, door het accepteren van (gewijzigde) voorwaarden, toestemming voor gegeven.

Ik heb geen toestemming gegeven dat andere hun gehele adresboek delen met externe partijen zoals bijvoorbeeld Facebook/WhatsApp. Waardoor deze toegang hebben tot mijn volledige naam, telefoonnummers, e-mail adressen, woon adres, geboortedatum, et cetera?
Veel gegevens kan je niet geheim houden naar vrienden en kenissen, die weten immers waar je woont, wanneer je jarig bent, etc cetera....

[crackletinned]

De drie namen en het feit dat zij gebruik maken van de dienst zijn buiten bedoeling bekend geworden.
Lijkt me niet dat het uit maakt hoe dat gebeurde.

[kcNL]

Het is een lek omdat onbedoeld persoonsgegevens bij mensen terecht is gekomen waar dat niet had moeten zijn.

[Foxtrot3309]

Datalek is een redelijk ruim begrip. gegevens (data, in dit geval namen) zijn in handen gekomen van derden zonder dat dit de bedoeling was.

als je datalek alleen ziet als een criminele actie dan kan mijn bedrijf rustig:
oude HDDs op straat gooien
de server online gooien met het wachtwoord "password1"
emails sturen met iedereen in het "to" veld ipv "bcc"

[Verwijderd]

Datalek wordt tegenwoordig natuurlijk geassocieerd met gigantische databases en creditcards die voor iedereen te downloaden zijn. Maar al was het één naam die bij één andere gebruiker neer kwam dan zou dit een datalek zijn. De grootte ervan maakt in die zin niet zo veel uit, dat heeft alleen gevolgen voor mogelijke boetes natuurlijk. Tenminste, het lijkt me raar als 3 namen even hard wordt bestraft als plain text creditcard gegevens van 10000 gebruikers bijvoorbeeld, maar beide zijn een datalek.

[Frituurman]

Dus een test met productiegegevens? Geen ontwikkel of acceptatie-omgeving waar dit soort dingen getest kunnen worden tegen een geanonimiseerde of fictieve DB? Ik wou geen waardeoordeel geven, maar dat is wel slecht. En ik weet dat het op veel plekken ook niet goed gaat, maar bij mijn (voormalig) werkgevers zaten we hier jaren voor de invoering van wetgeving omtrent dit punt al bovenop.

@Martijntj Kan.. maar dan had je tijdens de ontwikkel/acceptatiefase toch wat beter door moeten testen.

@frickY Misschien heb ik het geluk dat ik bij werkgevers heb gewerkt die persoonsgegevens van miljoenen mensen op productie hebben staan; dat daar iets mee moest was eigenlijk altijd wel duidelijk. In de periode 2008-2012 werd bij de meeste de omslag gemaakt naar geanonimiseerd. Inmiddels is dat op meer plekken fictieve data geworden. Blijft wel lastig om de dataset zo volledig mogelijk te houden, zeker in een omgeving, bijvoorbeeld zorgverzekeraars, waar tal van uitzonderingen en business rules bestaan.

@pagani Omapost geeft zelf het volgende aan:

Volgens Omapost ging het om een fout. De personen waarvan de naam werd verstuurd, waren niet gekoppeld aan een andere gebruiker. Omdat zo'n koppeling ontbrak, werden de namen naar alle gebruikers van de dienst gestuurd.

Als er een acceptatieomgeving was om op te testen én de data was representatief (geanonimiseerd of fictief én inclusief onderlinge relaties, dus een zo volledig mogelijke dataset), dan was dit probleem 100% zeker boven water gekomen in de acceptatiefase (met capabele testers, in elk geval). Sowieso had dit iets kunnen zijn wat in de ontwerpfase al aan het ligt had kunnen komen (als koppeling ontbreekt, dan niet verzenden; zeker niet een send to all )

[Reactie gewijzigd door Frituurman op 28 juli 2024 02:43]

[Martijntj]

Of een falend testprotocol. Het ging goed in dev, maar iets minder goed in productie. (-;

[The Zep Man]

Of een falend testprotocol. Het ging goed in dev, maar iets minder goed in productie. (-;

Daarvoor heb je een acceptatieomgeving. Gelijk aan productie, maar met fictieve (representatieve) data en niet destructief wanneer het fout gaat.

[Reactie gewijzigd door The Zep Man op 28 juli 2024 02:43]

[pagani]

Alles leuk en aardig, maar als je in die fictieve data niet een gebruiker hebt opgenomen die niet is gelinkt aan een andere gebruiker heb je alsnog dit probleem.

Ook zijn testprotocollen vaak enkelvoudig (je test voor één gebruiker of iets werkt), waar er ook fouten kunnen optreden bij de tweede gebruiker (zo heb ik ooit meegemaakt dat alle producten na een update ineens hetzelfde recept hadden in een productiesysteem, enkel de eerste van de lijst klopte en die was uiteraard getest én gevalideerd).

Daarnaast kunnen er nog fouten optreden die je alleen onder load krijgt (bijvoorbeeld bij de combinatie multithreading en snelheidsgeoptimaliseerde databases zonder al teveel controles in de database-engine) of fouten door het overlopen van buffers/integers/datum/tijd etc.

Tot slot heb je in je acceptatie-omgeving vaak niet alle data en systemen tot je beschikking en simuleren gaat niet altijd. Vooral integratietesten kun je vaak pas op de productieomgeving doen. Uiteraard test je dan weer niet álle data, dus kun je weer terug naar het begin van mijn betoog.

Je laat het klinken alsof je met een acceptatieomgeving alles afvangt, maar dat is slechts schijn.

[The Zep Man]

Alles leuk en aardig, maar als je in die fictieve data niet een gebruiker hebt opgenomen die niet is gelinkt aan een andere gebruiker heb je alsnog dit probleem.

Als dat zo is dan is je fictieve data niet representatief. Linken van data kan je dankzij relationele databases afdwingen. Als dat niet wordt gedaan, dan moet je ook records hebben die geen data linken.

Testen met vuile data is net zo belangrijk als testen met correcte data.

Je laat het klinken alsof je met een acceptatieomgeving alles afvangt, maar dat is slechts schijn.

Dat is wat jij erin leest. Mijn commentaar was op "Of een falend testprotocol. Het ging goed in dev, maar iets minder goed in productie". Als je geen acceptatieomgeving hebt, dan ga je zaken missen. Het vangt niet alles af, maar dit soort domme fouten kan het zeker afvangen (mits de data representatief is).

[Reactie gewijzigd door The Zep Man op 28 juli 2024 02:43]

[pagani]

Dan nog, als ze die specifieke gebruiker dan niet getest hebben kom je de bug niet tegen. En kom nou niet aan met "dan moeten ze alle gebruikers met alle activiteiten testen", want dat is compleet onrealistisch (miljarden zo niet meer combinaties)

[The Zep Man]

En kom nou niet aan met "dan moeten ze alle gebruikers met alle activiteiten testen", want dat is compleet onrealistisch (miljarden zo niet meer combinaties)

Je moet niet alle gebruikers testen, maar alle soorten gebruikers. Dat zijn nog steeds veel combinaties, maar niet miljarden.

Niemand heeft gezegd dat testen makkelijk is. Als er echter geen acceptatieomgeving is dan houdt dat in dat bij een gebrek aan OTAP het testtraject zeer waarschijnlijk niet op orde is, als het al bestaat.

En nee, 'testen op productie' is niet testen. Dat is spelen met vuur. Iedereen kent wel dat verhaal van die firmware update vijf minuten voor een live event, of een kleine maar belangrijke aanpassing aan een website net voordat deze live gaat. Gewone beheerders doen dit even tussendoor. Goede beheerders onder druk ook, maar wel met een zweet in de bilspleet gevoel.

[Reactie gewijzigd door The Zep Man op 28 juli 2024 02:43]

[pagani]

Alsnog, veel integratietesten kun je slechts deels simuleren. Dan zul je alsnog iets in productie moeten testen. En dan nog ondervang je geen issues onder load/threadingissues e.d.

Ik heb dan ook in 13 jaar in de industrie nog nooit meegemaakt dat een inbedrijfstelling van een systeem zonder fouten ging (die wél goed gingen in acceptatie)

[Reactie gewijzigd door pagani op 28 juli 2024 02:43]

[The Zep Man]

Ik heb dan ook in 13 jaar in de industrie nog nooit meegemaakt dat een inbedrijfstelling van een systeem zonder fouten ging (die wél goed gingen in acceptatie)

Leuke anekdote, maar voegt weinig toe aan de discussie. Nergens wordt geclaimd dat een acceptatieomgeving alles afvangt.

[pagani]

Nee, je claimt dat je alles in acceptatie test. Dat is het punt van de anekdote, dat kan vaak niet.

[The Zep Man]

Nee, je claimt dat je alles in acceptatie test.

Citeer mij eens waar ik dat doe.

[Frituurman]

Deels simuleren klinkt net alsof het allemaal net niet is. Een goede acceptatieomgeving heeft naast productielike data ook (waar nodig) koppelingen met acceptatieomgevingen van externe partijen, etc. Vrijwel alles is dan mogelijk. Behalve dan wellicht betalingen doen met iDeal (tuurlijk zijn er meer te noemen), maar dat is met een iDeal-testomgeving wel redelijk te ondervangen.

Doel je op performance? Daar zijn veel mogelijkheden om dat te ondervangen. Als dat bij je werkgever een probleem is; wij hebben goede ervaringen opgedaan met experts van Computest en Expleo (de Ierse tak, met name! Tony, if you're reading this, you're the best!) en zeer gedetailleerde performancetest over een performance keten (identiek aan acceptatie, maar met productielike hardware; duur geintje, maar wel de enige manier om de piek te kunnen ondervangen). Op het gebied van performance, load en stress hadden we perfect inzicht.

[Reactie gewijzigd door Frituurman op 28 juli 2024 02:43]

[pagani]

Veel machineleveranciers (ik heb het dus over de industrie) hebben weinig focus op de automatisering en meer op het werktuigbouwkundige aspect. Als je dan interfaced met die machines (99% van mijn werk) is volledige simulatie praktisch onmogelijk. Áls je dat wil gaan simuleren, zul je een digital twin (bah, modewoord) moeten gaan maken die ook het werktuigbouwkundige aspect simuleert (immers heeft dat direct invloed op al je sensoren en data)

Verder voor de omapost-case minder relevant, die hebben waarschijnlijk weinig integratie met andere systemen en daar ligt zeker niet de oorzaak van deze fout.

[Reactie gewijzigd door pagani op 28 juli 2024 02:43]

[Chris_147]

Tja, het simuleren van het werktuigkundige heb ik toch bij verscheidene klanten gedaan.
Maar ja, kost geld. Gemakkelijke besparing (denkt men)

[pagani]

Mee eens hoor, maar je ziet dat het geen prio heeft

[Scriptkid]

Productie kom je altijd dingen tegen die niet in een test voor kwamen,

ook al doe je ODAP - die laatste letter is TESTEN in productie voordat je de oplossing accepteerd.

[OxWax]

In welke definitie is die "P" = testen?
https://acronyms.thefreedictionary.com/ODAP

[pagani]

Je systeemacceptatietest (SAT) doe je toch echt in productie.

[Fluttershy]

P = Productietest

[Tylocke]

P staat voor ‘Proberen’

Komt voor genoeg voor helaas.

[Scriptkid]

Alle bedrijven hebben een test omgeving,

Sommige bedrijven hebben gelukkig een productie omgeving

[Scriptkid]

OTAP en ODAP zijn NL afkortingen

Ontwikkel
Test / Develop
Acceptatie
Productie

[OxWax]

Heyyyy toch iemand

[Snow_King]

Zou je zeggen wellicht. Maar die is duur om te hebben en te onderhouden. Zeker als je niet de schaal hebt.

Impact bij Omapost is laag lijkt het en daarom zal er eerder met productie worden getest dan een hele OTAP straat op te tuigen. Waarom? Kosten. Simpel zat. Het kost simpelweg te veel om het allemaal te onderhouden. Welkom in de echte wereld.

[latka]

In dit geval lijkt het erop dat testen met productiegegevens beter was geweest. In dev waren er blijkbaar geen slingerende accounts die er in prod wel waren. Verder: heb wel eens een db mogen zien die ge-anonimiseerd is. Dat is of waardeloos gedaan (maw. voornaam en achternaam kolom omgedraaid en roepen dat het fictief is), of het is zo goed gedaan dat bepaalde tests niet meer werken (sha-1 van alle achternamen en dan base-64 zodat iedereen ineens een achternaam heeft die veel langer is. Kun je je opmaak weer niet testen en de index op je DB ook niet meer werkt want iedere achternaam is uniek...). Wat ik wel weet is dat het heel duur is om dit heel goed te doen en meestal de kosten niet tegen de baten opwegen om dit in te richten. Een kopie van productie naar dev en de mail-server stekker eruit in dev kost een half uur. Leg dat dan maar uit aan diegene die het geld beheert....

[stunn0r]

Er zijn prima tools om "fake" data te produceren. Bijvoorbeeld https://github.com/fzaninotto/Faker. Zoals je kan zien is deze tool gebaseerd op vergelijkbare tools voor andere talen. Dit kan je gebruiken om je dev/test database te seeden, maar kan je ook gebruiken in je geautomatiseerde tests.
Het ging hier ook niet om "slingerende gebruikers", maar "oma's" waar geen gebruiker aan is gekoppeld. Dit had ook door middel van geautomatiseerde tests en/of peer reviews aan het licht kunnen komen. Waarom zou je een willekeurige gebruiker, of blijkbaar alle gebruikers selecteren als een "oma" niet gekoppeld is aan een gebruiker? Het lijkt mij dat je over dergelijke cases denkt tijdens het ontwikkelen van het product.

[Frituurman]

Testen met productiegegevens is vrijwel altijd een slecht idee. Ik heb ook vaak genoeg gehoord over acceptatie-omgevingen die, omwille van het gemak, gelinked waren aan een exchange-omgeving die niet dicht was gezet naar buiten toe. Hoewel gegevens fictief zijn of geanonimiseerd, komt het dan toch nog wel eens voor dat er mails naar buiten komen. Erg slecht en betreurenswaardig.

Dat anonimiseren duur is, dat ben ik met je eens. Bij een vorige werkgever was er een team 'Testdatamanagement' die met eigen scripting en wat support van DatProf er wel in geslaagd waren. Daarnaast haal je anonimiseren en fictief door elkaar. Anonimiseren heeft als doel dat klantgegevens op geen enkele wijze meer herleidbaar zijn naar een werkelijke klant. Kolommen omwisselen heeft daarbij geen zin. Bij BSN's loop je er wel tegenaan dat je niet weet welke wel en niet in gebruik zijn. Als ik mijn eigen BSN opzocht in de geanonimiseerde database had ik vaak een prachtige buitenlandse achternaam, 2 of 3 mooie voornamen, 5 kinderen, geen vrouw en woonde ik in hartje Middelburg.

Een fictieve dataset is mogelijk nog veel lastiger, omdat je in plaats van het anonimiseren van een bestaande populatie, eerst moet inventariseren wat voor dataset je eigenlijk nodig hebt. Dat kan voor een financiële afdeling veel anders zijn dan voor een polisadministratie of een webteam. Toch moeten al die gegevens ook aan elkaar gelinked kunnen worden, zodat je over de gehele keten een werkbaar geheel hebt.

[frickY]

De meeste bedrijven waar ik binnen ben geweest hebben dit niet op orde. En daar waar dat wel is lopen ook nog steeds developers rond die denken dat je best even wat productie-data op een non-productie omgeving kunt laden.

[Aelyss]

Dit is prima, zo lang je geen privacy gevoelige data van klanten gebruikt. Vaak zijn bepaalde productie omgevingen, zeker in multi-tenent setups, zeer moeilijk om precies na te bootsen in een test omgeving. Dan spreek ik over duizenden combinaties van vlaggetjes, settings etc. Dit is ook productie data, echter geen privacy gevoelige data. Heb je bijvoorbeeld verkopen gekoppeld aan klanten -> anonimiseer deze data.

[RVervuurt]

Ik wil je aanbevelen om te reageren op de reacties met de "Reageer"-knop, ipv ze in je hoofdpost toe te voegen. Het is nu nogal raar dat je in je post reageert op dingen die wij pas later te lezen krijgen.

[Reactie gewijzigd door RVervuurt op 28 juli 2024 02:43]

[wifikabelhuren]

En door dit soort berichtgeving maak je het alleen maar erger voor de mensen die gelekt zijn. Nu gaat men op zoek naar wat er gelekt is en wordt het publiekelijk gebracht. Onnodig! Die 3 klanten hadden liever gehad dat het stil bleef, dat het gemeld had moeten worden uiteraard..

[volkoren]

"Omapost zegt dat het melding van een datalek heeft gedaan bij de Autoriteit Persoonsgegevens."

Nog vaak worden datalekken aan de AP gemeld zonder dat dit vereist is. Het publiek maken van 3 namen van klanten aan duizenden mensen... waar zit het risico (voor de rechten en vrijheden) voor die klanten?

[FilipSP]

Nou....in eerste instantie is het niet te hopen dat iedereen een kaartje terug stuurt

[volkoren]

[DaBomb2]

Handige sluikreclame van Omapost, guerillamarketing.

[Threbez]

Misschien hebben ze een briljante imago-manager die mij volledig beet heeft.... maar volgens mij is Omapost gewoon iemand die kaartjes naar z'n oma wilde sturen en dacht 'dit is ook leuk voor andere oma's, ik bouw een app'. De kneuterigheid zelve. Ik moet dan ook wel een beetje lachen om de discussie hierboven over welk testprotocol en hoe daar geanonimiseerde data voor gegenereerd kan worden. Het zal vast beter georganiseerd zijn dan helemaal houtje-toutje, maar ik kan me niet voorstellen dat hier meerdere hoogopgeleide app-ontwikkelaars achter zitten die Agile werkend van Scrums naar Scrum stressen om releases uit te brengen.

[FreshMaker]

Handige sluikreclame van Omapost, guerillamarketing.

Inderdaad, dit is iets waar ik wel gebruik van wil maken, maar nog niet van had gehoord.

Ze zijn wel 'traag'
Greetz is de volgende dag bezorgd ( mits voor 20:00 besteld )
Oma doet er 2 dagen over .... maar is wel goedkoper

edit :
En ze zijn sociaal meer begaan .... heb ze toch bij de bookmarks gezet, just in case

[Reactie gewijzigd door FreshMaker op 28 juli 2024 02:43]

[Bear312]

Testen doe je over het algemeen niet met echte gegevens lijkt mij? Of mis ik wat? Zou niet bepaald moeilijk moeten zijn om als bedrijf een paar test accounts te hebben voor je eigen product waarmee je iets nieuws test...