Brits ministerie haalt data van 76.000 immigranten door elkaar door databasefout

Het Home Office, het Britse ministerie van Binnenlandse Zaken, is onzorgvuldig omgegaan met de gegevens van meer dan 76.000 immigranten. Deze zijn onder meer geregistreerd onder de verkeerde namen en er zijn foto’s van immigranten door elkaar gehaald.

Door de fout van het Home Office kunnen de getroffenen niet solliciteren en komen ze niet in aanmerking voor een woning of voor behandeling bij de National Health Service, schrijft The Guardian donderdag op basis van uitgelekte documenten. Dat komt doordat er in het systeem van het Home Office identiteiten zijn samengevoegd. Dat houdt in dat de biografische en biometrische gegevens van twee of meer personen aan elkaar zijn gekoppeld.

Het ging vaak om gegevens van immigranten die volgens The Guardian ‘totaal niets met elkaar te maken hadden’. De krant heeft gesproken met een aantal getroffenen. Een man uit Nicaragua zou meer dan honderd keer naar het Home Office hebben gebeld om aan zijn werkgevers te kunnen bewijzen dat hij een werkvergunning had. Een andere vluchteling zag herhaaldelijk het identiteitsbewijs met de foto van een vreemde toen ze inlogde op haar account.

Hoewel het ministerie in het verleden de ‘IT-problemen’ heeft erkend, heeft het weinig gedeeld over de schaal van de problemen. In februari zei de minister van Binnenlandse Zaken, Tom Pursglove, tegen het parlement dat er ‘geen systemische problemen’ waren vastgesteld bij Atlas, de tool die immigratieambtenaren gebruiken en die opereert op basis van de gebrekkige database. In de uitgelekte documenten wordt echter beschreven hoeveel mensen zijn getroffen door de fout en de pogingen die het Home Office heeft ondernomen om de ‘lang bestaande problemen’ op te lossen.

Uit interne documenten blijkt dat het ministerie een tool heeft ontwikkeld om potentiële samengevoegde identiteiten te signaleren. Tot nu toe zijn daarmee ruim 38.000 problemen gesignaleerd, die elk ten minste twee mensen hebben getroffen. Een woordvoerder van het Home Office zegt dat de problemen naar schatting 0,02 procent van de personen in de database hebben getroffen.

Door Loïs Franx

Redacteur

15-03-2024 • 13:52

44

Reacties (44)

Sorteer op:

Weergave:

En daarom gebruik je in een gedistribueerde database GUID's als key, en geen oplopende nummering. Ook niet als je denkt dat je die oplopende nummering goed geïmplementeerd hebt, want dit riekt naar race condities. Dood eenvoudig te voorkomen, en zeer slordig dat dit überhaupt in zo'n systeem ergens is gebruikt.
Identifiers zijn het probleem niet.

Als je in een systeem gegevens over individuele personen wil opslaan, heb je doorgaans te maken met ontdubbelingsproblematiek en dat is verdomd lastig bij een internationale populatie. Herkomstlanden hebben misschien een slechte of afwezige bevolkingsadministratie, geboortedata zijn niet altijd bekend, namen kunnen anders gespeld worden, niet iedereen kan schrijven of beheerst ons alfabet, mensen kunnen geen/meerdere/nieuwe paspoorten hebben, enzovoorts. Dat krijg je nooit 100% correct, zelfs als je er vanuit gaat dat alle aanvragers hun gegevens eerlijk invullen.

Als je dan op basis van wat voor ontdubbelingsmethodiek gegevens gaat samenvoegen loop je de kans op onherstelbare schade. Op mijn werk, waar dit probleem ook speelt, voegen we dan ook geen gegevens samen, maar leggen een 'lijkt op' koppeling aan die zonder schade te verwijderen is.
In de bron worden medewerkers aangehaald die volstrekt andere id's zoals paspoorten en visums krijgen te zien als ze gegevens opvragen. Als het aan het ontdubbelen ligt, dan wordt dat wel bar slecht gedaan in ieder geval.
Uit het artikel blijkt inderdaad dat het te maken heeft met ontdubbeling.

Zij quoten trouwens het woord "merged identities" en noemen ook linked identities, waardoor het er op lijkt dat het om een merged view gaat en geen daadwerkelijke samengevoegde rows. Dus zou je kunnen aannemen dat zij dat risico ook zien en soortgelijke techniek gebruiken als die @TheekAzzaBreek ook al noemde.
The problem, which involves “merged identities”, where two or more people have biographical and biometric details linked incorrectly, is leaving people unable to prove their rights to work, rent housing or access free NHS treatment.
Bron: The Guardian

Edit: fix typo

[Reactie gewijzigd door Webber op 22 juli 2024 13:57]

Janoz Moderator PRG/SEA @barbarbar15 maart 2024 14:59
Dit lijkt me eerder een functionele fout ipv een technische fout. Unieke ID's genereren kunnen we al sinds de 2e helft van de vorige eeuw. Dit lijkt me eerder een overactieve ontdubbeling.
Maar dan nog zou je verwachten dat ze een backup hebben of tenminste transaction logs; het gaat tenslotte over persoonsgegevens.

Met een backup kan je tenminste de bulk terug rechtzetten; het enige wat je dan mist zijn de mutaties sinds de fout. Beter (ik zeg maar wat) 80% correcte gegevens dan 100% foute gegevens...
Je hebt gelijk, maar misschien loopt het probleem al zo lang dat 80% correcte gegevens bij lange na niet eens haalbaar is. Dat is het probleem als het eerst ontkend wordt.
Vaak zijn dat soort voor de hand liggende oorzaken niet de werkelijke oorzaak. In de praktijk is de oorzaak van problemen vrijwel altijd een samenloop van omstandigheden die nooit voorzien waren tijdens het ontwerp van de techniek en werkprocessen.
En vaak ook wel. Soms is een bug gewoon een bug. Een race conditie is per definitie een samenloop van omstandigheden. Dus ben het helemaal met je eens.
De Conservatieven in de regering in het VK doen al 15 jaar aan afbraakpolitiek daar.
En helemaal waar het om immigratie en het om dit ministerie gaat.
Toen Theresa May daar minister was, voordat ze Prime Minister werd, heeft ze het "hostile envirnoment" ingevoerd, met als doel om het immigranten bewust zo moeilijk mogelijk te maken.
Ik kan me zo voorstellen dat dit soort problemen een indirect gevolg zijn van de politieke leiding daar de afgelopen 15 jaar.
En dan heb je nog altijd te maken met de grootste bug in het systeem: de gebruiker
few thousand people in the database who (typically due to human error) had other people’s passport details recorded on their records
Als dit handwerk is geweest en ze hebben duizenden en duizenden moeten invoeren, foutje is te simpel gemaakt.
Een id is niet meer dan een id, of je daar nou een nummertje hebt staan of een GUID, doet niet ter zake.

Dit werkt al sinds begin jaren '70 uitstekend in elke relationele database en dan zou een fuck-up van een paar linksrijdende Engelsen hét bewijs zijn dat id's niet werken?

Homework
Every non-key attribute must provide a fact about the key, the whole key, and nothing but the key. So help me Codd".
Uitstekend is onzin. Het heeft een reden dat alle gedistribueerde systemen guids gebruiken.

Alles om numerieke id's werkend te maken op gedistribueerde systemen zijn lapmiddelen waar fouten insluipen.
En waarom zou je voor een dataset van slechts aan paar honderd miljoen records een gedistribueerd systeem gebruiken??? Mijn telefoon heeft voldoende opslag én rekenkracht om die data real time te presenteren.

Alsof je met een truck met oplegger door de supermarkt heen gaat om boodschappen te doen omdat een winkelwagentje niet groot genoeg is.
GUIDs zijn natuurlijk universeel nuttig, of je nou gedistribueerde systemen gebruikt of niet. Het lijkt dat je barbarbar's argument belachelijk maakt op basis van je eigen voorkeur van software architectuur voor dit bedrijf, maar je weet waarschijnlijk niet wat voor architectuur zij in de praktijk draaien.

Het lijkt me überhaupt een grote stap om aan te nemen dat 't aan identifiers zou liggen. Uit het artikel blijkt dat het geen per ongeluk foute query was, maar doelgericht samenvoegen van documenten, met ingecalculeerd risico en blijkbaar onderschatte impact.
A document seen by the Guardian highlights a “small but important downside […] a few thousand people in the database who (typically due to human error) had other people’s passport details recorded on their records. The trade-off here was deemed by the business [the Home Office] to be worth it, hence the approval to proceed.”
Bron: The Guardian

Hierbij denk ik aan het samenvoegen van documenten op basis van niet-identifier gegevens, zoals bijvoorbeeld op basis van een combinatie van voorletter, achternaam en verblijfplaats. Zulk soort handelingen zijn foutgevoelig en vragen in de praktijk vaak om een soort afweging te maken.
Bel ze ff dat je de oplossing hebt
Ze zeiden dat ze er al een hoog opgeleide migrant opgezet hadden, maar ze wisten niet exact meer wie. Toen ze in hun systeem keken zagen ze ene B. Johnson met een foto van een theepot. Ze vermoeden daarom dat de migrant nog bezig is met de oplossing.
De oplossing hebben de Britten zelf inmiddels ook al, maar de reeds gemaakte fout is moeilijk te corrigeren omdat het veel werk is.
"Race" conditions. Erg toepasbaar dit.
GUID's zijn ook niet per se uniek, en zeker niet als ze door verschillende systemen worden gegenereerd.

edit:

okee, okee, de kans is heel klein dat ze niet uniek zijn ;)

[Reactie gewijzigd door derkesthai op 22 juli 2024 13:57]

Zuig je dit nu gewoon spontaan uit je duim?

We weten helemaal niet wat de oorzaak is, hoe de database werkt, of het überhaupt een technische of menselijke fout was, maar jij beweert alles al begrepen te hebben, je weet precies wat er fout is gegaan, en als jij het had gemaakt was er nooit iets misgegaan.

Graag 1 bewijs van je beweringen...
Je maakt natuurlijk wel een aantal aannames hier. Overheden zijn natuurlijk supercomplex met gigantisch veel databronnen. Al die data moet, waar nodig gecorreleerd worden. Er zijn een ‘oneindig’ veel plaatsen waar dit mis gegaan kon zijn.
Geloof maar dat de databron voor een werkvergunning een andere databron is dan waar de verblijfsvergunningen staan. Om nog maar te zwijgen over de geregistreerde woonplaats, voertuigeigendom, registratie van verplichte verzekeringen, huishouden, familie, geregistreerd inkomen, enz, enz, enz.

Al die data wordt ergens gecorreleerd. Bij iedere correlatie kunnen fouten worden gemaakt. Het is natuurlijk goed mogelijk dat je gelijk hebt hoor, maar je kunt er niks over zeggen zonder kennis van zaken over hun datamodellen en meer details dan “door een fuck-up is er data van meerdere natuurlijke personen door elkaar geraakt op ogenschijnlijk willekeurige manieren.”
Het is natuurlijk goed mogelijk dat je gelijk hebt hoor, maar je kunt er niks over zeggen zonder kennis van zaken over hun datamodellen
In dit geval is wel te stellen dat de persoon waar je op reageert sowieso geen gelijk heeft. Ik heb een paar pogingen gedaan hieraan toe te voegen op welke manier de logica niet opgaat, maar geen van de voorbeelden die ik me kon bedenken vond ik breed illustrerend en in alle gevallen kun je met numerieke identifiers net zo goed werken als met tekenreeksen.
0,02% van de mensen die in de database staan, zijn getroffen en dat betreft inmiddels 76.000 mensen. Dan moeten er 380 miljoen mensen in die database staan. Bijzonder voor een land met een 67 miljoen inwoners
1 enkele persoon kan verbonden zijn aan meerdere problemen. Daarnaast bevat deze database vermoedelijk info over iedereen die ooit het land is in geweest of daar een aanvraag voor heeft ingediend waardoor er effectief veel meer mensen dan inwoners in kunnen staan.
In de bron staat gewoon letterlijk het aantal mensen in de database, namelijk 177 miljoen. Er staat ook letterlijk dat ze dachten dat het om een paar duizend gevallen ging. Aannames doen is dus helemaal niet nodig, het staat er letterlijk.
It stores the records of 177 million people
a few thousand people in the database who (typically due to human error)
Vermoed dat de woordvoerder reageert op hun officiële standpunt dat het gaat om enkele duizenden handmatige verkeerde invoer. In de bron staat niet duidelijk waar de woordvoerder exact op reageert.
We weten niks van de database en de inhoud.
Allicht staat er ook historische data in. Dus van iedereen die in de afgelopen 10 jaar in het VK heeft verblijft?
Misschien tellen ze al hun vroegere kolonies erbij op. Ze denken toch ook nog dat Brittania rules the Waves.
Ze hebben een tool ontwikkeld om identiteiten te signaleren. Betekent dit dat de originele data niet meer beschikbaar is?

Ik zie enorm veel IT-projecten in mijn werk als security consultant. In IT-projecten wordt voornamelijk de focus gelegd op de beschikbaarheid van data en servers. Integriteit, zoals in dit project gigantisch gefaald is, is iets waar minder aandacht voor is. En als ze dan aanvullende tools moeten ontwikkelen om de data weer te herstellen, wens ik ze veel sterkte.
Ik heb wel eens mee gemaakt dat bijneem test men er achter kwam dat de software in de backend geen unieke code maakt bij het invoeren van een nieuw persoon. Dan werden er willekeurig namen, adressen e, foto’s en vingerafdrukken onder een record gehangen. Gelukkig ging het om een schaduw test, en kond de maker dit eerst herstellen.
Dit lijkt me een vergelijkbaar geval. Maar blijkbaar niet goed getest
Waarom noemt de titel dit een 'databasefout'? Denk niet dat de database iets fout doet. Eerder een bug waardoor data foutief wordt opgeslagen.

[Reactie gewijzigd door YGDRASSIL op 22 juli 2024 13:57]

Dit is een vrij bekend patroon, de database de schuld geven zodat de schuld niet bij jou ligt.
Dit gebeurt op allerlei lagen van een organisatie:
- manager die rapporteert naar c-level, en het zover vereenvoudigd dat elke nunce verdwijnt
- developer die niet doorheeft waarom zijn queries zo traag zijn en ziet dat de database 100% CPU gebruikt en dus concludeert dat de database niet genoeg resources heeft.

En dus kennelijk ook records in je database mergen...
Het kan ook daadwerkelijk aan de database liggen. ;)

Een keer meegemaakt dat subrecords niet allemaal onder dezelfde parent record werden ge-insert. In de code was dat echter niet mogelijk, op de acceptatieomgeving ging het prima en het had al jaren goed gewerkt. Uiteindelijk is er onderhoud aan de database gepleegd (adhv acceptatie de db weer opbouwen) en het werkte weer als normaal.
Ook bij reacties hier hoor.
Als je nuance vereenvoudigt naar nunce blijft er ook niets over.
Een databasefout zie ik als een fout in de database, exact wat er mis is.
Waar die door veroorzaakt is, is een tweede.
De titel zegt dat het komt 'door een databasefout'. Dus als een applicatie groen opslaat als geel in je database dan komt het feit dat de kleur verkeerd is door een 'databasefout' zeg je. In mijn ogen door een applicatiefout of een bug . De database doet niets fout.
Ja, dat was ook mijn punt.
Als data niet correct is vind ik dat eerlijk gezegd gewoon een databasefout. Daarnaast heb je natuurlijk ook technische fouten (bugs, ontwerpfouten).

Het is maar net met welke blik je er naar kijkt. Een developer kijkt naar de functionaliteit, een sysadmin naar bugs en een gebruiker naar de data.
Een database hoeft natuurlijk helemaal niet verkeerd te zijn , wanneer je de invoer van gegevens niet in het juiste vakje plaatst. Het kan zelf wel goed in de database staan , maar mis gaan bij het opvragen.
Dus als ik mijn leeftijd fout intik ergens in een applicatie en dat is later een probleem dan komt dat probleem 'door een databasefout'. Dat is niet hoe ik het zou omschrijven.
Tja, is het inderdaad een fout, of een poging tot Windrush II ... ?
Hoe is dit een database fout? Het is toch gewoon de medewerker/ team/ontwikkelaar/consultancy bedrijf dat een fout maakt?

Als je iemand aanrijdt is het toch ook geen autofout?

De berichtgeving van alles wat ook maar met tech te maken heeft is bar slecht, en op tweakers blijkbaar niet beter.

Op dit item kan niet meer gereageerd worden.