Kentekens en adresgegevens 50.000 Snappcar-gebruikers uitgelekt via api

Door een lek bij autodeelplatform Snappcar lagen de kentekens en adresgegevens van 50.000 Nederlanders op straat. Die waren op te vragen via de api, ontdekte RTL Nieuws. Het lek is inmiddels gedicht en het bedrijf informeert getroffen gebruikers.

RTL ontdekte het lek na een tip van een lezer en bracht Snappcar daar maandag vóór publicatie van op de hoogte. Het bedrijf heeft het lek direct gedicht, waarna RTL publiceerde. Het bleek mogelijk om via de api informatie op te vragen die niet opvraagbaar zou moeten zijn. Het ging om kentekens en privéadressen van gebruikers.

Snappcar heeft inmiddels een reactie op het nieuws geplaatst. Daarin zegt het bedrijf dat er geen tekenen zijn dat er misbruik is gemaakt van het lek, en dat niemand toegang heeft gehad tot de adresgegevens en kentekens. Ook zegt het bedrijf dat e-mailadressen en wachtwoorden niet via de api te bemachtigen waren. Het bedrijf roept klanten die bezorgd zijn over het lek, op om contact op te nemen. Snappcar heeft de Autoriteit Persoonsgegevens ingelicht en klanten die getroffen zijn geïnformeerd.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (67)

En weer een lek met persoonlijke gegevens.
Dat "makkelijk" toegankelijk is. Hoe komt het toch dat dit soort lekken nog zo vaak voorkomen?
Verkeerd bezuinigen of dit soort projecten aan net van school af werknemers geven?

Wat een belachelijke reactie. Maak jij soms nooit fouten? Dit soort dingen gebeuren zolang mensen de APIs bouwen en beveiligen, het is interessanter hoe het bedrijf vervolgens met het lek omgaat.

Dit hoeft niks met bezuinigingen te maken te hebben en al helemaal niet of het aan recent afgestudeerden is uitbesteedt

[...] Dit soort dingen gebeuren zolang mensen de APIs bouwen en beveiligen, het is interessanter hoe het bedrijf vervolgens met het lek omgaat.

Nee, dit soort dingen gebeuren zolang onervaren mensen APIs bouwen en beveiligen.
@PM_Petrol stelt een aantal vragen. Eentje met daarin de aanname dat op projecten bezuinigd wordt op de verkeerde onderdelen (security bijvoorbeeld) en de andere dat er onervaren medewerkers op projecten gezet worden.

Zelf heb ik bij bedrijven gewerkt waar ook onervaren programmeurs werkten aan kritische systemen. Zij voerden niet enkel taken uit, maar maakten ook beslissingen over architectuur. Daar sluipen fouten in, daarvoor zijn het beginnende programmeurs. Het besluit van een bedrijf om jonge, relatief onervaren (en goedkope) ontwikkelaars op projecten te zetten komt veel vaker voor dan de meeste mensen denken of zien.

Helaas ken ik genoeg bedrijven waar het eerste prototype van een webapplicatie nog altijd draait, met de nodige hacks om het te stabiliseren.

Dit hoeft niks met bezuinigingen te maken te hebben en al helemaal niet of het aan recent afgestudeerden is uitbesteedt

Het zal niet 100% onderdeel zijn van de oorzaak, maar ik durf er toch wel vergif op in te nemen dat ofwel knijpen in het security budget ofwel onervaren programmeurs deels veroorzaker zijn van dit lek.

Sorry, maar ik vind je strekking totaal verkeerd. Ik kom uit de Devops rol en ben zeer betrokken met security op dit moment. Daarnaast ook veel te maken gehad "change management" waardoor ik inzicht heb over de gehele organisatie en niet dat 'ene kleine' stukje waar jij het nu over hebt (onervaren programmeurs, etc.).

Ten eerste is een programmeur met alle respect een nobody binnen de organisatie. Ik bedoel dit niet inhoudelijk of persoonlijk, noch denigerend. Echter draagt een programmeur maar beperkte verantwoordelijkheid. Misschien verantwoordelijk voor zijn stukje code, dat dit wel "goed" moet zijn. Desalnietemin zul je nog steeds processen moeten hebben die zulke dingen kunnen waarborgen. Dus om zo'n hack af te schuiven richting "onervaren mensen die APIs bouwen en beveiligen", vind ik wel heel erg gemakkelijk. Dit is puur kijken naar 'eerste' oorzaak en gevolg. Niet vanuit WAAR die oorzaak vandaan is gekomen.

Er kan net zo goed een project manager en/of IT manager zijn die zorgt draagt dat bepaalde doelen behaald worden. Ook op het gebied van testing & security. Je mag en kan niet verwachten dat 1 programmeur de gehele organisatorische verantwoordelijkheid draagd.

Ook al is een programmeur onbekwaam en/of onervaren. Dan ligt die verantwoording alsnog bij een manager / baas. Hier zijn ook letterlijk rechtsuitspraken op gedaan. Recent nog een casus geweest van een verpleegkundige die door onkunde een grove fout heeft gemaakt. De uitspraak was dat "bedrijf" onvoldoende begeleiding heeft gegeven. Hoewel de verpleegkundige dermate "slecht bezig was", had bedrijf dit moeten signaleren en adequaat op moeten reageren.

Het feit dat men vrijheid krijgt in architectuur is helemaal niet slecht en zeker niet de gehele oorzaak is bepaalde infra niet 'okay' is. Immers vind ik dat hier een rol van CTO of whatever een eindverantwoordelijke rol in moet spelen. In het geven van de vrijheid en waar nodig managen om bedrijfswaardes te waarborgen (en dus ook security, CISO ).

Zolang de big boss de waarde van gedegen producten niet inziet, er geen tijd en geld wordt geinvesteerd in kennis, kunde en rust, dan zal dit ook merkbaar zijn in de rest van de organisatie. Als er geen CISO is. Als er geen seniors zijn die ook nog ruimte krijgen om een veilig product te mogen ontwikkelen of hun kennis te delen met het rest van het team. Zeker als je alleen maar deadlines hebt en niet eens mag/kan werken aan test-cases, pen-tests, of whatever. Visa-versa ook als er geen gedegen mensen binnen de organisatie zitten die juist op een iets hoger niveau deze kernwaardes moeten overbrengen bij management. Maar laten we vooral die ene onervaren programmeur te schuld geven.

-----

Dat allemaal gezegd hebbende. Zolang er geen boeiende post mortem komt met daadwerkelijke details zit iedereen hier maar te gissen. Voor hetzelfde geld is eigenlijk alles best wel in orde en is er toevallig 1 stomme fout geweest. Misschien hebben ze vorige maand nog wel een volledige pen test gedaan en is er pas een nieuwe release geweest. Ik probeer het niet echt goed te praten, want uiteindelijk ben ik wel van mening dat dit echt wel voorkomen had moeten worden. Desalnietemin vind ik het te simpel om van die one-liners te roepen; "daar lag het aan". Want dat is pure onzin.

Mooi perspectief, ben het met je eens.

Mijn punt was niet om de verantwoordelijke aan te wijzen, maar om terug te kijken naar de mogelijke oorzaken van dit lek. Het woord verantwoordelijkheid komt dan ook niet terug in mijn post.

Budget, Visie, Management... Ik benoemde het al kort in mijn post. Nu staat het in jou epistel mooi uitgewerkt.

Jong, onervaren en meestal overmoedig. Vooral dat laatste wil nog wel eens de bovenhand nemen.
ik heb ook de indruk dat er weinig aandacht wordt besteed aan beveiliging in de verschikllende opleidingen en eigenlijk zou dit met stip bovenaan moeten staan.

Jong, onervaren en meestal overmoedig. Vooral dat laatste wil nog wel eens de bovenhand nemen.

Mijn ervaring is dat juist de meest ervaren developers op den duur niet meer kritisch op zichzelf zijn en dan
juist de foutjes in de applicaties sluipen.

Daarom moet je een developer zijn eigen code niet laten reviewen en testen

Uiteraard. Maar als de API openbaar toegankelijk is, dan is het niet beveiligd.
Ik weet niet precies hoe de code hiervoor werkt, maar een wat ervaren developer ziet zoiets toch niet over het hoofd, zeker niet als je in een team werkt.

Een API kan op allerlei manieren openbaar toegankelijk zijn. Dat kan zijn dat er ergens een proxy open stond of dat authenticatie tokens nooit verliepen.

Uit zowel de blogpost van Snappcar als het artikel van RTL wordt niet duidelijk wat exact het probleem is dus het blijft speculatie. Beveiligingsproblemen zitten vaak in een klein hoekje

Er zijn gewoon ontzettend veel plekken waar gegevens staan. Daarom lijkt het ook zo vaak voor te komen.

Niet alleen daar, ik heb zelf bij collega's meegemaakt, dat ik iets tegen kom bij code audits, en ik vraag waarom op bepaalde dingen niet wordt gecontroleerd. Dan reageren ze soms best laconiek dat het bij normaal gebruik gewoon werkt, en kost het anders weer een halve dag om het helemaal dicht te timmeren.

Ik zorg dan dat dat laatste wel gebeurt, maar als er geen audits plaats vinden, bij bijvoorbeeld kleine bedrijfjes die API's enz bouwen, dan gebeurt dit. Je wilt niet weten hoeveel er potentieel lek is als je iets op een andere manier benaderd dan de bedoeling is.

Precies, weird machines vind je echt overal als je gaat zoeken.
SQLi is nog steeds een ding (er zijn zelfs voorbeelden van scholen die dit aanleren, gewoon SQLi in het huiswerk/voorbeelden) hoe makkelijk het ook te verhelpen is.

[Reactie gewijzigd door jozuf op 10 juli 2019 06:54]

Dat komt omdat er ontzettend veel bedrijven in de wereld zijn, en dit nu erg actueel is. Je hoort dus van elke lek. Uiteraard is elke 1 te veel, en zou het niet mogen. Helaas hebben veel bedrijven nog steeds andere prioriteiten en zal dit vermoed ik helaas altijd blijven. Zo lang mensen IT systemen maken blijven criminelen manieren vinden om binnen te komen

Goedkope junior developers op een plek zetten waar ze niet horen te zitten.
Of voor een dubbeltje op de eerste rang willen zitten en je project en\of beheer outsourcen naar een vage asiatische club.

Laatste tijd lekt alles, of is het perrongeluk, persoonsgegevens online enz...
hele internet is een wazig iets geworden anno 2019 belastingdienst nog systemen heeft uit de jaren 80
voorwaar ik zeg je het grote moment moet nog komen alles plat en dan heb je werkelijk een chaos
zogenaamde storingen, atm die niet werkt vanwege een storing, routing wat verkeerd heeft uitgepakt hele telefonie paar uur plat 112 onbereikbaar met alle gevolgen. ik neem ook niets meer voor waar! Grote jongens in de ICT' die opstappen omdat de verantwoordelijkheid er zwaar gaat wegen ...enz..
Gaat de laatste tijd behoorlijk mis maar te zwijgen over persoonsgegevens BIG business, en dan nog het hilarische reclamespotje de bank in je zak, de bank die op basis van je koop gedrag .......
Apps die alsnog ondanks, deze geen rechten zijn verleend gegevens verzenden.
Apps die toegang,rechten moeten hebben tot werkelijk alles , nieuwe telefoons met bloatware en crap
langzaam maar gestaag word er zo steeds meer geopenbaard
Hele playstore die 30% opstrijkt per betaalde app
Jammer maar hoop alsnog dat er een Ubuntu phone , linux of o.s komt wat niet afhankelijk is van playstore.
Google backup staat geblokkeerd op mijn phone tel zo een 20 tal ip adressen wat als nog probeert om een backup te maken of toegang wil. en zo meerdere apps met X tal ip adressen

[Reactie gewijzigd door Jeroen hofman op 9 juli 2019 22:45]

Tja, een lek is snel genoeg gevonden. Ik heb zelf een tijdje mijn oldtimer verhuurd bij Snappcar! Opzich prettige organisatie maar ze zijn in korte tijd wel ontzettend groot geworden. Op dit moment verhuur ik op www.loyaltyride.nl voor mij iets klein schaliger.

Ik denk dat het opzich zelf staand niks te maken heeft met bezuiningen.

Door een lek bij autodeelplatform Snapcarr lagen de kentekens en adresgegevens van 50.000 Nederlanders op straat.

Daarin zegt het bedrijf dat er geen tekenen zijn dat er misbruik is gemaakt van het lek, en dat niemand toegang heeft gehad tot de adresgegevens en kentekens.

Wait what? Dus RTL toont aan dat ze er bij kunnen, maar niemand heeft er bij gekund?
Klinkt niet heel plausibel.

Dat staat ook niet in de blog van Snappcar, dus ik weet niet waar deze conclusie vandaan komt.

Jawel; 4e alinea van het blog bericht begint met:

Er is op dit moment geen indicatie dat er daadwerkelijk adresgegevens of kentekens bemachtigd zijn door derden.

'Er is geen indicatie' bla bla is een voorzichtige stelling dat zij niet kunnen concluderen dat er misbruik is gemaakt van het lek.

[Reactie gewijzigd door xoniq op 9 juli 2019 17:00]

Er is geen indicatie als je uberhaubt niet logt wie er toegang heeft gehad. Geen indicatie klinkt alleen wat beter.

Klopt. Maar ‘geen indicatie’ is een heel voorzichtige stelling om de boel te sussen, en als er wel iets blijkt te gebeuren, dan is er hier gelogen, ‘er was op dat moment alleen geen indicatie hiervan’.

Zulke termen gebruiken vind ik nogal te voorzichtig.

Maar als je gewoon geen indicaties hebt dat er misbruik is gemaakt is de uitspraak ook gewoon waar. Hou altijd in de gaten dat de meeste lekken gevonden worden voor er misbruik van is gemaakt. Met iets als adres + kenteken is het makkelijk te zien of die data ergens te koop is) of dat die werkelijk geld waard is. Naam en adres staan tenslotte voor 94% in het telefoonboek.

Maar als je gewoon geen indicaties hebt dat er misbruik is gemaakt is de uitspraak ook gewoon waar.

Het gaat er niet om of de uitspraak waar is, het gaat erom dat de uitspraak nietszeggend is.

"Er is op dit moment geen indicatie" is ook waar als

• je nog niet begonnen bent met zoeken
• je wel begonnen bent met zoeken maar je überhaupt niet in staat bent om misbruik te constateren

Ik heb geen telefoonnummer in het telefoonboek. Maar maak me wel zorgen over de gelekte gegevens. Ik kreeg toevallig vandaag een phising sms. Rabobank wereldpas. Zie oa oplichting van Tros circa januari 2019. Het nummer dat is gebruikt vandaag is 06 87172863.Ze hebben wellicht al van mijn 06 nummer gebruik gemaakt, dit staat namelijk bij mijn adresgegevens.

Geen e-mail van Snappcar! En een reactie op een blog dat er geen gebruik van is gemaakt zegt niks. Iedereen kan dit verklaren, zonder onderzoek te doen. En ook al is er onderzoek gedaan dan gaat het om de kwaliteit van de onderzoeker die eventuele schade kan achterhalen. Ik wacht even af wat er gebeurt.

Er is op dit moment geen indicatie dat er daadwerkelijk adresgegevens of kentekens bemachtigd zijn door derden. Daarnaast zijn er op geen enkel moment andere type gegevens (zoals wachtwoorden, e-mailadressen of financiële gegevens) openbaar geweest. Ook zijn gegevens van huurders nooit openbaar toegankelijk geweest.

Ik denk dat het moet slaan op de gegevens van de verhuurders, het is inderdaad niet juist verwoord door Tweakers.

Plus dat RTL niet zelf actief zoekt naar lekken, maar tipgevers najaagt. Dus er is tenminste nog iemand die het lek heeft gevonden en RTL heeft getipt.

Rtl heeft daar zelf wel de kans kennis voor. Een van hun journalisten won onlangs nog een prijs.

Inderdaad:
https://www.rtlnieuws.nl/...eek-bottema-camera-talent

Ik claim ook nergens dat RTL daar geen kennis van heeft, maar het lijkt me stug dat werknemers zelf vanuit het niets lekken zoeken in API’s. Lijkt me dat we eerst een tip over komt, en dat ze op onderzoek uit gaan. Als ze de kennis niet hadden konden ze dit zelf ook niet onderzoeken natuurlijk.

men beweert niet dat niemand erbij kon, maar dat er geen teken van misbruik is, wat naar mijn menig nu ok weer niet wil zeggen dat dit er niet geweest is, geen teken van is nogal een vaag begrip

Nee, maar zoals Tweakers het schrijft staat er letterlijk dat niemand er bij heeft gekund, maar het is dus inderdaad alleen dat er geen aanwijzingen zijn dat het misbruikt is (wat al helemaal niet betekend dat niemand er bij geweest is die dat niet had moeten kunnen).

Ai ai ai ai. Zo slecht dit. Heel slecht voor hun imago, maar nog slechter is dat dit soort data 'gewoon' in het openbaar terecht komt.

Waar baseer je dit op? Ik lees dat RTL het artikel heeft gepubliceerd na het dichten van de lek. Wat dat betreft vind ik dat RTL professioneel heeft gehandeld en hiermee een grotere potentiële datalek heeft geminimaliseerd.

Dat laatste is sowieso netjes, maar je hebt geen idee hoe lang dit al open staat, en hoe lang dit al is misbruikt. RTL die komt er ook niet bij toeval achter, die is ook gewoon getipt, waardoor RTL niet de enige is die wist van het lek.

Met een beetje deftig logsysteem moet dat prima kunnen. Dat iets open staat kan je misschien nooit achter komen. Maar een beetje requests loggen kost amper overhead. Achteraf terugkijken of bepaalde api requests misbruikt zijn sinds introductie hoeft geen probleem te wezen.

dat zijn al 2 aannames,

1. er is een systeem dat requests logt
2. logfiles worden daadwerkelijk bijgehouden.

Klopt, dat is een nadeel en nalatigheid ook wel vanuit de site. Daarom zei ik ook potentiële want de consequenties van een datalek zijn vrijwel altijd lastig te meten

Heel slecht voor hun imago

Ik hoop het ergens, maar in praktijk zie ik er heel weinig van. Ik kan geen voorbeelden noemen van bedrijven die echt nadeel hebben gehad van de berichtgeving over een datalek. Ken je ahsleymaddison.com nog? Dat is een dating site voor overspel. Die site heeft een groot datalek gehad en heeft dat gewoon overleefd. Ik kan me weinig sites bedenken die meer privacygevoelig zijn.

Veel mensen doen nog steeds een beetje lacherig over IT-beveiliging. Ik geloof dat ze het accepteren omdat ze zelf ook niks snappen van IT en de daar bij horende beveiliging, en het eigenlijk heel normaal vinden dat IT een onveilige en onbegrijpbare puinhoop is. De beste stuurlui staan aan wal, maar in het geval van IT kunnen die stuurlui het water niet vinden.

[...]

Ik hoop het ergens,

Ik hoop dat ze er lering uit trekken i.p.v. dat ze een deuk in hun imago krijgen.

[...]
Veel mensen doen nog steeds een beetje lacherig over IT-beveiliging. Ik geloof dat ze het accepteren omdat ze zelf ook niks snappen van IT en de daar bij horende beveiliging, en het eigenlijk heel normaal vinden dat IT een onveilige en onbegrijpbare puinhoop is.

Dat ze het niet snappen wil niet zeggen dat ze het daarom maar bewust accepteren.

Dat blog bericht doet er nogal luchtig over. Dat alleen mensen met een 'specifieke' methode erbij konden (ja dus? Er is nog zoiets als Pastebin om al die gegevens op te dumpen), en dat er verder geen gegevens gelekt zijn. Ik vind de adresgegevens enz toch al teveel.

Ze zullen de logs wel hebben bekeken van wat er opgevraagd is geweest?

[Reactie gewijzigd door kuurtjes op 9 juli 2019 16:52]

De vraag is houden ze logs bij voor elk aanvraag? Hoogst waarschijnlijk niet.

Vrij generieke verklaring dus.

Om deze reactie te plaatsen moet ik ook een vrij specifieke methode gebruiken...

Ik heb geen 'indicatie' kunnen vinden dat jij een 'specifieke methode' hebt gebruikt om die reactie te kunnen plaatsen.

Handig als je nog een Audi RS 6 nodig hebt voor je volgende klusje.

Om welke API gaat het?
Een API tussen de klanten-app en de servers of tussen de servers en derden die in deze informatie mogen grasduinen. Paswoord en email uitgezonderd. Als het het eerste is dan zou ik verwachten dat email wel is op te vragen namelijk.

Of als je nog een nummerplaat nodig hebt voor op die RS6.

Denk jij dat iemand zijn Audi RS6 deelt ja?


"Door een lek bij autodeelplatform Snappcar lagen de kentekens en adresgegevens van 50.000 Nederlanders op straat. Die waren op te vragen via de api, "

en even verder

"Daarin zegt het bedrijf dat er geen tekenen zijn dat er misbruik is gemaakt van het lek, en dat niemand toegang heeft gehad tot de adresgegevens en kentekens."

Dus ze lagen op straat, maar niemand (behalve RTL en de tipgever) heeft die gegevens bemachtigd?
Er waren geen tekenen, maar wat als iemand bij de gegevens heeft kunnen komen, zonder sporen achter te laten? Of heeft het bedrijf die optie uitgesloten? Anders heeft hun uitspraak geen waarde...

[Reactie gewijzigd door T-Rut op 10 juli 2019 09:15]

Denk jij dat iemand zijn Audi RS6 deelt ja?

lol, touché..

"Daarin zegt het bedrijf dat er geen tekenen zijn dat er misbruik is gemaakt van het lek, en dat niemand toegang heeft gehad tot de adresgegevens en kentekens."

Dus ze lagen op straat, maar niemand (behalve RTL en de tipgever) heeft die gegevens bemachtigd?
Er waren geen tekenen, maar wat als iemand bij de gegevens heeft kunnen komen, zonder sporen achter te laten? Of heeft het bedrijf die optie uitgesloten? Anders heeft hun uitspraak geen waarde...

Mja..
Dat er niemand is binnen geweest kun je niet echt bewijzen.
Daarom stinkt deze verklaring.

wauw .. best slecht dit. Dus er was een API gewoon open

https://blog.snappcar.nl/...ar-op-artikel-rtl-nieuws/

"Gistermiddag 8 juli 2019 is SnappCar door een journalist van RTL Nieuws gewezen op een onbeveiligde toegang tot data op ons platform, via een zogenaamde ‘API’. Via deze toegang was het mogelijk voor derden met de juiste technische kennis adresgegevens en kentekens van autoverhuurders op te zoeken zonder ingelogd te zijn met een SnappCar-account."

Titel, nieuws, best tegenstrijdig toch?
en dat niemand toegang heeft gehad tot de adresgegevens en kentekens
uitgelekt via api

Goed, RLT is natuurlijk ook meer sensatie dan nieuws, maar liggen die 50k gegevens nu wel of niet op straat? Feit dat ik ergens bij kan, betekent niet dat dit dan ook direct op pastebin te vinden is.

We willen benadrukken dat het risico op een ernstige inbreuk van de privacy, zoals identiteitsfraude, zeer klein is. Met name omdat geen andere gegevens openbaar zijn geweest en dat alleen mensen met specifieke technische kennis, na een aantal handelingen, bij de adresgegevens en kentekens konden

Ook het lekken van naam en adresgegevens kan leiden tot ernstige inbreuk. Dat is onder andere waarom die combinatie van gegevens niet publiek hoort te zijn en dit soort ernstige vormen van datalekken gemeld moeten worden en de betrokkenen zelfs geinformeerd moeten worden.

Snappcar probeert hier de situatie te bagatelliseren door er irrelevante andere ernstige vormen van inbreuk die niet mogelijk zijn erbij te betrekken. Het gaat er om wat wel kan. En de kans daarop neemt ook niet af doordat irrelevante andere vormen van inbreuk niet mogelijk zijn.

Ik vind het eigenlijk niet kunnen dat een bedrijf dat de gegevens slecht beschermd zelf een bagatelliserende mededeling doet dat het allemaal wel mee zou vallen voor de personen die het treft. En ook nog op een volledig ontransparante wijze tot een oordeel komt zonder duidelijk te zijn waarom hun stelling de juiste zou zijn.

[Reactie gewijzigd door kodak op 9 juli 2019 18:40]

Ook het lekken van naam en adresgegevens kan leiden tot ernstige inbreuk. Dat is onder andere waarom die combinatie van gegevens niet publiek hoort te zijn en dit soort ernstige vormen van datalekken gemeld moeten worden en de betrokkenen zelfs geinformeerd moeten worden.

Pst.... hier is een lijst met vrijwel alle mensen die de vries heten en in Amsterdam wonen (niet doorgeven aan marketeers hoor!): https://www.telefoonboek.nl/personen/vries/amsterdam/. En toen ik gisteren de hond uit liet zag ik zelfs dat heel veel mensen hun naam op hun door hadden staan! Hebben die mensen geen enkele notie van privacy?

De meeste brave tweakers met kinderen die op de achterste benen staan bij elk datalek staan gewoon in het telefoonboek maar denken dat hun naam+adres via een super geheime hack bij marketeers terecht is gekomen waardoor ze nu post krijgen.

[Reactie gewijzigd door Anoniem: 310408 op 9 juli 2019 20:03]

De meeste brave tweakers met kinderen die op de achterste benen staan bij elk datalek staan gewoon in het telefoonboek maar denken dat hun naam+adres via een super geheime hack bij marketeers terecht is gekomen waardoor ze nu post krijgen.

Bij dit soort claims over tweakers of marketeers verwacht ik toch wel een onderbouwing. Je doet anders maar wat loze uittingen om zogenaamd een punt te maken.

Daarbij gaat privacy via persoonsgegevens niet om wat er allemaal onterecht gedaan kan worden maar wat als eigenaar je rechten zijn en wat de plichten voor anderen zijn die van je gegevens gebruik maken. Als iemand zijn naam bij de deur wil hangen of in een telefoongids wil staan dan is dat onder de geldende voorwaarden een goed recht. Dat een ander er misbruik van kan maken is niet de schuld van het slachtoffer en indien iemand er ook misbruik van maakt is dat voor de verantwoordelijkheid van de persoon die de wet niet wenst te respecteren.

Om de kans te verkleinen dat iemand persoonsgegevens onrechtmatig gaat gebruiken valt natuurlijk te opperen dat mensen voorzichtiger met hun gegevens kunnen omgaan. Maar het is de wereld op zijn kop als iemand die gebruik maakt van zijn rechten dan de beschuldiging zou krijgen dat die dat dan maar niet had moeten doen als iemand anders andermans rechten, verboden zaken en eigen plichten naast zich neer legt.

Misschien moeten we maar eens wat terughoudender worden met het plaatsen van onze gegevens in "The Cloud". Er is inmiddels elke week wel een significante datalek. Óók bij organisaties waarvan je zou mogen verwachten dat ze weten hoe je data afdoende beveiligt.

[Reactie gewijzigd door Tyrian op 9 juli 2019 16:52]

Ja, want on-prem heb je geen publieke API's

Wat heeft de cloud hiermee te maken? Er was gewoon een API endpoint helemaal open. Dus bij het maken van de feature van de endpoint ging men niet eens eerst afvragen of dit een beveiligde endpoint moest zijn.

Ik denk dat men eerst de feature gingen maken (dus zonder beveiliging, want ja dat is makkelijker), nooit meer aan gedacht hadden om het te beveiligen en gewoon live gingen.

Dan heb je 1 oplossing. Netwerkkabel uit je pc en smartphone het water in. Voor de rest zal je data altijd ergens staan. Cloud of niet maakt hierbij niks uit.

Tja, zo gaat het digitaal. vandaag komen hier gegevens op straat en morgen weer van iets anders. zo weinig mogelijk gegevens opslaan bij zorginstantie, Energiemaatschappij etc etc.