Chaos Computer Club kreeg via lek coronalijst Duitse restaurantbezoekers

Leden van de Duitse Chaos Computer Club wisten toegang te krijgen tot een onlinedienst die restaurants gebruikten om gegevens van bezoekers op te slaan, om contact op te kunnen nemen bij gevallen van een coronabesmetting.

In totaal kregen de Chaos Computer Club-leden toegang tot 87.313 coronacontacten van 180 restaurants die gebruikmaakten van het systeem. Dat systeem is van het bedrijf Gastronovi en restaurants kunnen hiermee ook reserveringen, bestellingen en kassatransacties bijhouden. Via de kwetsbaarheid konden de hackers ook 5,4 miljoen reserveringen inzien, waarmee 4,8 miljoen klantgegevens gemoeid waren. Het ging om data van de afgelopen tien jaar.

De onderzoekers claimen 'in een handomdraai' met volledige beheerdersrechten toegang tot alle in het cloudsysteem opgeslagen gegevens te hebben verkregen. Ze troffen ook andere fouten in de api aan, waarmee bijvoorbeeld restaurant A de coronagegevens van restaurant B kon inzien. Bovendien waren opgeslagen wachtwoorden voor een deel niet versleuteld.

Leden van het Chaos Emergency Response Team kregen bij een restaurantbezoek argwaan toen ze hun gegevens moesten opgeven voor de coronalijst, en hen verzekerd werd dat deze veilig bij een clouddienst opgeslagen zouden worden. Gastronovi heeft na de melding van de CCC bevestigd dat er een kwetsbaarheid was en deze gedicht.

De dienst verwijst naar restaurants om oude gegevens te verwijderen, maar die leken volgens de CCC ervan uit te gaan dat die verantwoordelijkheid bij Gastronovi lag. De club noemt het doel om restaurantbezoekers snel te kunnen informeren in geval van een coronabesmettingen legitiem en belangrijk, maar raadt daarbij het gebruik van clouddiensten af. "De gevoelige gegevens komen dan niet in het restaurant terecht, maar op een grote stapel ergens op het internet, waar ze de komende jaren op geïnteresseerde hackers zullen wachten", aldus een woordvoerder van de CCC. Restaurants zouden volgens de club op papieren lijsten moeten overstappen.

Reacties (69)

[jj71]

De onderzoekers claimen 'in een handomdraai' met volledige beheerdersrechten toegang tot alle in het cloudsysteem opgeslagen gegevens te hebben verkregen. Ze troffen ook andere fouten in de api aan, waarmee bijvoorbeeld restaurant A de coronagegevens van restaurant B kon inzien. Bovendien waren opgeslagen wachtwoorden voor een deel niet versleuteld.

Dit soort geknutsel komt zo ontzettend vaak voor... Ik stel me voor dat het meestal op zo'n soort manier ontstaat:

Ondernemertje heeft een leuk idee, maak een online dienst voor restaurants waar ze reserveringen kunnen doen en andere dingen zoals corona-gegevens kunnen bijhouden. De ondernemer zoekt een paar whizzkids die even snel zoiets in elkaar kunnen knutselen. De whizzkids gaan aan de gang, het moet vooral snel en goedkoop. Ze knallen er een MVP uit (Minimum Viable Product) waarbij er niet teveel naar details worden gekeken; het belangrijkste is dat het zo snel mogelijk live is. Na een paar weken hebben ze een werkende MVP. De ondernemer gaat het verkopen bij restaurants en we zijn live!

En dan wordt er vervolgens maar even vergeten dat een MVP geen volledig en netjes dichtgetimmerd product is. Die security enz. dat is maar moeilijk en kost veel extra tijd en geld, dus dat is gemakkelijk om op de lange baan te schuiven of maar helemaal te vergeten.

En op een dag komt er een hacker langs en blijkt de service zo lek als een mandje te zijn...

[CAPSLOCK2000]

Ondernemertje heeft een leuk idee, maak een online dienst voor restaurants waar ze reserveringen kunnen doen en andere dingen zoals corona-gegevens kunnen bijhouden. De ondernemer zoekt een paar whizzkids die even snel zoiets in elkaar kunnen knutselen. De whizzkids gaan aan de gang, het moet vooral snel en goedkoop. Ze knallen er een MVP uit (Minimum Viable Product) waarbij er niet teveel naar details worden gekeken; het belangrijkste is dat het zo snel mogelijk live is. Na een paar weken hebben ze een werkende MVP. De ondernemer gaat het verkopen bij restaurants en we zijn live!

Yup, zo gaat het.
Er is misschien een andere ondernemer die het wel goed doet, maar die heeft meer ontwikkeltijd nodig en is duurder uit. Iedereen kiest dus het goedkope product van de "marktleider". Die zou nooit zo groot zijn geworden als het product niet in orde was, denkt men dan.

Eat shit! Billions of flies can't be wrong!

Die marktleider belooft uiteraard dat er beveiliging toegevoegd gaat worden, maar moet nog leren dat je veiligheid in het ontwerp moet meenemen en niet achteraf kan toevoegen.

De klanten/gebruikers kun je weer verwijten dat ze hun huiswerk niet hebben gedaan. Inmiddels zou je moeten weten dat er enorm veel slechte software is en dat je dat niet van buiten kan beoordelen. Als professionele organisatie zal je zelf de kwaliteit van software in de gaten moeten houden met behulp van audits, pen test rapports en eigen onderzoek.

De overheid verwijt ik dat ze het helemaal aan de markt overlaten terwijl iedere expert weet dat de meeste bedrijven en personen niet in staat zijn om veiligheid zelf goed te beoordelen. De overheid begint langzaam bij te draaien, maar levernaciers zouden gedwongen moeten worden om meer verantwoordelijkheid te nemen voor de veiligheid van hun product in plaats van alle verantwoordelijkheid te ontwijken via licentievoorwaarden.

[Reactie gewijzigd door CAPSLOCK2000 op 25 juli 2024 07:40]

[Skit3000]

Via wetgeving zou dit mogelijk op te lossen zijn. Je kan daarmee niet beschermen tegen een programmeur die even snel iets in elkaar flanst en daarbij fouten maakt, maar je kunt wél zorgen dat gegevens enkel gecodeerd opgeslagen mogen zijn. Sterker nog, dit hoef je niet eens in een wet te zetten. Je kunt ook gewoon de wet zo schrijven dat een onderneming gegevens niet op mag slaan op een server die onder eigen beheer staat. Aangezien je dan jouw data op een server van een derde partij (die je niet noodzakelijkerwijs kunt vertrouwen) moet zetten, ga je vanzelf op voorhand al nadenken over hoe je die data beveiligd. Het enige zwakke punt zit 'm dan nog in de applicatie zelf waar je de gegevens weer decodeert voordat je ze aan de eindgebruiker voor kunt schotelen.

[CAPSLOCK2000]

Je kunt ook gewoon de wet zo schrijven dat een onderneming gegevens niet op mag slaan op een server die onder eigen beheer staat. Aangezien je dan jouw data op een server van een derde partij (die je niet noodzakelijkerwijs kunt vertrouwen) moet zetten, ga je vanzelf op voorhand al nadenken over hoe je die data beveiligd.

Ik ben het met je eens dat de wet een groter rol moet spelen.
Ik geloof helaas niet dat het gebruik van een externe server iets gaat veranderen. Mijn verwachting is dat er op software niveau weinig zal veranderen. We maken nu al op grote schaal gebruik van "cloud" diensten en VMs die allemaal hun data opslaan op een platform dat door anderen wordt beheerd. Ik zie vooral mensen die, tegen beter weten in, doen alsof zo'n cloud VM hetzelfde is als de desktop op hun bureau of de server in het lokale datacenter.

[Reactie gewijzigd door CAPSLOCK2000 op 25 juli 2024 07:40]

[Skit3000]

Ja er zit dus meer achter. Zodra iemand zelf gaat zitten goochelen weet je nooit wat er uit komt, maar in principe kan je bij elke DBMS de rechten van gebruikers limiteren tot enkel INSERT (wat precies het enige is dat nodig is bij de applicatie uit dit nieuwsbericht). Als iemand zelf gaat knutselen en al blij is een en ander werkend te krijgen met de root account dan kan je verdere beveiliging op dat niveau niet snel meer verwachten en wordt het waarschijnlijk op applicatieniveau geregeld wat goed mis kan gaan zodra er een fout in de code zit.

Waar ik op hoop als ik schrijf dat gegevens op een externe server moeten komen, is dat er aanbieders komen die databaseservices verlenen via een REST API die via javascript te benaderen is en waarbij deze partij ook het gebruikersbeheer doet en een inlogpagina verzorgt. Wanneer je dan een "coronalijst" maakt en een restaurant als gebruiker aanmaakt, dan geef je gelijk aan dat deze gebruiker alleen nieuwe regels toe mag voegen aan de database (want je snapt dat als je meer rechten geeft, dit gelijk inhoudt dat deze gebruiker meer kan doen dat je wilt) en is het risico op een datalek op applicatieniveau weg.

[bzzzt]

Misschien werkt het beperken tot het uitsluitend toevoegen van gegevens in dit specifieke geval goed, maar in de praktijk wil een gebruiker doorgaans de ingevoerde gegevens ook weer een keer opvragen.

[Tubby]

Dit is in essentie wel het probleem, je benoemt hetzelf door te zeggen "... dat gegevens enkel gecodeerd opgeslagen mogen zijn ..."

Dit soort implementatie details moet je vooral niet benoemen in wetgeving, het maakt namelijk niets uit of je gegevens gecodeerd opgeslagen zijn of niet. Dan kun je ook perfect een onveilige situatie creeren, laat dat maar over aan een ontwikkelaar met net iets te weinig kennis en iets te veel druk van sales

Wat wel relevant is hoe je je database beveiligd hebt, hoe de verbindingen tussen jou en de webserver verloopt en tussen de servers onderling en hoe dat verder beveiligd is met netwerken / firewalls, maar dat is helaas niet zo triviaal als eisen "dat data alleen gecodeerd opgeslagen" mag worden

[Groningerkoek]

Een onderneming gegevens niet op mag slaan op servers die onder eigen beheer staan....

Vind dit wel extreem ver gaan, nog even los van de problemen waarmee je veel bedrijven met als duidelijkste voorbeeld Google opzadelt zijn er voldoende bedrijven die hun zaken prima op orde hebben.

[Skit3000]

Stel dat het altijd al zo zou zijn geweest, dan was een verplichting dat een bedrijf data op eigen servers op slaat opeens "extreem ver gaan". De grootste problemen die we tot nu toe hebben gezien met gelekte persoons- en bedrijfsgegevens zijn bijna allemaal terug te voeren op onveilige opslag van data. Uit verplichten dat bedrijven hun gegevens ergens anders opslaan (dat kan dus bij wijze van spreke bij de concurrent zijn) rolt vanzelf voort dat bedrijven écht na gaan denken over hoe ze dit 100% veilig kunnen doen (want anders krijgt hun concurrent wellicht de data te zien).

[Renoir]

Zo word een proof of concept verward met een mvp. Want een mvp moet in ieder geval viable zijn en dat betekent bij persoonsgegevens ook dichtgetimmerd.

[SlaadjeBla]

In mijn ervaring werd viable altijd puur economisch uitgelegd: het moet verkoopbaar zijn. Hoe het onder de motorkap eruit ziet, daar kijkt toch niemand naar. Tuurlijk hoort dat anders, maar er moet zo snel mogelijk geld in het laatje komen.

[bzzzt]

Dat is dan toch puur een wetgeving kwestie?

Voor de juiste regulering waren auto's rijdende grafkisten, maar tegenwoordig moet alles aan strenge eisen voldoen voor het de weg op mag. Tijd om wat ICT 'botsproeven' verplicht te maken voor je een vergunning krijgt om een site online te zetten die gevoelige data verwerkt misschien? En een flinke boete als je dat nalaat...

[Annihlator]

Dat is echter voor fysieke situaties, zoals bij het voorbeeld van botsingen, veel makkelijker te voorspellen dan in de wereld van software, waar er zat voorbeelden zijn van iets wat de ene dag als geheel veilig beschouwd werd, het andere moment onveilig BLIJKT te zijn.
Zéker wanneer je nagaat dat je dit soort problemen kan proberen dicht te timmeren op individuele niveaus, is er dan alsnog het voorbeeld wanneer eer een low-level/kernel-level exploit gevonden word; Ik denk niet dat je zo'n mogelijkheid op voorhand uit kan sluiten zónder dat volgens genoeg "marketing-experts" het product te duur wordt om te verkopen; hierom komen we ook gewoon afgelopen jaren steeds meer geknoei tegen, de programmeurs die de problemen op voorhand kunnen inschatten zouden hen handen er niet zo snel aan branden. Nieuwere programmeurs zien het dan mogelijk vooral als een kans om zich te onderscheiden, en óf daar hebben ze geluk in, of zullen in de praktijk tot een andere conclusie/ervaring komen.

[Reactie gewijzigd door Annihlator op 25 juli 2024 07:40]

[sympa]

Bij fysieke veiligheid worden er harde eisen gesteld. Elektra is aangelegd op een standaard manier. Het kan op veel andere manieren ook, en vast zelfs veiliger. Maar er is een werkwijze die gevolgd moet worden en die makkelijk te controleren is.
Voor het opslaan van data kan zo'n goedgekeurde methode ook verplicht worden gesteld.
En als je daar niet aan kan of wil voldoen zit je aan een lang goedkeuringstraject vast. Dat is dan een consequentie.

[Annihlator]

Dat is waar, maar de natuurwetten zijn nou eenmaal vele malen minder veranderlijk dan de onderdelen die binnen softwareland meespelen.
Als mensen hebben we de neiging een standaard zo compléét mogelijk uit te denken, en in een wereld beperkt door natuurwetten gaat dat simpelweg makkelijker dan een landschap waar het zo veranderlijk is dat men zo goed als onmogelijk kan voorspellen binnen wat voor tijd (bijv.) de huidige als veilig-beschouwde vormen van bijvoorbeeld encryptie niet meer als veilig beschouwd kunnen worden.

Waar we in de vergelijking met fysica vooral nog nieuwe dingen leren over de dingen op de kleinste schaal en alles op de schalen die voor ons belangrijk zijn/lijken is nagenoeg alles wel gesneden koek. Maar in software-/tech-land lijkt het veelal zo dat we vooral nog bekend zijn met de hogere lagen. Het aantal personen dat gebaseerd op high-function implementaties zuiver kan beoordelen wat voor mogelijke implicaties het meebrengt op low-level is nou eenmaal relatief klein, en lijkt m.i. zelfs naarmate de tijd vordert enkel kleiner te worden.
Dit zijn heden-ten-dag veelal experts, de mensen die of destijds op dat niveau interactten met de elementen en die ervaring ermee opgedaan hebben. En laat dat net de schare mensen zjin die niet bij de start van dit soort projecten betrokken lijken te worden omdat de meeste mensen die die schijbaar individuele afweging maken het tot zover al snel eerder als een onkostenpost als een risc-management kans lijken te beschouwen...

Misschien is het "nodig" dat er een goedkeuringstraject ontstaat, maar ik vraag mij dan ook oprecht af wat voor impact dit kan hebben voor de vrijheid/openheid van de algehele softwaremarkt.
Kan dit proces danwel door de complexiteit ervan of de overhead er bijvoorbeeld voor zorgen dat hoofdzakelijk grotere namen zich nog willen bemoeien met gegevensverwerking en kunnen we dat als een positief aspect beschouwen? Maakt dat het risico niet tegelijkertijd groot dat een (nieuwe) partij die zichzelf als too big to fail beschouwt nogal FB-achtige praktijken er op na laat? (Schone schijn voordoen voordat ze daadwerkelijk controle heeft gedaan) en vervolgens áls ze een flater slaan, is dan de schade niet mogelijk groter? Of vinden we het dan vooral belangrijk dat we wel naar die partij kunnen wijzen als "de schuldige"?

Ik vrees dat we dat soort overwegingen soms wat lijken te passeren, ondanks de beste intenties.

[sympa]

Ik kan me voorstellen dat het neerkomt op een aantal 'datakluizen' die goedgekeurd zijn. Die niet snel verkeerd in te zetten zijn.
Ik denk even terug aan mijn beginjaren met hardware sleutelen. Met ESD-bandjes. Maar ik had mezelf aangeleerd om met 1 hand het chassis te pakken en met de andere te werken. Alleen een polsbandje als ik met 2 handen moest klussen.
Mijn collega's dachten: "hij doet het zonder, dan wij ook". Tja, dat ging dus behoorlijk mis.
Daarom zijn er polsbandjes. Kan de baas zien dat je het goed doet. En daarom zijn er regels nodig over wat goed is en wat niet.

[xs4all.user]

Wat is nat.

Het juridische systeem is totaal verstopt. Te veel zaken. Te veel overtredingen. Justitie vervolgt alleen nog het laaghangend fruit. (en de allergrootste criminelen omdat ze die niet kunnen negeren)
En de agent op straat zorgt alleen nog dat hij zijn proces verbaal quotum haalt. Zodat hij netjes zijn salaris krijgt, en een normale beoordeling op zijn jaargesprek.

Winstmaximalisatie, zelfs het opzoeken van belasting-ontwijking-truuks, word door bijna de hele maatschappij aangemoedigd. En bijna iedereen gaat voor het goedkoopste product.

Dus wat verwachten wij? Dat mensen/bedrijven worden aangepakt omdat ze onze privacy niet serieus nemen?

Laat me niet lachen.

Tweakers en alle andere nieuws sites kunnen hier nog 100 jaar over berichten. Er gaat NIETS veranderen. Waarom zou er IETS veranderen?

[Reactie gewijzigd door xs4all.user op 25 juli 2024 07:40]

[Rutger Muller]

Misschien wat mierenneukerig, maar bij een product waar security een hoge prioriteit heeft is het dus geen MVP wanneer dat niet op orde is. Dat is dan namelijk 1 van je core features bij uitrol.

[Reactie gewijzigd door Rutger Muller op 25 juli 2024 07:40]

[Yalopa]

Dit heeft niets met cloud te maken, maar alles met slecht ontworpen en beheerd. Deze fouten hadden er on prem evengoed in gezeten..

[Sebazzz]

Dit heeft niets met cloud te maken, maar alles met slecht ontworpen en beheerd. Deze fouten hadden er on prem evengoed in gezeten..

Ja, maar daar hadden fouten zoals dit geen effect gehad:

Ze troffen ook andere fouten in de api aan, waarmee bijvoorbeeld restaurant A de coronagegevens van restaurant B kon inzien.

Als je één applicatie host waarop meerdere bedrijven zitten met een dataset, dan ga je vaak logische scheiding aanbrengen zodat men niet bij de data van een ander kan.

Als je het echter implementeert door fysieke scheiding aan te brengen via gescheiden databases (dus bijvoorbeeld bepaald "abc.myrestaurantsystem.com" dat het systeem naar database "abc" moet kijken) dan kan je dat ondervangen en wordt de foutgevoeligheid lager. Anders blijf je hiermee zitten.

[latka]

Slecht ontworpen formulier in het restaurant wat bij de eigenaar onder kassa ligt is toch een stuk minder gevoelig dan via een centrale digitale omgeving. Dus cloud speelt wel degelijk een rol hierin.

[Yalopa]

Neen, informatisering heeft hier een rol gespeeld. Dezelfde applicatie on prem was even onveilig (of onveiliger) dan in de cloud, dus cloud heeft er niets mee te maken.

[latka]

Maar dan was het 1 restaurant ipv. alle restaurants. Cloud/centralisatie van diensten zorgt voor een grotere fallout dan 1 server/omgeving per restaurant en papier neemt het digitale risico weg.

[Hans C]

Cloud is toch niet hetzelfde als online opslag op een server bij het restaurant zelf? Jij bedoelt denk ik online opslag.

[bonzz.netninja]

Nee digitaal speelt een rol hierin

[Skit3000]

Waar je deze gegevens ook opslaat of bewaard, als niemand ze vernietigd dan blijven ze potentieel beschikbaar voor kwaadwillenden. Alles gecentraliseerd in de cloud geeft een lek wel een grotere impact dan wanneer een restaurant eenzelfde systeem in huis heeft draaien, maar nog blijft in beide gevallen het gevaar dat de beheerder van de data dit niet (goed) verwijderd nadat ze niet meer nodig zijn.

Een betere optie lijkt mij gasten hun naam en telefoonnummer op een papiertje te laten schrijven en dan in een soort van stembus te laten deponeren. De eigenaar van de horecagelegenheid kan deze 's avonds mee naar huis nemen en twee weken later (als de gegevens niet meer nodig zijn voor bron- en contactonderzoek) in de open haard gooien en het is weg.

[Verwijderd]

Hier in de regio krijg je gewoon een papieren document dat na een periode vernietigd word.

Kan je eenvoudig bijhouden en wegsmijten eens de periode gepasseerd is.

Ja hier kan het oik fout lopen, maar de schaal zal kleiner zijn.

[Skit3000]

Gewoon een lijst neerleggen kan ook inderdaad, maar je hoort al van mensen (gasten, personeel) die daar dan een foto van maken.

[johnbetonschaar]

Ik vraag me inderdaad af wat er nou eigenlijk een groter privacy risico is... Een klunzige database die mogelijk gehackt kan worden, of een papieren lijst die jan en allemaal voor zijn neus krijgt...

Ik heb sinds de invoering van deze regel nu al 2x meegemaakt dat ik aan tafel een lijst voor mijn neus kreeg met zo ongeveer alle namen en 06-nummers van alle gasten van die dag, en de bediening vervolgens vrolijk wegloopt om mijn drankjes alvast te halen, en dat bij elke tafel hetzelfde. Op die manier hoef je helemaal niks te hacken, een foto'tje is voldoende. En dan wordt er vreemd opgekeken dat mensen daar fake gegevens gaan invullen...

Ik sta er echt van te kijken dat iedereen hier zo makkelijk overheen stapt, jarenlang heeft de EU en onze regering een grote mond gehad over GPDR, cookie walls, dat je geen foto's meer mag maken van het afzwemmen van je kind zijn klas, etc. En nu wordt er zonder enig vorm van protest of kanttekening gewoon overal informatie gevraag die gegarandeerd niet GPDR compliant verwerkt wordt en die ook nog eens klakkeloos met zo ongeveer elke andere gast van hetzelfde restaurant wordt gedeeld. Heel apart.

En waarom? Het is mij totaal niet duidelijk dat dit ook maar enig effect of noodzaak heeft, dit soort maatregelen worden letterlijk nooit onderbouwd met statistieken dat het helpt tegen de verspreiding van Corona. Beetje hetzelfde verhaal als de teststraat op Schiphol. Klinkt als een goed idee maar om mysterieuze reden verbiedt de minister om het percentage positieve tests daar openbaar te maken. Dat zou zogenaamd 'niet bijdragen aan het bestrijden van verspreiding van het virus'. Ra ra waarom? Ik gok omdat het percentage zo laag is dat je alleen maar kan concluderen dat je je inspanningen beter ergens anders op kan richten, maarja dan staat de minister voor schut en moet weer aan het werk om iets te verzinnen dat wel werkt...

Symbool politiek om maar daadkracht te tonen is het, en dat mag wel een privacy schending hier en daar kosten...

[Reactie gewijzigd door johnbetonschaar op 25 juli 2024 07:40]

[Skit3000]

Zie ook mijn eerdere opmerking over de in mijn ogen meest privacyvriendelijke manier (een afgesloten bus waar je een briefje met je gegevens in doet). De overheid schrijft volgens mij ook niet voor hóe een horecaondernemer bezoek moet registreren. Omdat privacy niet de core-business van deze ondernemers is, is het wel te verwachten dat ze niet altijd de juiste keuze maken ook al hebben ze de bereidheid.

Met betrekking tot de onderbouwing; er zijn genoeg gevallen geweest in Nederland die de media hebben gehaald waar op één locatie meerdere mensen tegelijk besmet zijn geraakt. Een voorbeeld zijn vleesverwerkingsbedrijven, maar ook op enkele kantoren en ander plekken ging het mis. In die gevallen is er al een beperkte groep mensen die daar komt (de mensen die er werkzaam zijn) en is het nog wel makkelijk om hen allemaal te informeren. In de andere gevallen (horeca, openbaar vervoer, winkels) is lastiger te achterhalen wie er zijn geweest. Dat er in de horeca nu wordt gevraagd om je te registeren moet zeker wel helpen om mensen op de hoogte te brengen van een mogelijke besmetting. Voor de andere gevallen is de privacyvriendelijke CoronaMelder app "onze hoop" (zolang deze niet te vaak een verkeerde melding geeft).

[Reactie gewijzigd door Skit3000 op 25 juli 2024 07:40]

[Groningerkoek]

De overheid schrijft niet voor hoe ze dit moeten registreren, de overheid schrijft echter wel voor hoe er met de verzamelde gegevens dient te worden omgegaan, en jouw persoonlijke gegevens bij een andere klant onder de neus leggen is gewoon strafbaar, maar niemand die hierop controleert of er wat mee doet en dus boeit het die restaurants ook niet.

[Skit3000]

Ik denk dat het restaurants wel boeit maar dat ze het gewoon niet weten. De gemiddelde persoon weet ook niks over voedselveiligheid of industriële hygiene, terwijl dat voor een restauranteigenaar dagelijkse hap (ha-ha) is.

[Verwijderd]

Je hebt gelijk. Maar de drempel om zo'n foto te maken maakt dat het niet frequent genoeg voorkomt dat die foto's consequent genoeg gemaakt worden om voldoende informatie te bemachtigen dat er munt uit kan geslaan worden.

Dat is bij apps en centrale databases wel zo.

Die papieren versie is momenteel dus beter.

Ook al kan je daar ook foto's van maken.

[Stoney3K]

Wat @jj71 dus probeert te zeggen is dat dat 'slecht ontworpen en beheerd' vooral een keuze is van het management die zo snel mogelijk de markt op wil met een product dat half af is.

Alsof je een auto verkoopt zonder remmen, airbags en veiligheidsgordels en aan de klant belooft 'die zetten we er straks nog wel even op'. En het dan gek vinden dat er mensen het niet overleven als ze een aanrijding krijgen.

Dat kun je de engineers die het product hebben ontworpen weinig kwalijk nemen, want die zaten met onrealistische randvoorwaarden.

[Sergelwd]

Meteen 1 gigantische denkfout.

"Alsof je een auto verkoopt"

Een auto is functioneel, terwijl de privacy doorgaans met geen enkel nut verkwanseld word door overheden/bedrijven.

[jj71]

...dat 'slecht ontworpen en beheerd' vooral een keuze is van het management die zo snel mogelijk de markt op wil met een product dat half af is.

Inderdaad.

Het doet een beetje denken aan verhalen van de Victoriaanse tijd (19e eeuw) toen de industrialisatie opkwam, toen er op grote schaal werd geknoeid met etenswaren. Gooi maar kalk door het meel, bijvoorbeeld. Als het er maar uitziet als meel dan kun je het snel verkopen. Dat heeft uiteindelijk aan het begin van de 20e eeuw geleid tot keuringsdiensten en wettelijke eisen aan de kwaliteit van voedsel.

Misschien moeten er ook wettelijke eisen komen (voor zover die er nog niet zijn) aan software-producten.

Voor het voorbeeld wat je zelf noemt, auto's, zijn er net zo allerlei wettelijke veiligheidseisen.

[Reactie gewijzigd door jj71 op 25 juli 2024 07:40]

[sympa]

En bij een auto heb je als koper nog de keuze.
Maar als ik ergens een dienst gebruikt (dokter, restaurant, webshop, chat) heb ik geen inzicht en zeker geen keus in de gebruikte techniek.

[DaFeliX]

"Het ging om data van de afgelopen tien jaar."

in hoeverre is het gerechtvaardigd deze data 10 jaar te bewaren? De grootste waarde zit uiteraard in recente data, maar is het wenselijk dat als ik daar 8 jaar geleden 'ns gereserveerd heb, deze gegevens nog steeds terug te halen zijn?

[D3lth1r]

Dat systeem is van het bedrijf Gastronovi en restaurants kunnen hiermee ook reserveringen, bestellingen en kassatransacties bijhouden.

Altijd fijn om terug te kunnen zien wat je 5 jaar geleden hebt gegeten bij een restaurant

[YangWenli]

Privacy is een afweging. Het is maar net waar je prioriteit ligt, in sommige landen maken ze een bewuste keuze en gaan ze er rücksichtslos in om corona te bestrijden.

Iets wat de Romeinen trouwens al wisten: in een crisis stel je de Senaat buiten werking en neem je een dictator aan om de republiek te redden. Minpuntje is dat die dictator niet met pensioen gaat.

[haam]

Het vreemde is natuurlijk dat de overheid dit vraagt/vereist, maar niet de juiste (veilige) middelen beschikbaar stelt hiervoor.
Over een corona app is al maanden lang gesteggeld en daar zitten geen NAW gegevens bij, hoe dachten ze dat dit geregeld ging worden dan?

[Neo_TGP]

Moet de overheid alle restaurants een pen en papier opsturen dan? Zo moeilijk is het veilig bijhouden van een fysieke lijst niet hoor..

[Sergelwd]

Gewoon gevangenisstraffen zetten op het bewust nemen van risico's met andermans privacy.
Het houd niet op... Niet vanzelf.

[divvid]

nou, dan kunnen we half den haag opsluiten, alleen is er iets met wet pikmeer arrest....
Kortom, je bent en blijft zelf verantwoordelijk, dan maar niet uit eten

[FreshMaker]

Gewoon gevangenisstraffen zetten op het bewust nemen van risico's met andermans privacy.
Het houd niet op... Niet vanzelf.

En dan gaan trouwen, en zelf de fout in gaan

[Sergelwd]

Geen idee hoe je reactie op de mijne slaat, maar trouwen doe je in samenspraak waar je privacy vaak verkwanseld word buiten je eigen toedoen.

[FreshMaker]

Je mist de grap compleet .....

https://www.nu.nl/algemee...nd-op-eigen-bruiloft.html

Boetes voor niet naleven maatregelen
Regels introduceren om afstand te behouden
dan op je eigen bruiloft zo de mist ingaan, wetende dat je in de spotlights staat.

Gewoon gevangenisstraffen zetten op het bewust nemen van risico's

Stukje do as I say, not as I do

[Sergelwd]

Als je het nu nog niet kan opbrengen om afstand te houden ben je echt een aso

[FreshMaker]

There you are, we zitten op dezelfde golflengte

[SuperDre]

Je bedoelt dus dat de beleidsmakers die aangaven dat men een (vrijwillige) lijst moet bijhouden van iedereen die hun pand bezoekt, want DIE zijn degene die niet met de correcte suggesties zijn gekomen van hoe men op zijn minst zoiets moet gaan bijhouden op een manier die AVG-proof is. DIE hebben de mensen niet goed voorbereid en zomaar wat knulligs bedacht. Je kunt niet verwachten van een uitbater als die te horen krijgt van de beleidsmakers om een lijst bij te houden, dat die zich eerst helemaal gaat verdiepen in hoe dat dan zo AVG-proof mogelijk kan, want dat kost tijd (en geld), en de beleidsmakers zeggen dat je dat de dag nadat zij het gezegd hadden moest invoeren..

[Neo_TGP]

Als bedrijf heb je je sowieso aan de AVG te houden, ook voor Corona al. Net zoals je als burger en of bedrijf eigenlijk op de hoogte hoort te zijn van de geldende wetten.

Dus ja, dat kan je van een ondernemer verwachten ja.

[SuperDre]

Zo simpel werkt het dus niet, zeker niet als er de avond ervoor verkondigt wordt dat je meteen de dag erna al moet beginnen met bv die lijsten bijhouden, dan heb je dus geen tijd gehad om goed uit te zoeken wat en hoe je die lijsten moet gaan beheren..
En het is wel heel makkelijk om te zeggen dat een bedrijf zich aan de AVG moet houden als je iemand bent waarbij AVG een onderdeel van je dagelijks werk is (alsin beheer/verwerking van data), of zelfs dus een aparte DPO er voor heeft. Zelfs grote bedrijven met juridische afdelingen hebben moeite met het implementeren en interpreteren van de AVG, laat staan een buurtcafe die van nog toeten of blazen weet van databeheer, want die heeft er nog nooit mee te maken gehad, totdat ineens op een zondagavond gezegd wordt datie vanaf maandag een lijst moet gaan bijhouden van zijn gasten......... Als jij denkt dat je het acceptabel vindt dat zo'n bedrijf dan stel op sprong precies zich perfect aan de AVG kan gaan houden, dan heb je toch wel echt een grote plank voor je kop en heb je een zeer beperkt realiteitsbesef..

[Neo_TGP]

Nee, dat is dus weer het zoeken naar excuses.. de complexiteit van de AVG voor grote organisaties is de bestaande data en de bestaande processen. De AVG is voor nieuwe processen juist helemaal niet zo complex, persoonsgegevens mogen alleen opgeslagen worden als dat een geldige grondslag voor is en je moet al het redelijke doen om die data veilig op te slaan.

Nou ben ik het met je eens dat het allemaal wel erg kort dag was, maar als we de registratie van de bezoekers van je café er even bij pakken en vertalen naar de AVG is het zo complex niet. De grondslag is er (eis vanuit de overheid, je kan nog twisten over de juridische basis daarvan), nu moet het dus beveiligd worden en dat is zo simpel als niet de lijst aan de andere klanten geven. Een prima oplossing is dus 100 papiertjes printen met de juiste invul velden en een dichte brievenbus of doos achter de bar..

Het feit dat de AVG complex is kan je in dit geval geen argument noemen, want los of dat nou daadwerkelijk zo is (want simpel is het zeker niet als je het over grote datasets hebt, maar we hebben het over een café, geen enorme internetonderneming of de belastingdienst) aan de AVG regels moesten ze toch al voldoen, ook voor het hele Corona gedoe.

[SuperDre]

Tja, zoals ik al weer zeg, dat is logisch voor jou, iemand die er mogelijk elke dag mee te maken heeft gehad, of regelmatig en die dus ook regelmatig hier informatie over de AVG leest. Maar voor iemand die daar nooit mee te maken heeft gehad, zoals een cafebaas, is dat helemaal niet zo simpel. Die heeft waarschijnlijk nog nooit van de AVG gehoord, omdat die helemaal geen persoonsgegevens ooit hoefde te bewaren (want een hoop hebben helemaal geen personeel) en daarmee dus nooit te maken hebben gehad met AVG..

De AVG is gewoon een draak van een wetgeving, zelfs de overheid zelf lukt het niet om zich er aan te houden, dus hoe kun je dan van een simpele kroegbaas verwachten dat die wel even weet hoe die er mee overweg moet gaan. En vooral dus zoals ik zeg, als de overheid de avond er voor zegt dat men dan een lijst bij de ingang moet leggen waar mensen hun gegevens op kunnen invoeren (waarbij je als je ook maar wat van de AVG weet, weet dat dat dus echt totaal niet AVG compliant is)..

[SuperDre]

Niet moeilijk? Je begrijpt toch wel dat een lijst die de klant zelf moet invullen compleet anti-AVG is, aangezien bezoeker F dus de gegevens kan zien van bezoeker A-E. Je vraagt dit dan ook aan mensen om te doen die helemaal niet bedacht zijn op iets dergelijks als de AVG.
De dichtsbijkomende oplossing is dus losse papiertjes en die in een afgesloten box bewaren, en die box mag dus ook niet zomaar mee te nemen zijn, en mag in principe niet eens geopend worden tenzij het nodig is.

[Neo_TGP]

Waarom zou je de lijst aan de bezoekers geven? Je kan ook gewoon de gegevens vragen en ze zelf opschrijven zonder die lijst aan je bezoekers te geven..

Voor iedere oplossing zijn problemen te bedenken, als je maar lang zat zoekt naar excuses om dwars te zijn..

[SuperDre]

Dat is een mogelijkheid ja, maar aangezien er bij de presentatie toen gezegd werd, bij binnenkomst een lijst neerleggen waar men hun gegevens op kan invullen, tja, dan zal iemand die daar niet zo goed over nadenkt (en zeker in zijn uppie achter de bar staat) gewoon doen wat er gezegd wordt, ofwel bij de ingang een schrift neerleggen met een pen waar men dan de gegevens op kan schrijven..

Zoals ik in de andere response al zei, is makkelijk om vanaf een positie te reageren waar je niet stel op sprong even iets goeds kunt bedenken als het niet iets is waar je dagelijks mee te maken hebt. Hell, zelfs de Belastingdienst kan niet snel reageren op de coronamaatregelen met hun technische systemen, terwijl 1tje ervan slechts het uitzetten van een controle is, maar 3 maanden later staat die controle nog steeds aan (waardoor wij als softwareleverancier dus de mogelijkheid die zou moeten kunnen wat betreft de coronamaatregelen ook niet toestaan omdat de aangifte anders toch afgekeurd wordt bij het indienen).

[kodak]

De oplossing van het papier lijkt aan de andere kant weer alleen bekeken vanuit de voordelen. Vergeleken met digitale verwerking zal het waarschijnlijk overzichtelijker zijn, maar weer alleen als aan voorwaarden is voldaan. De papieren worden ook niet altijd correct en overzichtelijk gebruikt. Eenmaal uit zicht heft het gemak en de controle zich net zo makkelijk op. Het verwerken van persoonsgegevens is niet voor bedrijven en goedkope inhuur om makkelijk mee om te gaan. En dat laatste lijkt zowel bij de digitale als de papieren oplossing het echte probleem. Het verwerken is vaak niet in goede handen omdat het bijzaak is.

[SuperDre]

Sorry, maar denk jij dat die papieren invullijsten zorgvuldig behandeld worden? Het feit dat ze vaak gewoon al bij de ingang liggen als een boek, waarbij je dus al de informatie kunt zien van je voorgangers, is dus al iets dat totaal niet strookt met de AVG (want die geldt dus niet alleen voor digitaal)..

Maarja, wat wil je als je vandaag te horen krijgt dat je vanaf morgen met een lijst moet gaan werken, wat dan dus gevraagd wordt aan mensen om te doen die geen kaas gegeten hebben van deze stof of de AVG.
Dit is dus weer gewoon het zoveelste voorbeeld van het geklungel van de overheid om stel op sprong maatregelen te nemen (beste voorbeeld is nog die zondag, om 15:00 zeggen dat alle horeca om 18:00 gesloten moet zijn, je moet toch wel echt zo incompetent zijn om in te zien dat dat nergens op slaat, en dat je bedrijven minstens 24-48 uur de tijd moet geven om daar op te kunnen anticiperen).

[kodak]

De oplossing waar ik het over heb is afkomstig van Chaos Computer Club. Dat staat ook in het artikel van Tweakers. Het lijkt me juist niet dat het een echte oplossing is als ze alleen maar kijken naar de zogenaamde voordelen.

[habbekrats]

Ben gisteren in een brasserie geweeest, Bij vertrek even uw gegevens invullen op een blokje a4 bij de balie. Of u even naam adres en telefoonnummer kunt invullen. De juffrouw achter de kasaa maar even meegedeeld dat dit zo niet kan, 1 foto en je scoort een mooi lijstje naw gegevens.

Ik heb voorgesteld om ieder een briefje te laten invullen en deze in een grote ton te laten doen. Daarna nog gezegd dat ze er dan 1 x per week een winnaar uit kunnen trekken.

[Erkens]

Daarom heeft het bedrijf waar ik werk een gratis te gebruiken online systeem gemaakt waarin die registratie wel veiliger is (en makkelijker, want je kan het gewoon met je eigen telefoon doen door het scannen van een QR code of naar een url te gaan).

[habbekrats]

?

[Tubby]

tja, de algemene verwachting is dat je leverancier dat veilig bouwt. (dat is Feature 0 zoals dat dan zo mooi heet )

Dergelijke systemen zijn namelijk wel gewoon veilig te bouwen; ook in de 'cloud'

[Reactie gewijzigd door Tubby op 25 juli 2024 07:40]

[shadowfox]

Het probleem is dat het economische aspect elke keer weer primeert. Quick & Dirty ...

[Bruin Poeper]

Het probleem is dat het economische aspect elke keer weer primeert. Quick & Dirty ...

Ik denk toch echt dat het economische aspect niet in "quick & dirty" zit, maar meer in het aanleggen van een klantenbestand onder dekmantel.

[shadowfox]

Het komt er gewoon op neer dat het zoveel mogelijk moet opbrengen en zo weinig mogelijk mag kosten. Ja, dan ga je veiligheid niet op de eerste plaats zetten, maar van tafel vegen.