Autoriteit Persoonsgegevens: Booking.com meldt datalekken nu wel op tijd

Booking.com meldt datalekken inmiddels op tijd, zegt de Autoriteit Persoonsgegevens na een jaar intensief toezicht. In 2021 kreeg het platform nog een boete van 475.000 euro omdat een datalek te laat werd gemeld. Nu houdt het bedrijf zich wel aan de regels, stelt de AP.

Bedrijven zijn volgens de AVG verplicht om binnen 72 uur datalekken te melden bij Europese toezichthouders, maar Booking.com deed dit in 2019 pas na drie weken. Hiervoor kreeg het bedrijf in 2021 een boete. Vanwege die boete 'en omdat het bedrijf daarna mogelijk enkele datelekken niet op tijd meldde', stelde de Autoriteit Persoonsgegevens in 2023 intensief toezicht in.

Als onderdeel van dat intensieve toezicht moest Booking.com gedurende het jaar rapporteren over maatregelen die het platform had genomen om datalekken op tijd te melden. Daarnaast moest het bedrijf rapporteren over maatregelen om incidenten te voorkomen en controleerde de Autoriteit of Booking.com 'bepaalde incidenten' onterecht niet meldde. "In de periode van geïntensiveerd toezicht bleek het bedrijf alle incidenten die het moest melden, ook daadwerkelijk te melden", schrijft de Autoriteit Persoonsgegevens.

In 2023 meldde Booking.com 'diverse fraudezaken'. Bij een groot deel hiervan konden criminelen accounts van accommodaties overnemen. Hiermee werden Booking.com-gebruikers weer opgelicht. Ze vroegen gebruikers bijvoorbeeld via Booking.coms berichtensysteem om betalingen, die niet naar de accommodatie gingen maar naar de crimineel. "Vanwege dit soort incidenten blijft de AP Booking.com goed in de gaten houden." De AP zegt dat tijdige meldingen belangrijk zijn, 'zodat de AP kan adviseren waar nodig'.

Reacties (51)

[JoHnnY-Btm]

datalek(ken) als in multiple??!!!!

zo goed is booking.com dus niet met hun security niveau. schandalig, nooit wat geboekt trouwens bij deze organisatie.. gaat dus ook niet gebeuren

[Keypunchie]

Er is natuurlijk ook veel communicatie tussen Booking.com en hotels, als daar iets mis gaat (mailtje naar verkeerde, of iemand heeft de inlog van een hotel gekraakt), dan is er al een datalek.

Dat laatste schrijft de AP ook expliciet

Gedurende het intensievere toezicht heeft Booking.com diverse fraudezaken gemeld. Bij een groot deel van deze zaken slaagden criminelen erin het account van accommodaties op Booking.com over te nemen. Vanuit het overgenomen account werden gasten vervolgens opgelicht. De oplichters vroegen klanten de hotelkamer te betalen, bijvoorbeeld omdat er iets mis zou zijn gegaan met een eerdere betaling. Omdat de berichten via het berichtensysteem van Booking.com kwamen, leken deze voor klanten authentiek te zijn.

Dit was trouwens ook het oorspronkelijke lek van de boete van 475k:

Criminelen ontfutselden per telefoon bij medewerkers van 40 hotels in de Verenigde Arabische Emiraten inloggegevens tot hun accounts in een systeem van Booking.com.

[Reactie gewijzigd door Keypunchie op 22 juli 2024 18:28]

[StarZ]

Een keer een mail sturen aan een verkeerd persoon kan al als datalek gezien worden. Het is niet zo gek dat het vaker gebeurd. Niet elk datalek is een database dump van alle klanten.

[Jorah_Newstone]

Of een groep klanten in de cc inplaats van bcc gooien bijvoorbeeld. Heeft bij mij op werk echt wel even tijd nodig gehad om gebruikers hierin op te voeden en het gebeurd nog steeds soms.. gebruikers blijven de zwakste schakel.

Kan je wel van alles dicht gaan lopen timmeren, maar dan maken ze wel een foto met een telefoon van dat ene gevoellige bestand.

[JoHnnY-Btm]

goed valide punt

ik had laatst namate van een ander berichtgeving op de website va nde politie gekeken of één van mijn e-mail adressen gehacked of via een hack gekaapt zouden zijn.

bleek dat 1 van de 4 e-mail adressen door een hack waren buit gemaakt.

het nog meest vreemde is dat het een e-mail adres is die ik voor zakelijke doeleinden gebruik en geen social media.

enige waar ik met dat e-mail adres bij bekend sta is: linkedin, en overheids instanties...

[jvdmeer]

offtopic:
Hou het er maar op dat het linkedin betreft.
https://duckduckgo.com/?q=linkedin+data+breach

De cijfers zijn niet heel erg consistent, maar ze verschillen van 200 tot 700 miljoen accounts.

[JoHnnY-Btm]

duidelijk..tijd om Linkedin er dus uit te gaan gooien

[Aldy]

Toen ik het artikel las moest ik onwillekeurig aan een vergiet denken, later kwam daar ook nog zo lek als een mandje bij. Ik vraag mij af of dit alleen Nederland betreft of dat AP dit voor heel EU doet?

[JoHnnY-Btm]

goede vraag, ik denk van niet maar dat ze mogelijk wel een samenwerkingsverband hebben met buitenlandse organisaties

[morphje]

Aangezien Booking.com het hoofdkantoor heeft in Amsterdam vallen ze daarmee onder de verantwoordelijkheid van het AP voor de gehele unie. Ook in in de aankomende NIS2 wetgeving valt de verantwoording van een belangrijke entiteit bij het lidstaat waarin het hoofdkantoor gezeteld is.

Een (zeer interessante) toevoeging voor niet-EU bedrijven is de eis om een europese vertegenwoordiger binnen de EU te hebben (mits ze onder NIS2 vallen uiteraard). Voor de meeste grootste bedrijven is dat nu al het geval, maar er komt ook meer verantwoordelijkheden bij kijken. Het mag geen brievenbuskantoor zijn.

[Aldy]

Een datalek blijft natuurlijk ongewenst, maar als Booking.com in elk EU-land één keer een datalek heeft, dan zijn dat al 27 stuks. En waarschijnlijk halen ze dat aantal niet eens, maar het zorgt er wel voor dat je het (niet in het artikel genoemde) aantal in een ander licht gaat zien.

[Zackito]

Zoeken naar hotels vindt ik anders altijd wel makkelijk via booking.com, vaak via het hotel zelf kan je hetzelfde hotel boeken alleen voor minder geld.

[Flappiewappie]

https://www.techradar.com...jor-new-phishing-campaign

Deze is al jaartje gaande. Zowel mijn vriendin als ik zijn de dupe geweest.

[Floort]

De AP moet leren dat meer dan een jaar een verzwaard toezichtstraject voor het te laat melden (niet onterecht niet melden) voor een enkele verwerkingsverantwoordelijke misschien niet de meest schaalbare vorm van toezicht is. Ik twijfel er ook aan of het uberhaubt verstandig is om zoveel toezichtsdruk te leggen op verwerkingsverantwoordelijken die te laat melden zonder dat er vergelijkbare of meer druk ligt op degenen die niet melden. Dat werkt volgens mij averechts. Misschien dat anderen zich de volgende keer bedenken als ze al te laat zijn met melden: niet melden lijkt dan veiliger.

[lenwar]

De meeste bedrijven willen zich gewoon aan de wet houden. Het gaat er om dat je het meldt. Dat je op het moment van melden nog niet alle details boven water hebt, hoeft geen probleem te zijn.
De AP weet ook wel dat het soms heel ingewikkeld kan zijn om de precieze impact te kunnen detecteren. Hier is niets algemeens over te zeggen. De factor transparantie is hier dus essentieel.

[Floort]

Dat klopt. In de praktijk kan je een vrij generieke eerste melding doen en die later aanvullen, corrigeren of zelfs intrekken. En het op tijd melden gaat bijna volledig over de tijd tussen het ontdekken en de initiele melding.

De aanname dat de meeste bedrijven zich gewoon aan de wet willen houden wil niet zeggen dat ze niet van die gedachte af te krijgen zijn als ze in de praktijk harder gestraft worden voor het net net voldoen (te laat melden) dan het helemaal niet voldoen (niet melden). De AP straft vaker en harder na aanleiding van te late meldingen dan na aanleiding van niet melden voor zover dat zichtbaar is in gepubliceerde besluiten. Wat de intrinsieke motivatie van bedrijven ook is, dat motiveert niet om de AVG na te leven.

Edit: ik had hier wat statistieken uitgewerkt over 2022.

[Reactie gewijzigd door Floort op 22 juli 2024 18:28]

[morphje]

En zie hier de effecten van een sterke lobby campagne tegen de GDPR. De AP (en EU equivalenten) zijn effectief tandeloos gemaakt omdat ze alleen maar reactief kunnen handelen. Daarom was ik ook aangenaam verrast door frankrijk die proactief boetes ging uitkeren voor TLS1.0 websites.

Maar ook na een feitpleging heeft het AP geen extra instrumenten binnen de GDPR. Boete betalen en doorgaan. De boete gaat ook nog eens naar de schatkist, dus kan niet worden gebruikt om het AP te versterken, dat moet uiteraard weer via de tweede kamer budgetcommisie.

Enige hoop is de NIS2 die zich proactief opstelt en bedrijven verplicht (en mag controleren) om maatregelen te nemen. Maar we zullen zien hoe dit zich in de toekomst ontwikkelt.

[kodak]

We kunnen net zo goed redeneren dat bedrijven die te laat melden duidelijk te weinig waarde aan de lekken en wet hechten. Dat ze te laat melden heeft dus niet zomaar de betekenis dat ze meer te vertrouwen zijn dan wie geen melding doet. Eerder juist net zo min, want de kans is aanzienlijk dat als de toezichthouder er niet strenger op zou zijn men er mee probeert weg te komen. En daarnaast te ver gaat door niet alles te melden. Terwijl dit kennelijk geen klein bedrijf is waarbij maar sporadisch lekken zijn.

Het streng aanpakken toont aan dat zowel niet melden als te laat melden zwaar meetellen. Het is dus ook een signaal naar overtreders die het melden niet waardevol vinden: men moet hoe dan ook moeite doen.

Dat de overtreders die niets melden aangepakt moeten is duidelijk. Maar het verzwaarde toezicht gaat niet duidelijk ten koste van het doel. We kunnen dan twijfelen aan evenwicht, maar ik lees niet dat het meer tijd besteden aan de vele niet-melders duidelijker zou zorgen dat overtreders die niet melden hoe dan ook maar meer moeite gaan doen.

Het zal me niets verbazen als de overtreders die niets melden en zich niets aantrekken van handhaving op te laat melden pas gevoelig worden als ze zelf aangepakt worden. Wat niet zomaar het geval is door minder streng handhaven op te laat melden.

[Reactie gewijzigd door kodak op 22 juli 2024 18:28]

[Floort]

Te laat melden heeft in mijn ervaring vaak te maken met interne awareness of communicatie. Denk bijvoorbeeld aan een medewerker die donderdag middag een inbreuk ontdekt maar op het punt staat om naar huis te gaan. Het lijkt niet ernstig dus dat kan de volgende ochtend ook wel doorgezet worden aan de collega die erover gaat. Die blijkt toevallig een dagje ziek te zijn dus het wordt over het weekend heen getild en maandag netjes opgepakt en gemeld. Dan zit je al *ruim* over de 72 uur heen. Te laat dus.

Elke situatie is natuurlijk anders en een paar dagen later melden is wat anders dan maanden of jaren later melden. Maar te laat melden vaker én harder te bestraffen dan niet melden is echt de omgekeerde wereld. Je gaat me niet overtuigen dat te laat melden erger is dan niet melden, ook als je beiden niet ok vind gaat dat wel erg ver.

[kodak]

Wat ik noem is niet bedoeld om je te overtuigen. Het is om te tonen dat je eigen stellingen en argumenten waarschijnlijk niet makkelijk overtuigend voor anderen zijn. Er zijn nu eenmaal meer mogelijkheden dan gelijk gestemde meningen wat het beste is.

Ik vraag me af of de wetgever hier duidelijk genoeg in is. Want dat lijkt me vooral de mogelijkheden te geven. En zowel voor de huidige aanpak als jou stelling gaat op dat het zich moet bewijzen bij de wet. Ik lees niet hoe de huidige aanpak zich bewijst om zowel laat melden als niet melden zo evenwicht mogelijk aan te pakken. Daar mag waarschijnlijk inhoudelijke verantwoording bij verwacht worden over de keuzes en het in stand houden. Is er bijvoorbeeld wetenschappelijk onderzoek? Zijn er wettelijke uitspraken? Enz.

[Floort]

Het is zeker terecht om te stellen dat er veel te weinig onderzoek is naar de effectiviteit en impact van verschillende toezichtsbenaderingen die de AP zou kunnen hanteren. Ik heb ervaringen omdat ik ongeveer 12 jaar in dit veld werkzaam ben. Ik probeer her en der data vandaan te halen om mijn standpunt te onderbouwen. Maar veel meer dan dat kan ik niet doen.

[Met]

Ieder bedrijf heeft last van datalekken. En heeft dan ook te maken met security-incidenten. De mens is en blijft de zwakste schakel. En dat is gewoon een feit. Het is goed dat de AP er toe ziet. Dat is hun taak.

[phoenix2149]

Hoezo "Nu wel"

Waarom hebben ze hun security nog steeds niet op orde?

[Blokker_1999]

Als je denkt dat datalekken alleen maar ontstaan omdat er fouten in de beveiliging zitten, dan heb je het mis. De meeste lekken ontstaan net door menselijke fouten. Iets vergeten te anonimiseren, een verkeerde lijst gebruiken voor een mailing, een foutje in de configuratie ergens.

[Frame164]

En er worden iedere keer nieuwe vulnerabilities in software ontdekt.

[lenwar]

Zoals @Blokker_1999 al terrecht aangeeft zijn lang niet alle datalekken het gevolg van 'slechte beveiliging' of 'niet patchen'.


Simpel voorbeeld:

Ik ben zelf vrijwilliger bij de lokale afvalverwerker (ik heb een sleutel van de ondergrondse container en heb een stuk gereedschap gekregen, waarmee ik een eventuele klemmende zak of zo naar beneden kan forceren). Eens in de zoveel tijd sturen ze een mailing rond. Ze hadden op een gegeven moment per ongeluk alle vrijwilligers (een paarhonderd) via het 'aan-veld' een mail gestuurd.

Dit is gewoon een datalek door een dom ongelukje van een een of andere communicatiemedewerker. Ze hebben dit netjes gemeld bij de AP en een excuusberichtje gestuurd naar alle vrijwilligers (dit keer niet met het 'Aan-veld'). Of ze daadwerkeiljk een boete hebben gekregen weet ik niet.

[CAPSLOCK2000]

Ze hadden op een gegeven moment per ongeluk alle vrijwilligers (een paarhonderd) via het 'aan-veld' een mail gestuurd.
Dit is gewoon een datalek door een dom ongelukje van een een of andere communicatiemedewerker.

Nee, het is vooral een software fout*.

Het zou nooit nodig moeten zijn om meer dan een stuk of 10 adressen in de To: te zetten. Als een mens toch 100 adressen in de To: zet had de software moeten ingrijpen. Technisch gezien is dat niet moeilijk, ik configureer mijn mailservers al 20 jaar met een limiet op het aantal adressen in To: en CC:.

Sofware is er om ons te dienen en moet rekening houden met menselijke beperkingen en fouten, niet andersom.

Ze hebben dit netjes gemeld bij de AP en een excuusberichtje gestuurd naar alle vrijwilligers (dit keer niet met het 'Aan-veld'). Of ze daadwerkeiljk een boete hebben gekregen weet ik niet.

Als je het meld krijg je geen boete, er is namelijk geen straf voor datalekken. Het melden is verplicht en zo'n boete krijg je dus voor het niet melden van een lek. Als je het wel netjes meldt zul je er geen boete voor krijgen.


* software wordt door mensen geschreven, eigenlijk zijn softwarefouten ook menselijke fouten, maar dat kun je over alle fouten zeggen. Natuurkunde maakt geen fouten, alleen levende wezens.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 18:28]

[lenwar]

Het zou nooit nodig moeten zijn om meer dan een stuk of 10 adressen in de To: te zetten

Dat vind ik wel een heel erg algemeen statement. Er zullen zat mensen zijn die zo voorbeelden kunnen oplepelen wanneer dit wel 'nodig' is (meer dan 10).
Het ligt er net aan hoe een organisatie werkt. Of het een slimme manier is om zo te werken is weer een andere discussie, maar zoals je zelf aangeeft. De software is om ons werk te faciliteren, niet andersom .

[CAPSLOCK2000]

Dat vind ik wel een heel erg algemeen statement. Er zullen zat mensen zijn die zo voorbeelden kunnen oplepelen wanneer dit wel 'nodig' is (meer dan 10).

Dit is dan wel weer een erg makkelijk statement. Er zullen zat mensen zijn die tegenargumenten kunnen oplepelen waarom het niet 'nodig' is.

Kom maar op met die voorbeelden waarin het nodig is om meerdere adressen in de To:/CC: te hebben.

[lenwar]

Grotere projecten die over meerdere afdelingen gaan.
Iemand die een familiefeestje organiseert.
Enz.

Als het gebruikelijk is binnen een bedrijf om het zo te doen, dan is dat zo.
Dat familiefeestje kan ook met bcc, maar zo is het beter zichtbaar wie er betrokken/uitgenodigd zijn

Enzovoorts
Uiteraard zijn daar alternatieven voor, maar dit zijn wat mij betreft prima voorbeelden voor meer dan 10 adressen.

[Emunator]

Het zou nooit nodig moeten zijn om meer dan een stuk of 10 adressen in de To: te zetten. Als een mens toch 100 adressen in de To: zet had de software moeten ingrijpen. Technisch gezien is dat niet moeilijk, ik configureer mijn mailservers al 20 jaar met een limiet op het aantal adressen in To: en CC:.

Dus bij minder dan honderd zou jij het niet als datalek bestempelen?

[CAPSLOCK2000]

Goed punt, het blijft natuurlijk een datalek, maar wel een veel kleiner lek. Schade beperken is ook een mooi doel.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 18:28]

[Aldy]

Een goed voorbeeld. Ik vraag mij af hoe AP hiermee om is gegaan. Want niet elke datalek is een boete waardig.

[JoHnnY-Btm]

de grootste "vulnerabilities" is de gebruiker niet gelijk zozeer de software

[CAPSLOCK2000]

Als je denkt dat datalekken alleen maar ontstaan omdat er fouten in de beveiliging zitten, dan heb je het mis. De meeste lekken ontstaan net door menselijke fouten. Iets vergeten te anonimiseren, een verkeerde lijst gebruiken voor een mailing, een foutje in de configuratie ergens.

Ik vind het een beetje lastig stelling. Technisch zien heb je gelijk, al is het maar omdat bugs ook menselijk fouten zijn, maar het moet geen excuus zijn. Mensen zijn deel van het systeem en beveiligingsmaatregelen moeten rekening houden met menselijke fouten en zwaktes.
Goede software maakt het makkelijk om je het juiste te doen en moeilijk om het verkeerd te doen. Je systeem moet niet afhankelijk zijn van dat mensen ergens aan denken. Als het systeem faalt moet het veilig falen.

Laat ik versleutelde e-mail als voorbeeld nemen. Als je aan je mailer een knop toevoegt met "versleutel deze mail" dan moet de gebruiker bij iedere mail nadenken of de mail versleuteld moet worden of niet voor de mail verstuurd wordt. Vroeg of laat vergeet de gebruiker dat en gaat er een onversleutelde mail de deur uit.

Dat zou je kunnen oplossen door het expliciet aan de gebruiker te vragen voor de mail vestuur wordt ("Deze mail is niet versleuteld. Doorgaan j/n ?") maar binnen de kortste keren is de gebruiker er aan gewend om altijd op "ja" te klikken en gaat het alsnog fout.

De betere oplossing is dus om het zou te bouwen dat encryptie by default aan staat. Als de gebruiker een fout en vergeet encryptie uit te zetten dan is het worst-case scenario dat iemand een onleesbare e-mail krijgt.

We kunnen niet alle fouten tegenhouden (en doelbewust misbruik al helemaal niet) maar we zouden meer werk moeten maken van fail-safe design.

We zouden heel veel kunnen bereiken door onze data standaard te versleutelen. Nu is het meetal zo dat data onversleuteld in een database staat en alleen versleuteld wordt als er data wordt geexporteerd, typisch handmatig door de gebruiker die de data wil delen. Als de gebruiker dat vergeet of de databaseserver gekraakt wordt dan is alle data direct leesbaar.

Het zou mooier zijn als we onze databases zo inrichten dat alle data altijd versleuteld is met een sleutel die niet op de databaseserver zelf aanwezig is. Het ontsleutelen wil je zo laat mogelijk doen en de sleutel wil je dicht bij de gebruiker houden, niet bij de database.

Dat is natuurlijk makkelijker gezegd dan gedaan want nu is software vaak ontwikkeld vanuit de gedachte dat de database alle data tegelijk kan zien en verwerken en met versleutelde data is dat lastiger. Overigens betekent encryptie niet dat de data helemaal niet meer centraal verwerkt kan worden. Er zijn techieken waarmee toch (veilig) bewerkingen kan doen op versleutelde data zonder dat de database die eerst hoeft te decoderen.

Om er nog even een ander paradigma bij te halen: goede beveiliging bestaat uit meerdere lagen die elkaars zwakheden opvangen en afdekken. Een enkele fout of zwak punt zou nooit genoeg moeten zijn om de beveiliging te compromitteren. Menselijke fouten horen daar ook bij en het systeem moet daar rekening mee houden.
Al hoort daar ook bij dat je accepteert dat perfecte beveiliging niet bestaat. je systeem moet enkele fouten kunnen opvangen maar je kan niet alle fouten opvangen. Ik wil ook niet beweren dat iedere zichbare menselijk fout bewijst dat het hele systeem niet deugt. Maar ik hoor iets te vaak dat problemen worden afgeschoven op een "menselijke fout" die in mijn ogen is uitgelokt door een gebrekkig systeem dat een foutloze gebruiker verwacht. Dat is ook een fout.

[DdeM]

Dat zijn toch fouten in de beveiliging?

Voor al die dingen zou ik verwachten dat er processen met geautomatiseerde checks zijn zodat dit niet makkelijk kan gebeuren.

(Wil overigens niet zeggen dat het nooit fout kan gaan hoor, maar dit artikel leest een beetje alsof datalekken bij Booking.com schering en inslag zijn).

[Reactie gewijzigd door DdeM op 22 juli 2024 18:28]

[Timmiejj]

Die geautomatiseerde checks worden in de basis toch ook door mensen gemaakt die ook fouten kunnen maken

Plus iemand heeft in de comments elder ook al aangegeven dat het gross van de datalekken niet bij Booking.com zelf vandaan komt maar bij Hotels die aangesloten zijn op booking.com en gehackt worden, waarbij hun login credentials voor hun booking.com account bemachtigd word.

[Reactie gewijzigd door Timmiejj op 22 juli 2024 18:28]

[Frame164]

Blijkbaar weet jij hoe je het 100% veilig krijgt. Jij patcht natuurlijk alles al voordat de vulnerability gevonden is.... Verhuur jezelf aan booking.com voor 250 euro per uur om ze het uit te leggen.

[Reactie gewijzigd door Frame164 op 22 juli 2024 18:28]

[Aldy]

Je hoeft het niet altijd zelf beter te kunnen om te zien dat een ander het niet goed doet. Een heel goed voorbeeld is nog altijd voetballen. De beste stuurlui zitten op de tribune (of met een bord op schoot )

[wildhagen]

Ik gok dat dat is omdat Booking.com geen helderziende systeembeheerders en/of security-officers heeft, die niet op voorhand kunnen voorspellen wanneer een lek optreed, of wanneer bepaalde vulnerabilities ontdekt worden danwel er een patch voor wordt uitgebracht.

En zoals mensen hierboven opmerken kunnen er altijd gebruikers een fout maken waardoor gegevens gelekt worden. Het is letterlijk onmogelijk om dat te voorkomen, zo simpel is het.

[Met]

Geef een definitie van Security... Wat bedoel je precies?

[Keypunchie]

Deze datalekken zijn dat er gegevens uitlekken omdat een hotel zijn logingegevens gekraakt worden (nou ja, kan gewoon social engineering zijn).

Noodzakelijkerwijs bewaart Booking.com persoonsgegevens voor die hotels. Die zijn dan "gelekt". Als verwerker is Booking vervolgens meldingsplichtig.

[Timmiejj]

Ja maar het is zo fijn om ' Booeeee big corporate' te roepen I guess

[JDx]

Nou daar heb je wat aan, alsof je iemand neersteekt en naar de politie gaat en zegt dat je iemand hebt neergestoken, ja maar ik had het wel op tijd gemeld.

[jvdmeer]

Zo raar is het niet.
"Doorrijden na een aanrijding" kan je ook grotendeels voorkomen door je binnen enkele uren nog te melden bij de politie. (Is wel afhankelijk van de omstandigheden)

[watercoolertje]

Een boete nadat je door rood gereden bent is volgens jou dan ook niet nodig, want je kan het toch niet meer terugdraaien

[JDx]

He? Dat slaat helemaal nergens op.

Het zou beter nieuws zijn als ze minder datalekken hebben.

[NSG]

Melden ze dit ook bij getroffen klanten? Vrij recentelijk zijn er meerdere frauduleuze pogingen gedaan op een creditcard die ik enkel op Booking.com heb gebruikt.

[Wailing_Banshee]

Nee, mijn moeder is recentelijk ook opgelicht. Ze heeft mij het mailtje laten zien wat ze van booking.com kreeg, en die was 100% legit. Alleen de link (blijkbaar) niet. Het mailtje was zelfs logisch aangezien mijn moeder een accomedatie had geboekt en haar CC was verlopen.

En het kwam zo vaak voor dat haar bank (fraude helpdesk) zelfs zei dat ze daar een een procedure voor hadden beschreven.

[robuus]

Daniel Verlaan heeft (een van) de booking fraudezaken die in dit artikel benoemd worden besproken in zijn podcast "Ik weet je wachtwoord". Wel interessant wellicht voor degene die er iets meer van af willen weten.

Aflevering 2, seizoen 3, "De Booking-oplichters".
https://open.spotify.com/episode/0Cxj7FL180ZDmKUUnlLDpE