Database van corona-app lekt uit tijdens appathon

In een van de zeven corona-apps die dit weekend verder worden ontwikkeld is een datalek aangetroffen. RTL Nieuws wist via de code van de app een database te achterhalen met namen, e-mailadressen en versleutelde wachtwoorden. De database kwam van een gekoppelde app.

Het gaat om de app Covid-19 Alert, die gebruikmaakt van 'de blockchain'. Dat is een van de apps die dit weekend meedoen met de 'appathon' van het ministerie van Volksgezondheid. Het ministerie heeft zeven appontwikkelaars opgeroepen hun concept voor een corona-app te presenteren. De ontwikkelaar achter Covid-19 Alert, Immotef, plaatste een deel van de broncode zaterdagavond online.

RTL Nieuws vond in die broncode een koppeling naar een database van een andere app die Immotef eerder had gemaakt. Volgens RTL Nieuws staan daar ook gegevens van Nederlandse gebruikers in. Het bedrijf heeft het desbetreffende deel van de broncode offline gehaald na de melding van RTL. De site schrijft echter dat de database met zoekwerk nog steeds te vinden is. Volgens journalist Daniël Verlaan is de database inmiddels ook via een fork van de blockchain-app bij anderen terechtgekomen.

Het lek is zowel aangegeven bij het ministerie als bij de Autoriteit Persoonsgegevens. Een woordvoerder van de app zegt tegen RTL dat de data per ongeluk online is gezet. "We hebben de code zo snel mogelijk openbaar gemaakt".

Dit weekend moeten de makers van de zeven apps op het ministerie meer bekendmaken over de werking van hun apps. Experts hebben daarbij grote zorgen. Afgelopen vrijdag bleek al dat sommige experts een aantal uitgekozen apps als negatief hadden beoordeeld. Ook tijdens de appathon zeggen sommige experts bezorgd te zijn over de gang van zaken. Zo is nog niet alle broncode openbaar en lijken veel apps zich niet te houden aan het vereiste principe van dataminimalisatie. Zo werkt de app van Capgemini met een telefoonnummer en gebruikt een andere locatiedata voor contacttracing.

Reacties (357)

[copywizard]

Dit moet allemaal zo enorm gehaast worden ontwikkeld dit kan NOOIT veilig worden gedaan. Ik ben zelf geen ontwikkelaar maar zelfs ik begrijp dat het ontwikkelen van een VEILIGE app gewoon tijd kost en niet in 1 a 2 weken even kan worden uitgepoept en dan gebeuren er dit soort dingen... Deze apps zijn niet aan mij besteed hoe veilig we Nederland er ook mee kunnen maken sorry.

[MadEgg]

Veilige code schrijven is onder tijdsdruk inderdaad een uitdaging. Maar er zijn ook gewoon een lijst met no-go's die je nooit en te nimmer zou mogen toepassen. Als je in dergelijke fundamentele dingen al faalt moet je app / bedrijf sowiesos per direct de deur gewezen worden.

[Opa73]

Is het hier niet zo dat de bedrijven die de tijd nemen om fundamentele dingen goed & veilig te implementeren wegens de gestelde deadline zijn afgevallen?

[COW_Koetje]

Vandaar dat bedrijven als CapGemini en Excenture erbij zitten.
Dit zijn de bedrijven die standaard ongeveer alle europese aanbestedingen winnen en zeer veel contacten en lobby hebben bij de verschillende departementen.
Ik vind het bijna schandalig dat deze weer, ondanks dat ze zo vaak hebben bewezen nog geen project uit te kunnen voeren zonder 300% overschreiding, op een lijst staan.
Het was fijn geweest eens een app(licatie) te zien die door een andere partij gemaakt zou worden, maar het zou me verbazen als niet 1 van deze 2 het weer gaat winnen. Ik heb net een groot stuk van de presentatie gezien en als ze iets kunnen dan is het verkopen. Ook al is het vaak bullshit, zolang de mensen op de departementen maar geloven dat het als waarheid klinkt kopen ze het toch wel.
In een apart interview na de presentatie zei de meneer van Cap dat de veiligheid werd gewaarboorgd doordat ze meerdere platformen gebruiken .... Dat zegt hoogstens iets over de gelaagdheid en het risico/kans dat er iets mee kan gebeuren en daarna zich verspreid. Maar het zegt letterlijk niets over de totale beveiliging, gebruik en beheersbaarheid van de risico's

De verkooppraatjes lijken belangrijker dan de de mensen die echt het kaf van koren kunnen scheiden. De mensen die echt kritische vragen stellen werden afgekapt en min of meer als azijn pissers behandeld. Dus het zal wel weer gaan zoals altijd. De patij die het totaal nooit zou mogen uitvoeren mag het doen omdat ze de beste lobby hebben en het goedkoopste lijken om daarna eindeloos te vertragen en vele malen over budget te gaan.

[jahoorisieweer]

@COW_Koetje
Wat ik schandalig vind dat die bedrijven ook mee doen aan per land een app dus al dan niet in samenwerking met andere partijen voor delen of geheel dan ook nog incasseren uit weer andere EU landen.

Is gewoon een kermis om je kapot te schamen dit geheel.

Virus kent geen grenzen dus waarom niet 1 EU APP, mensen gaan ook over de grens anders moet je weer alles aan koppelingen gaan ontwerpen en uitwerken naar de APP van ander EU land voor die over de grens gaan / moeten vele zelfs dagelijks.

ER is reeds een BASIS in EU en ook een TOOLBOX en ook adviezen en ook avg privacy zaken advies dat alles was er reeds en zet men gewoon opzij om het wiel opnieuw uit te willen vinden, verspilling tijd en geld dus.
Toolbox is met ETSI en Enisa enz samengesteld er werken in EU reeds meer dan 130 specialisten samen en 14 landen enz.

[Reactie gewijzigd door jahoorisieweer op 23 juli 2024 08:26]

[RobbieB]

As deze crisis iets bewijst is het we dat er geen EU is, alleen een Europese handelsunie...

Er zijn teveel nationale belangen die de lidstaten niet opzij willen schuiven. Bij een EU app zal ieder land graag een partij uit zijn land willen die het ontwikkelt. En ook allemaal toegang tot de data. Dan hebben we het nog niet eens gehad over de verschillende talen, geschriften en tijdzones die ondersteunt moeten worden...

[ironx]

En dan valt het nog allemaal mee...
Ik vraag het me echt af: nu is het 'maar' een virus, hoe had dit allemaal gelopen als het een oorlog was?

Ze roepen maar om meer EU, EU dit, EU dat, maar als er stront aan de knikker is is het iedere keer weer iedereen voor zich...

[Zenomyscus]

Hoe lang hebben de verenigde staten erover gedaan om echt samen te komen? Ook daar zijn nog steeds een hoop verschillen tussen staten. Ik denk niet dat het erg is dat landen sommige dingen op een eigen manier aanpakken. Verschillende culturen = verschillende oplossingen voor problemen. Dat is niet erg, maar we kunnen wel een hoop leren om beter samen te werken. Een andere kijk kan lastig zijn, zeker als de verschillen (bijvoorbeeld op het gebied van financien) groot zijn. We komen er wel, het heeft tijd nodig. Waar ik eerst anti-eu was zie ik nu steeds meer de voordelen. Uiteraard zijn er nadelen, niets is perfect.

[RoestVrijStaal]

Eerlijk gezegd hou ik liever van een zwakke Europese Unie. Het liefste gaan we terug naar de Gemeenschap van Kolen en Staal en krijgen Den Haag èn onze gekozen politici het werkelijk weer voor het zeggen in plaats van Brussel en Staatsburg (en indirect Berlijn, Parijs, Madrid en Rome).

Door de Fransozen wordt de Noordzee met boomkorren omgeploegd waardoor alle zeebodemdieren kapot gaan. Omdat de Fransozen jaloers waren op onze moderne, milieuvriendelijke visserij waardoor ze in de media en politiek zo bespelen dat bij pulsvisserij alle vissen worden geëlektrocuteerd. Gevolg: Nederlandse vissers failliet omdat ze geen subsidie voor pulsvisserij meer krijgen noch subsidie om hun kotters weer naar de ouderwetse boomkorvisserij te om te bouwen.

Zeevisserij is net als landbouw een gedeelte van de Public Image van Nederland. En dat wordt even door een vreemde mogendheid de grond in geboord. Het valt me tegen dat er geen extra accijns op Franse producten is gekomen.

[Reactie gewijzigd door RoestVrijStaal op 23 juli 2024 08:26]

[ejabberd]

Voor zover ik weet is pulsvissen steeds verboden geweest maar is het tijdelijk toegestaan voor wetenschappelijk onderzoek (niet enkel in Nederland). Het was van in het begin duidelijk dat dit tijdelijk zou zijn. Wat is dan juist het probleem? De vissers die hier aan meededen wisten dat het tijdelijk zou zijn.

[0xygen500]

Dat lijkt me beetje kul, elke game in de appstore ondersteund toch veel talen? Waarom zou z'n app dat niet kunnen.

[trogdor]

Het is niet de vertaling die de diversieteit van implementaties veroorzaakt, maar alle verschillende interpretaties van zaken als de lokale privacy regels.

[Martao]

De GDPR is Europees....

[trogdor]

GDPR is europees, de manier waarop er mee wordt omgegaan niet.

[ejabberd]

Die mening deel ik niet hoor. De EU heeft in deze crisis heel snel en heel daadkrachtig gehandeld.

Het is natuurlijk wel belangrijk dat je weet waar de bevoegdheden van de verschillende overheden liggen. Voor economie ligt het zwaartepunt bij Europa...voor volksgezondheid zijn de verschillende nationale overheden aan zet. De EU mag daar simpelweg niet fundamenteel ingrijpen.

Als je dus vindt dat de EU net zo krachtdadig en coördinerend moet kunnen optreden op vlak van volksgezondheid als hoe ze dat deed voor de economie, dan moet je minstens een belangrijk deel van die bevoegdheid overhevelen naar de EU.

Het is overigens grappig dat vorige week een bepaalde president met hetzelfde bevoegdheidsprobleem geconfronteerd werd. Eerst kondigde hij aan dat hij als president de absolute macht had de lockdown in deelstaten terug te draaien om de economie in gang te trekken...en dag later ofzo is hij op de woorden moeten terugkomen omdat de gouverneurs meer macht hebben dan hij dacht.

[Flo]

Volgens mij zijn lang niet alle 7 partijen Nederlands. Dus volgens mij roep je maar wat over “partij uit zijn land”.

Dan is het ook nog zo dat we jarenlang graag naar de EU verwijzen voor alles dat mis gaat. En als het goed gaat is het omdat “Nederland er zich hard voor heeft gemaakt” om het Europees te regelen.

Welke handelsunie heeft er strenge privacywetgeving?!
Welke handelsunie praat er over gezamenlijke steun tijdens Corona?!
Niet NAFTA, niet ASEAN. wel de EU.

As we nu eens ophouden met kort door de bocht of populistische one liners hebben we iigv de kans om de EU sterker te maken.

[ejabberd]

Het belangrijkste wapenfeit wordt vaak vergeten: het geld dat de EU sinds maart massaal in de economie pompt. Als dat niet was gebeurd dan wil ik niet weten wat er ondertussen allemaal gebeurd was.

[kolonel klapzak]

Integendeel, dit is juist een kans om de EU eindelijk eens een beetje in te tomen. De apen komen steeds meer uit de mouw: Macron die openlijk en schaamteloos de corona-crisis probeert te misbruiken om grote hoeveelheden geld van de noordelijke landen los te peuteren, en verder elke vorm van onderlinge solidariteit resoluut verwerpt.
Ik denk dat steeds meer mensen zijn gaan inzien dat de eurocraten veel te ver zijn doorgeschoten in hun levensgevaarlijke plannen.

[StephanVierkant]

Eens met @RobbieB. De Europese Unie is net zo sterk als de lidstaten willen dat het is, voor elk onderwerp apart. En in het geval van gezondheidszorg hebben landen (tot nu toe althans) gezegd dat dit een volstrekt nationaal onderwerp is. Uitzondering is bijv. de goedkeuring van medicijnen, dat is eigenlijk een economisch onderwerp: de zogenoemde interne markt.

Dit hele circus bewijst dat lidstaten niet in staat zijn zo'n app te (laten) ontwikkelen. De belangrijkste technische hobbels moeten door Google en Apple worden weggenomen en daarna is een lobby nodig die door lidstaten niet kan worden gewonnen.

Die technische hobbels zijn bluetooth-toegang op achtergrond bij iOS en de locatietoestemming bij Google (https://issuetracker.google.com/issues/37065090#comment16)

[TheekAzzaBreek]

Virus kent geen grenzen dus waarom niet 1 EU APP, mensen gaan ook over de grens anders moet je weer alles aan koppelingen gaan ontwerpen en uitwerken naar de APP van ander EU land voor die over de grens gaan / moeten vele zelfs dagelijks.

Daar kunnen goede redenen voor zijn, want gezondheidszorg is in de EU landen heel verschillend georganiseerd. Het doel van de app is om de GGD te helpen met contact tracing (of eigenlijk: contact tracing weer op gang te helpen). Ik kan me goed voorstellen dat dat andere eisen stelt dan bv je bv in Duitsland zou doen, waar de zorg per deelstaat is georganiseerd.

Ook wordt er binnen de EU zacht gezegd nogal verschillend over zaken als privacy en burgerrechten gedacht. Je kan moeilijk een gemeenschappelijke EU app vragen maar wel eisen dat die volledig aan onze eisen voldoet, EU besluiten zijn uiteraard altijd compromissen.

Ik weet er ook het fijne niet van, maar het is tenminste voorstelbaar dat nationale apps juist wel een goed idee zou zijn, als die apps ten minste kunnen samenwerken.

[Drumar]

Het probleem net eu is dat het altijd ook politiek wordt. De partij die de aanbesteding wint, doet dat niet omdat deze de beste papieren heeft, maar omdat er genoeg Europese lobby plaatsgevonden heeft. Plus dat de hele aanbesteding wel een paar jaar gaat duren etc etc

Nee eens dat dit eigenlijk op grotere schaal dan per land zou moeten; een wereldwijd open source project cross platform uiteraard, zodat de veiligheid gegarandeerd kan worden omdat de hele code online staat

[SuperSiggy]

Je bedoel, het probleem met POLITIEK is dat het altijd POLITIEK wordt EU of geen EU : )

[Drumar]

Heb je een punt in Europees verband met ik dat dit wel zulke rare vormen aanneemt, dat je je flink moet afvragen of het wel zo handig is. Dat zie je bij het verdelen van wat hogere posities: niet de beste kandidaat wint, maar de kandidaat uit land x,y of z omdat die ook tevreden gehouden moeten worden. Alles gaat er in ruil voor iets anders, en dat is niet altijd de beste oplossing

[SuperSiggy]

Probleem is dat een structuur als een land of federatie als systeem niet zo goed schaalt maar laat ik Tweakers niet vermoeien met een college over anarchie : )

[Verwijderd]

Je slaat de spijker op zijn kop.. dit is geen falen van bedrijf X maar het falen van de EU.
Maar de hele reden waarom we steeds aan Cap en Centric vast zitten zijn ook weer de EU regels. Die stellen de regels zo in het voordeel van de grote IT-ers dat landen hoe dan ook blijven vastzitten aan deze verschrikkelijke partijen. Ze mogen niet eens geweigerd worden in een aanbesteding ondanks dat ze het vorige project enorm verknalt hebben.

Moet je je voorstellen dat je maar verplicht in zee moet gaan met zo’n partij terwijl je weet wat het eindresultaat is. Ambtenaar ben je niet, dat wordt je door het systeem.

De hele bende stinkt trouwens altijd ook naar corruptie lobby.

[Sissors]

Ik vind het bijna schandalig dat deze weer, ondanks dat ze zo vaak hebben bewezen nog geen project uit te kunnen voeren zonder 300% overschreiding, op een lijst staan.

Mijn informatie is ook gewoon van nieuwsberichten, en geen insider perspectief ofzo hoor. Maar als je schrijft dat ze ongeveer alle aanbestedingen winnen, zijn die nieuwsberichten bij enorme overschrijdingen bij 10 projecten dan niet 1% van de 1000 projecten die ze doen?

Algemeen begrijp ik de kritiek op de strakke deadline. Tegelijk laten we wel wezen, als je iedereen een halfjaar de tijd geeft on te ontwikkelen, dan de top uitkiest, die krijgen nog een stel extra eisen, dan een beta periode, en tegen de tijd dat hij geheel klaar is en aan alle eisen en audits voldoet, is het toch te laat.

[COW_Koetje]

http://www.rijksbegroting...eerd/2/0/5/kst205312.html

Document uit 2014-2015 waar in je duidelijk kan zien dat helaas niet 1% van de projecten in de ICT hun budgetaire en tijdsgerelateerde doelen niet halen. Als het inderdaad 1% was dan zou het in mijn ogen geen probleem zijn geweest.

Ik kan even niet accuratere informatie vinden maar ik denk dat de huidige cijfers niet veel beter zijn. (niet op feit gebaseerd, maar gevoel!)

[Kastermaster]

Volgens mij geldt dit niet alleen voor deze aanbesteding. Mijn ervaring is dat bij aanbestedingen altijd gegoocheld wordt met prijzen en deadlines om de aanbesteding maar te winnen. Geen wonder dat in de praktijk zo vaak kostenoverschrijdingen optreden..

[Navi]

Of we bouwen nu iets voor de volgende pandemie...en gebruiken covid-19 als betafase...

Tijd zat!

[Reactie gewijzigd door Navi op 23 juli 2024 08:26]

[jahoorisieweer]

@Navi
Nu gewoon 1 BASIS APP met controle en beheer centraal 1 punt in EU onafhankelijke instantie en geen bedrijf dus.
Deze dan onder controle van alle landen.
De Data die nodig is voor een gezondheid beleid als RIVM en GGD kan dan werkelijk als geagregreerde anonieme data uit systeem aangeleverd worden, dat beleid is dan aan de landen zelf zolang daar geen overeen stemming over is.

Dan simpel deze basis APP kan men intakt laten en in varianten inzetten ( wel daar onafhankelijk centraal beheer enz) waar nodig of gewenst in de toekomst.

Zo kan men de verspreiding van bijv, ziektes als die door teken overgedragen worden in beeld brengen en diagnose en behandeling sneller de juist laten zijn.

APP moet veel meer kunnen dan afstand contact momenten en wel of niet waarschuwen.

Dan pas heeft men iets in de hand wat werkelijk zinvol is.
Dus zaken die mensen al hebben op gezondheidsvlak waarden kunnen koppelen fitbit en andere smartwatch metingen enz, mensen hun temp in laten vullen en hoe ze zich per dag voelen.

Dan kan men uiteindelijk voorspellen ( AI en BIGDATA) in plaats van de dagen op test uitslag wachten , krijgt men meer kennis hoe het virus zich bij mensen ontwikkeld, en natuurlijk ook hoe het afbouwt.

Bij weer beter zijn/worden is de data van hoe mensen zich voelden temperatuur verloop enz ook bekend.

Zo een APP vrijwillig met acceptatie graad kan zoveel moois doen voor gezondheid systeem, welke infectie dan ook en vooral onbekende aankomende opgelopen in vakantie of buitenlandreizen kan men zo sneller traceren ook nog eens. ( EN dus mensen waarschuwen en meer vroegtijdig behandelen war mogelijk er zijn namelijk ziektes waar als men snel bij is men veel minder ernstige gevolgen van heeft)

[Het.Draakje]

En dat is precies wat we zouden moeten doen.

Rustig nadenken, willen we het, wanneer willen we het, hoe willen we het. Rustig ontwikkelen, goed de criteria in de gaten houden. En dan zou ik er misschien vertrouwen in hebben.

Als we een ding van de geschiedenis kunnen leren is dat Covid-19 of desnoods Monkey-Flu 30 vanzelf wel eens zijn kop opsteekt. We weten niet wanneer, maar wel dat het gaat komen.

Wij, als techneuten, vragen ons niet af wanneer een harde schijf uit gaat vallen. We weten dat hij het eens niet meer gaat doen en daarom maken we back-ups.

Deze app had op de plank moeten liggen, als wij het überhaupt willen. Dat is regeren. Vooruitzien. En niet als een kip zonder kop op een (te) laat tijdstip maar rond gaan bazuinen: wij willen een app.

[theobril]

"Vandaar dat bedrijven als CapGemini en Excenture erbij zitten." Kan het zijn dat je accenture bedoelt? Excenture bestaat wel trouwens. Ze zijn goed bezig in Ohio als ik hun site mag geloven

[itlee]

Zoals mijn vader zei als groot ondernemer, olifanten doen het met olifanten en niet met Muizen.

Dus het is logisch dat grote clubs de overheid projecten binnen halen en daarbij kleinere. Clubs niet gezien worden.

Het is al tientallen jaren zo dat dat soort tenten geen top werk afleveren, is ook nooit geweest. Ik zit al 25 jr professioneel in de it en ik heb 1 les geleerd dat kleine clubs vaak beter werk leveren als grote en al helemaal met maatwerk.zoals dit.

[Verwijderd]

Ik vind het bijna schandalig dat deze weer, ondanks dat ze zo vaak hebben bewezen nog geen project uit te kunnen voeren zonder 300% overschreiding, op een lijst staan.

Kom aan, dat zijn zeer grote bedrijven waarbij inderdaad wel eens projecten misgaan. En over die projecten lees je dan wel eens. Van de projecten die wel goed gaan hoor je niets. Je bewering is onzinnig en in daag je uit om die te bewijzen. Of te wijzigen in iets wat wat minder overdreven is.

Persoonlijk ben ik bij drie projecten van Cap betrokken geweest en die zijn alle drie tot ieders tevredenheid afgerond. Bij een waren de uiteindelijke kosten 10% hoger omdat tussentijds de wetten veranderd werden.

[jahoorisieweer]

Het is een systeem, opdracht binnen halen met aanbesteding en daarna zorgen dat specs en project wijzigen dan kan men vragen wat men wil hoor. ( OJA en natuurlijk is er nog steeds corruptie lobby vriendjes en co, dat is al tig jaren zo en nooit uit totale systeem gegaan alleen meer geconcentreerd bij een paar)

Daar zijn mensen voor die het mooi kunnen brengen dat en dat kan ook en kijk eens hoe mooi, of hmm dat is niet de beste oplossing wat wij kunnen is veel uitgebreider en beter enz.

Dan nog indien mogelijk een totaal onwerkbaar iets opleveren, maar ja de opdrachtgever heeft zelf zoveel wijzigingen tijdens het project ingediend dat is niet onze schuld en probleem. hihi.

Hoeft men ook geen "garantie afhandeling" te doen en al die fouten bugs eruit halen.

us heel veel geld voor heel veel werk binnen halen zonder werkelijk verantwoording af hoeven leggen voor eind resultaat zo ongeveer dus.

Toen ik ooit begon meer dan 24 jaar terug zoiets in praktijk gezien en hoe dat werkt bij een eigen projectje, daarvan veel geleerd want was supermooi wat eruit kwam kon superveel, maar was dus aan het einde zo traag en omslachtig dat het totaal niet meer gebruikt werd. ( en dan zie je soms als je met mensen die met projecten en vernieuwing bezig zijn al e.a. aankomen als ze praten over moeten en kunnen nog een paar aanpassingen bijv. )

[Reactie gewijzigd door jahoorisieweer op 23 juli 2024 08:26]

[GameNympho]

Zo zie hoeveel klapvee er is in NL maar ik ben het met je eens, het gelobby moet eens een keer stoppen,
Je ziet ze ook vooraan staan bij delegaties in een ander land, waar ze een slaatje uit kunnen slaan.
Hier gaat het er gewoon om, wie is het goedkoopst en wie kan het snelst, niet wie maakt er echt een goede privacy gebonden app.

[MadEgg]

Zou kunnen. De procedure voor deze apps is verre van goed geweest. Maar dan nog. Je zult me nooit betrappen op zelfs maar een proof-of-concept met daarin credentials. Dat zijn gewoon dingen die je als goede developer snoeihard afgeleerd hebt. Want een PoC evolueert soms in een productie-rijp project (al is ook dat eigenlijk niet de bedoeling) en dat gaat ongetwijfeld een keer mis.

[binair]

Inderdaad, wat dit voorval ook aantoont is dat die developer dus een andere app heeft (waarvoor hij de source niet openbaar gemaakt heeft?) waar doodleuk database credentials in staan. Los van het feit dat het misging met die covid app lijkt me dit dus geen betrouwbare developer.

[Xirt]

Extra tijd is geen garantie voor slagen; volgens mij hebben veel bedrijven dat in het verleden al bewezen. Degelijke processen zijn in mijn ogen veel belangrijker: bij versnelde processen mogen daar geen essentiële stappen uit weggehaald worden (maar versnellen kan ook gewoon door de wait time voor acties te minimaliseren / elimineren en dus alle stappen te behouden).

[SuperDre]

Veilige code schrijven is zelfs zonder tijdsdruk een enorme uitdaging en eigenlijk onbegonnen werk. Immers wat vandaag veilig lijkt kan morgen zo lek als een mandje zijn. Naast dat als jij nog zo je best doet het framework of het os ook nog het probleem kunnen zijn. En wat is veilig, hoe ver ga je?

[MadEgg]

Code die achteraf onveilig blijkt te zijn heb ik begrip voor. Bugs ook. Maar bad practices niet. Je gaat ook geen huis bouwen met funderingsbalken van piepschuim, dat is gewoon prutswerk.

[WillySis]

De app waar het om gaat was nu net een app die niet onder tijdsdruk is geschreven. Deze app was zelfs al via de app-stores verkrijgbaar.

[kodak]

Zolang no-go's niet verplicht zijn en als er geen strenge controle op is dan valt er moeilijk uit te sluiten.

[iew]

Tuurlijk noem een "probleem" maar vooral weer een "uitdaging", schijnt nogal mode te zijn ipv het beestje gewoon bij de naam noemen, dit ligt echt niet alleen aan tijdsdruk.
Bijna dagelijks duiken er lekken op van data bases waarbij persoonlijke gegevens lekken, ook bij apps en programma's waar helemaal geen tijdsdruk achter heeft gezeten.

Daarnaast moet ik bij het woordje "blockchain" en overheid gelijk aan die Rian v Rijbroek denken..., gek he ?!
Ik sta er dan ook echt niet van te kijken dat dit gebeurd is, had het ergens wel verwacht.
En dan te bedenken dat velen die al vanaf het begin kritisch waren op de corona apps voor het meeste deel werden weg gemind hier...

[Ryangr0]

Dit dus. Deze situatie kan natuurlijk nooit voorkomen bij een enigszins professioneel bedrijf. Kan het nog steeds moeilijk geloven dat dit echt gebeurd is... Hoe kun je zo'n fout maken? Snappen deze gasten niet dat nu heel Nederland denkt aan "Datalek" als de term "Corona app" geopperd wordt?

RTL valt hier ook wel iets in te verwijten vind ik. Handel het gewoon netjes af met het AP en de betrokken partijen. Dit is groter dan ad revenue en nieuwscycli. Zo werk je cynisisme in de hand.

Terecht misschien, dat dan weer wel.

[Xerxes249]

Ik was zelf als developer redelijk te spreken over Deus, ik had het zelf niet beter gedaan. Staan ook heel nuchter in, willen nu vast beginnen met kijken hoever we komen maar voor grote launch willen ze eignelijk wachten op de bluetooth api's van Apple en Google wat mij een heel goed idee lijkt:
https://www.publiekebeproeving.nl/deus/stem-mee

[Zoijar]

Als ontwikkelaar denk ik dat dat wel zou kunnen, als je er wat top devs op zet. Helaas zijn die vaak niet te vinden bij dit soort bedrijven die apps maken. Het is allemaal niet heel ingewikkeld, de algoritmes bestaan al en zijn bekend, al het andere is wat dingen aan elkaar knopen. Een beetje dev kan in een dag iets basis functioneels bouwen dat random codes genereert en die in een database opslaat.

Volgens mij is er gewoon weer een overdosis incompetentie aan de hand. Block-chain is ook al weer totaal niet nodig -- de algoritmes hoe het wel te doen zijn immers al lang bekend en dat is niet block chain. Over-complicatie en tech-fetish dus al vanaf het begin. Een dev in mijn team die met zoiets aan kwam zou de boodschap krijgen dat we dat dus zo niet gaan doen, kom maar met wat nieuws.

[Reactie gewijzigd door Zoijar op 23 juli 2024 08:26]

[WoutervOorschot]

Google en Apple willen hun API rond half mei publiceren dacht ik, als de twee (bijna) grootste techbedrijven ter wereld een maand willen nemen om iets fatsoenlijk te implementeren denk ik niet dat we het hier sneller even goed of beter kunnen.

Vooral dat laatste, het is vast mogelijk (zie andere hackatons), maar om in 1 week een volledig geteste, waterdichte goed werkende app te maken voor een usecase die nog nooit door iemand anders is gemaakt lijkt me heel onwaarschijnlijk.

[Xirt]

Grote delen van de usecase zijn al wel eerder gemaakt, maar er worden nu wat extra eisen gesteld aan de usecase: het is dus niet zo dat deze compleet nieuw is en het wiel 100% opnieuw uitgevonden moet worden. Ik die reden gebruiken verschillende van de apps al bestaande apps als basis.

[Verwijderd]

Grote delen van de usecase zijn al wel eerder gemaakt, maar er worden nu wat extra eisen gesteld aan de usecase: het is dus niet zo dat deze compleet nieuw is en het wiel 100% opnieuw uitgevonden moet worden. Ik die reden gebruiken verschillende van de apps al bestaande apps als basis.

Klinkt heel leuk, maar dit is juist de gigantische valkuil van hergebruik van code voor zaken waar het niet voor bedoeld is. Kom, we pakken die module die Jantje ooit eens voor project X heeft ontwikkeld, plakken er een paar extra functies aan en klaar is Klara. Recept voor gegarandeerde rotzooi.

[TheekAzzaBreek]

Huh?

Noem eens één project waar niet ruimschoots van bestaande functionaliteit gebruik gemaakt wordt? Je gaat toch niet je eigen databases, secure communicatie of encrypted opslag in elkaar sleutelen? Dan zou ik pas echt bezorgd worden.

Toe, een voorbeeldje maar. Hello world telt niet.

[R4gnax]

Noem eens één project waar niet ruimschoots van bestaande functionaliteit gebruik gemaakt wordt? Je gaat toch niet je eigen databases, secure communicatie of encrypted opslag in elkaar sleutelen? Dan zou ik pas echt bezorgd worden.

Dat soort zaken herbruik je in nieuwe projecten middels eerder gebouwde libraries of packages die goed gecontroleerd en via de juiste kanalen al-dan-niet alleen bedrijfs-intern gepubliceerd zijn.

Dat herbruik je niet door broncode van een project over te sleur-en-pleuren en weg te snoeien wat je niet nodig hebt. Want dat is dus een recept voor problemen.

[Reactie gewijzigd door R4gnax op 23 juli 2024 08:26]

[Xirt]

Daarom hebben jij en vele anderen dit weekend de mogelijkheid om functionaliteit, technologie en code te reviewen. Maak er gebruik van en geef de appmakers opbouwende feedback zodat er uiteindelijk wellicht een app komt en we weer deels normaal de straat op kunnen. En dat is hard nodig naar mijn mening, want met het huidige toenemende gebrek aan discipline zitten we binnen de kortste keren weer tegen een nieuwe wave besmettingen / doden aan te kijken.

[djwice]

Volgs mij gaat het hier om https://dutchblockchainco...lijke-corona-verklaringen

Een open source W3C referentie implementatie van Hyperledger Indy, een oplossing met Self-Sovereign Identity.

[Reactie gewijzigd door djwice op 23 juli 2024 08:26]

[Zoijar]

Ik bedoelde het meer als 2 weken om iets functioneels te bouwen, dat in theorie en fundament werkt en veilig is, om het daar dan vervolgens over eens te zijn en met een wat groter team uit te bouwen naar een volledig getest en gestroomlijnde app in nog een week of 2-3 -- met misschien ondertussen al wat limited beta releases van de basis-app om ervaring op te doen.

Overgiens zit er wel iets verschil als je een wereldwijde API wilt leveren: daar zit je meteen aan vast en is elke wijziging een hel door dependencies van mensen die het al gebruiken. Dus daar moet je veel beter over nadenken dan een losse app waar je gewoon een 1.1 update kan pushen en alles is blackbox geupdate.

[FireStarter]

Ik denk dat ze de komende weken onder druk te weten gaan komen wat ze in ieder geval niet willen

[Laguna]

Je hebt sowieso die API nodig om een fatsoenlijke app te kunnen ontwikkelen, dus prima als je bedrijven alvast laat nadenken en ideeën laat pitchen, maar dan moet je niet van ze verlangen dat ze deze maand nog met een geschikte app op de proppen komen.

Met als kanttekening dat ik niet denk dat een smartphone geschikt is om te gebruiken voor contact-tracing, teveel variabelen die je niet kan afvangen, met als gevolg false positives.

[B_FORCE]

Nu heb ik geen directe ervaring als professionele ontwikkelaar, maar wel ervaring met het (bege)leiden van dergelijke teams.
Dit is vaak een knelpunt van heel veel technici (niet alleen software).
Vaak wordt er veel te moeilijk gedaan en vindt men het wiel weer eens tien keer opnieuw uit.
Keep it simple is vaak toch de betere benadering.

Ik heb op die manier al zoveel projecten zien falen en zelfs bedrijven failliet zien gaan. Soms met een 10 koppig team met een gemiddeld inkomen van 2x modaal en ik weet niet hoeveel speciale papieren en PhD'ers.

[Zoijar]

Klopt. Mee eens. Je hebt hier dan ook juist geen belachelijk groot team en management nodig, maar 2 of 3 goede devs die echt goed weten wat ze doen. Nou heb ik daar sowieso al weinig vertrouwen in als ik namen als CapGemini hoor, waar het vaak belangrijker is om eerst 300 paginas requirements dicht te timmeren en te presenteren naar vier lagen management, in plaats van gewoon pragmatisch een oplossing te bouwen.

[K-aroq]

Je wilt apps als dit niet door heroes laten ontwikkelen.

[SuperDre]

Ah weer iemand die het wel allemaal even beter denkt te weten. Sorry hoor maar er zijn zoveel niveau's, zoveel zaken. Topdevs? Wat is een topdev? Genoeg gezien die op vlak A ingenieus zijn maar op vlak B crap en andersom, ben nog nooit een developer tegengekomen die op alle vlakken perfect is (en zelf ben ik dat als developer ook verre van). Als jij denkt dat je wel alles weet en jezelf als topdev ziet, dan weet ik al wel dat je dat niet bent.
<edit>wat mobile toetsenbord foutjes opgelost

[Reactie gewijzigd door SuperDre op 23 juli 2024 08:26]

[Zoijar]

Lekker zwart-wit weer; dus je moet alles weten op elk vlak om tot de top te behoren, die 1% uitblinkers die echt heel goed weten wat ze doen, zeg maar de Linus en Stroustrup types. En daar zie je totaal geen verschil mee dan, als ze niet alles van alles weten, met die 60% die "ook wel een app kan schrijven want een jaar een cursus gedaan en een artikel over encryptie gelezen"? Ok

[Verwijderd]

Daarbij ook nog eens hippe, onnodige zaken als blockchain erin gooien. Dat is wat we nodig hebben jongens. Problemen omtrent privacy, detectiemethodes e.d. zijn nog lang niet opgelost, maar er lekker een prestige-project van maken

[Pep7777]

Klopt blockchain is overbodig en zelfs verwarrend.
Houd het zo eenvoudig mogelijk dan is het transparant en is de kans op bugs/lekken is het kleinst.

[Verwijderd]

Ik zie in deze ook niet echt een ketting van transacties die immutable moet zijn. Het idee van de gegevens die hierin komen is dat ze eruit moeten gehaald kunnen worden (want privacy en rot op met vereeuwigen waar je mij hebt gezien via Bluetooth/Wifi beacons) en dat er een centrale database met gegevens is, zodat we die data kunnen gebruiken om heat maps en andere statistieken te genereren. He enige wat hieruit zou moeten komen is:

- Lijstje gebieden waar (veel) coronalijers zijn/waren
- Eenmalig signaal naar mensen die naast een geïnfecteerde is geweest

[Pep7777]

Nee belangrijkste zijn: goede random generator voor tracker id's (die niet te koppelen is aan hardware). En een veilige manier om die tracker id's in een database te krijgen (zonder dat daarbij een link naar het orginele toestel te maken is).
Moeilijker is het echt niet

[Verwijderd]

Enkel heb je dan weer het probleem dat je dat ID aan een geïnstalleerde app koppelt en deze meerdere keren gaat lopen jengelen tegen apparaten dichtbij. Met genoeg tijd kun je dan zien waar eigenaren tracker IDs wonen. Niet zo'n probleem in een flatgebouw van 200 man, wel in vrijstaande woningen, want dan tracker_id == blablastraat 123. Vooral in deze geïsoleerde tijden zal je pad vrijwel elke dag hetzelfde zijn. Die van mij is namelijk 99% van de tijd gewoon op dezelfde locatie de afgelopen weken. Het enige wat dus opgeslagen mag worden is GPS coordinate en corona ja/nee. Wat de app zou kunnen doen is de gereisde coordinaten lokaal opslaan en vergelijken met de data op de server.

Device > Server: gps_coords[],infected=true,date=now()
Device < Server: if ( gps_coords[] in infected_coords[] ) { alert(gps_coord_friendly_name) } )

In bovenstaand model stuurt jouw applicatie jouw historie op als lijstje GPS coordinaten. Jij selecteert vervolgens of je corona hebt. Op de server worden al deze coordinaten nu geüpdatet en gemarkeerd als gebieden waar iemand was met corona op datum/tijd x.

De applicatie kan vervolgens periodiek checken (of de server pusht een signaal zodat de app gaat checken) of jouw lokale historie (in het geheugen/opslag van de telefoon) overeenkomt met coordinaten die als geïnfecteerd zijn gemarkeerd. Met een beetje basis call naar een OpenStreetMap/Google/Bing/Apple API call kun je die coordinaten resolven naar een winkel, bedrijf, straat. Wat je wilt. Een berichtje kan vervolgens aankomen als "Op 19 april is er een coronapatient aanwezig geweest in de Albert Heijn te Blablastraat 123, Amsterdam."

Er komt natuurlijk meer programmeerwerk bij kijken om er een mooie app van te draaien, maar heel veel meer hoeft het niet te zijn. Er is totaal geen opslag of uitwisseling van IDs nodig, want dit leidt ALTIJD tot identificatie van een groot deel van de gebruikers wanneer je dit combineert met locatiedata en tijden.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 08:26]

[Pep7777]

Het kan echt nog simpeler

Het hele idee is dat Tracker id's om de paar minuten opnieuw gegenereerd worden.
Mijn telefoon houd zo'n lijst met id's bij. Jouw telefoon ziet er dan (via bleutooth signaal) misschien 1 of 2 van. Ik heb corona, dan upload mijn telefoon een lijst van die nummers (tracker id's) over de tijd dat ik besmettelijk was naar de cloud.

Jouw telefoon checkt afentoe online of de id's die jouw telefoon "gezien" heeft : namelijk een match van tracker id's. Is dier er dan weet jij dat je in de buurt van een besmettelijk iemand bent geweest (en niet dat ik het ben geweest). Komt geen GPS of wat dan ook bij kijken. Wordt alleen bluetooth voor gebruikt (evt. de nieuwe API van google en apple)

Zwakste moment is als IK (niet jij) de data upload. Dan is het mogelijk dat de cloud mijn ip vastlegt en ik als men zou willen terug getraceerd zou worden. En hier is review van niet alleen de app maar ook de cloud te updten.

En een "mooie" UI hoeft niet veel te kunnen, me waarschuwen als ik binnen moet blijven omdat ik besmettelijk kan zijn en een "ik heb corona" knop.

Oh en niet iedereen hoeft mee te doen bij zo'n 60% deelname houd je dan genoeg besmettingen tegen om alles beheersbaar te houden.

[Verwijderd]

Persoonlijk vind ik GPS belangrijk omdat we zo ook een kaart kunnen hebben van gevaarlijke gebieden in de app en openbare databases. Zo doen ze dit in Korea en Taiwan ook (laagste infecties ter wereld) Preventie is echt net zo belangrijk, misschien wel belangrijker dan weten dat je het hebt of mogelijk kunt hebben. Aangezien wij bijna niemand testen, is de wetenschap dat je het "misschien" hebt eigenlijk redelijk nutteloos.

Als ik zie dat er de afgelopen dagen 500 patienten bij de Jumbo waren en 10 bij de AH, dan weet ik wel waar ik heenga.

IPs opslaan is een keuze. Access logs van webservers kun je rotate en een database zal ze niet standaard gaan loggen. Dat ligt compleet bij de bouwer van de app.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 08:26]

[K-aroq]

Nog niet zo lang geleden was de opinie op deze site toch dat blockchain alles was. Als je nog gewoon geld gebruikte was je extreem dom volgens de meesten hier.

[Verwijderd]

Tja, dezelfde lui die dachten dat Bitcoin meer ging worden dan een virtueel beleggingsobject/gokspel met echt geld. Het heeft zijn voordelen hoor, voor bepaalde applicaties.

[Woy]

Maar dit toont wat anders aan dat de code zelf niet veilig is. Dit toont aan dat de organisatie gewoon niet volwassen genoeg is om een dergelijke app te ontwikkelen. Dit soort privacy gevoelige productie data mag gewoon nooit bij een een developer op zijn PC komen, dan kan het ook niet in source control terrecht komen.

Het is gewoon uit den boze dat bij een dergelijke app met medisch gevoelige persoonsgevens productie data zomaar bekeken kan worden door ontwikkelaars.

[binair]

hoe ga jij dan, eens een applicatie in productie is, een probleem oplossen waarbij één of andere edge case in de data de gehele boel doet crashen?
"Sorry, deze bug kan ik niet oplossen want ik kan de root cause niet analyseren. Maar geen probleem, het werkt wel in onze test omgeving met de door ons bepaalde test data."

[Reactie gewijzigd door binair op 23 juli 2024 08:26]

[Woy]

Wat dacht je van geanonimiseerde data. Verder is je sowieso eerst proberen om aan de hand van der beschrijving van het probleem een reproductie scenario proberen op te stellen.

[Martinspire]

Dit inderdaad. Er is niets wat een dummy database niet kan simuleren dat in productie anders loopt. Als dat zo is, dan is je database niet volgens spec

[djwice]

Zo te lezen heb je het beeld dat een ontwikkelaar productie data nodig heeft om goed te kunnen testen.

Je kunt ook een statistische analyse laten maken per kolom in de productie data, incl. diverse patroon eigenschappen en deze samen met de tabel schema's gebruiken om test data te genereren.

Zolang je de set groot genoeg maakt en statistisch gelijk laat zijn aan productie, verkrijg je vaak zelfs een betere testset dan je productie data, omdat door de kolom onafhankelijke analyse van de productie data, je edge cases in je test data hebt die in productie nog niet bekend zijn, maar statistisch wél voor kunnen komen.

Zeker bij een landelijke uitrol is het zeer belangrijk deze aanpak te kiezen en niet de productie data te nemen als 'test set'; de kans is groot dat de huidige productiegegevens minder datadiversiteit bevat dan de doelgroep in de 'to be' situatie aanlevert.

Dit geldt eigenlijk voor elke app die je bouwt die gebruikers input verwerkt.

[Reactie gewijzigd door djwice op 23 juli 2024 08:26]

[TheekAzzaBreek]

Dat hangt er vanaf.

Een aantal van deze apps leunt zwaar op een al bestaand framework, ze worden niet van de grond af opgebouwd. Ik heb gisteren wat in in die sources rondgeneusd, en was verrast met hoe weinig code ze af konden. Dat beperkt het testwerk, als je er vanuit gaat dat het framework al voldoende getest is, ten minste.

[Martinspire]

Volgens mij gaat het momenteel ook niet echt om een werkzame app af te leveren, maar eerder prototypes over hoe we willen dat ze werken en wat er mogelijk is.

Ik neem aan dat er nog wel een traject achteraan komt, maar iedereen gaat alle apps al afschieten voordat ze kijken wat er nou werkelijk is gemaakt en hoe dat in onze regelgeving valt.

[DigitalExorcist]

Je hebt de volgende mogelijkheden:

- Het moet *goed* gedaan worden
- Het moet *snel* gedaan worden
- Het moet *goedkoop* gedaan worden

.. en je mag er twéé uitkiezen. Laat me raden: de overheid koos 'goedkoop' en 'snel'

[R4gnax]

je mag er twéé uitkiezen

... en in de praktijk is het vaak zo dat er daar alsnog maar één daadwerkelijk van krijgt.

[GeoBeo]

Dit moet allemaal zo enorm gehaast worden ontwikkeld dit kan NOOIT veilig worden gedaan. Ik ben zelf geen ontwikkelaar maar zelfs ik begrijp dat het ontwikkelen van een VEILIGE app gewoon tijd kost en niet in 1 a 2 weken even kan worden uitgepoept en dan gebeuren er dit soort dingen... Deze apps zijn niet aan mij besteed hoe veilig we Nederland er ook mee kunnen maken sorry.

Het hele ding kan per definitie niet veilig, omdat het echte doel zoals altijd is: burgers tracken (via latere voorspelbare feature creep) en het zogenaamde doel is verspreiding van een ziekte remmen.

Die twee zijn per definitie niet te verenigen.

En dat alles in het jasje "aanbesteding" dat historisch zo ongeveer een 100 % faalkans heeft om welke app het ook gaat met welk doel dan ook. Inclusief de bekende (corrupte) partijen als Capgemini die experts zijn in overheid uitmelken en niet werkende software bouwen.

Dat terwijl alle andere landen in Europa ook bezig zijn met hun eigen app om de aandacht af te leiden van hun eigen politieke falen.

En dan tot slot de echte reden voor het hele app circus: aandacht afleiden van de politieke problemen: slecht voorbereid op de voorspelbare corona besmetting die we al sinds November/December zagen aankomen, niet genoeg beschermend materiaal ingekocht (de eerste mondkapjes komen nu pas aan, 4 maanden na de eerste outbreaks in China), geen lokale productie van essentiële medische benodigdheden, zorg personeel stres (dat was voor Corona al zo) en de belangrijkste: vaccins die al jaren in de vrieskast liggen en nu pas op mensen getest worden op veiligheid.

De pandemie had gewoon voorkomen kunnen worden. En wat doet men in de politiek? De aandacht afleiden met een app.

En het werkt. En mensen willen volgens de peilingen meer VVD, niet minder. Niet te geloven, maar het werkt.

In mijn droomwereld zou de politiek nu bezig zijn met voorkomen dat zo iets nogmaals gebeurd: klinische tests en/of medicijn ontwikkeling in handen van overheid brengen en productie van beschermende middelen terugbrengen naar Nederland desnoods met subsidie (net als landbouw) uit veiligheidsoverwegingen.

Maar, hey. Dan zou je het probleem bij de wortel aanpakken. Dat doen we hier niet. Gewoon ff een app bouwen en politiek lekker scoren met "leiderschap" (lees: gratis extra zendtijd).

Mark my words: zo'n pandemie gaat er gewoon nogmaals komen. Er is NIETS van geleerd. Of gaan we nu allemaal juichen bij de volgende pandemie, omdat een app ons allemaal gaat redden?

[Reactie gewijzigd door GeoBeo op 23 juli 2024 08:26]

[Damgood1977]

Eens met jouw opmerking, maar wat ik een beetje mis in het hele verhaal van de ontwikkelaars en de minister is het feit dat wij te weinig testen, dus nu alleen een app kunnen gebruiken voor de ongeveer 1.000 bekende corona besmettingen per dag. En als dit de 20% is die zo ziek is dat ze getest worden, dan hebben wij nog 4.000 mensen per dag die nog niet bekend/getest zijn vanwege de milde klachten en dus anderen kunnen besmetten... de app zal dit niet aangeven ;-)

De app is dus handig om sneller contactonderzoek te doen door de GGD, maar omdat de app op vrijwillige basis geïnstalleerd zal worden, de uiteindelijke effectiviteit waarschijnlijk tegen zal vallen. Er moet dan ook wetenschappelijk onderzoek plaatsvinden hoe snel je geïnfecteerd kan worden in een open ruimte en in een gesloten ruimte. Je loopt namelijk een risico dat je mensen informeert terwijl misschien met bv 10 seconden contact geen infectie risico oploopt...

Nu kijken veel mensen die er in geloven naar het buitenland, zoals China of Singapore, maar het grote verschil is dat ze daar mondkapjes gebruiken en veel testen. De verspreiding en het contactonderzoek is dus "makkelijker" tegen te gaan / uit te voeren en dus te volgen.

Het is een interessant initiatief, maar ik ben erg benieuwd wat na een paar maanden de effectiviteit is. Het zal het werk van de GGD waarschijnlijk makelijker maken, maar zo lang er geen vaccin is en te weinig mondkapjes, gaat het aantal besmettingen gewoon door...en is er geen zicht op een volledig beeld van zieke mensen/"genezen patiënten" en blijft het dus dweilen met de kraan open...

[rickiii]

Ik denk dat je het verkeerd ziet. De hoeveelheid aandacht die het nu gekregen heeft van zoveel experts tegelijk heeft voor een mate van transparantie gezorgd die je normaal niet hebt. Als je de livestream had gevolgd had je gezien dat de app ontwikkelaar keihard zijn ondervraagd en hoeveel kritiek er eigenlijk was op een aantal dingen waar de ze niet over hadden nagedacht. Elke app wordt nu onder de microscoop gelegd, wat meer is dan normaal gebeurt bij overheids-software. De app wordt niet volgende week opgeleverd, maar ze hebben door deze sessies nu meer om over na te denken dan ooit.

[eric.1]

Aan de andere kant, hoe gehaast het ook moet - het gaat om de werkwijze, denkwijze en bepaalde principes. Dat verandert niet door tijdsdruk. Een foutje is al snel gemaakt, maar een referentie naar een open database in een broncode die je publiceert (als ik het goed lees zelfs een database van een ander project, gewoon een copy-paste dingetje, dom), dat heeft niets maar dan ook niets met tijdsdruk te maken. De mindset is er gewoon niet.

Dat lijken sommige experts ook te zeggen over deze (en andere) app(s). "Er is zoveel mis met deze app, ik begrijp niet dat dit door de selectie heen is gekomen."

Afschrijven, next. Het is al een gevoelig onderwerp, laten we het dan gewoon goed aanpakken.

[Verwijderd]

Wat zou dat helpen dan? In elke taal zul je een database moet hebben en een connection string. Het zou helpen als developers geen gevoelige data naar repositories pushen.

[svane]

Ik mag hopen dat dit team direct uit de competitie gezet wordt. Dit is wel een grote fout. Zelfs als ze nu 100% nieuwe programmeurs aannemen, is het vertrouwen helaas al te erg geschaad.

Dit vind ik ook wel zorgwekkend:

Rijksoverheid:

In de uitgangspunten staat onder andere dat de app anoniem moet zijn, geen locatiegegevens mag verwerken en dat niet moet kunnen worden vastgesteld wie de gebruiker is.

Covid19-alert.eu:

The Covid-19 Alert! app does not collect or use location data of any kind and doesn’t access the contact list of the user’s phone

Vervolgens in de iOS broncode:

RegisterService.register(deviceId,
lat: coordinate?.latitude,
lon: coordinate?.longitude,
firebaseToken: self.firebaseToken)

en

let requestBody = RegisterRequest(deviceUUID: deviceUUID, lat: lat, lon: lon, firebaseToken: firebaseToken)
let request = Self.postJsonRequest(endpoint: Self.endpoint).jsonBody(requestBody)

Ik hoop dat ik er naast zit, maar als deze app echt je locatiegegevens doorstuurt hoop ik dat dit ook wel strafrechtelijk aangepakt gaat worden.

edit:
De code lijkt (gelukkig) niet gebruikt te worden, en op dit moment alleen lege locatie-data te sturen, sorry

[Reactie gewijzigd door svane op 23 juli 2024 08:26]

[Milt]

Het ziet er uit als dat die variabele nergens wordt geinitialiseerd en dus altijd nil is. Waarschijnlijk zat het er ooit wel in maar is het eruit gehaald. De call naar RegisterService.register() heeft echter die parameter nog wel nodig (nog geen tijd gehad om het er daar uit te halen?) maar er wordt volgens mij nil doorgegeven.

[CH4OS]

Dan is er nog veel code (en dus complexiteit) er nog niet uitgehaald, wat dit echt een niet te vertrouwen ontwikkelaar maakt, naar mijn idee.

[TIGER79]

Hoezo ? Functioneel doet ie wat ie moet doen en in het geval je nil kan meeleveren als parameter dan voldoe je ook netjes aan de eisen richtlijnen van geen GPS locatie. Dat ze misschien niet aan een stukje refactoring zijn gekomen, wat jij impliceert, is meer regel dan uitzondering in de software wereld. Als je daarop je vertrouwen baseert wat betreft ontwikkelaars dan zou ik je ten zeerste aangeraden om geen software met te gebruiken, punt. Immers niet te vertrouwen...

[Reactie gewijzigd door TIGER79 op 23 juli 2024 08:26]

[CH4OS]

Het heeft geen zin code te laten staan als het toch niet gebruikt wordt. En nee, dat is echt niet een gevalletje 'meer regel dan uitzondering', dat is gewoon bad practice.

[jrswgtr]

Veel applicaties bevatten ongebruikte code omdat ze op een framework gebouwd zijn maar niet alle functionaliteit daarvan gebruiken.

Heel normaal en geen bad practice.

[Amped]

Klinkt als het bewandelen van het gemakkelijkste pad. Tevens ook het pad met de meeste valkuilen.

[TIGER79]

Zoals ik het lees wordt die call nog steeds uitgevoerd, dus dat heeft niets met ongebruikte code opruimen te maken.
Ik heb zelf in de source niet gekeken maar neem de analyse van Milt als uitgangspunt. Er is een parameter komen te vervallen en wordt nu een nil waarde meegestuurd, indien de aangeroepen methode hiermee uit de voeten kan, en dat lijkt gesuggereerd te worden, is er nergens sprake van ongebruikte code opruimen. Dan heb je het, zoals ik eerder al aankaartte, over een stukje refactoring desnoods om bijv de aangeroepen methode vrij te maken van die parameter. Van de andere kant, indien het een optionele parameter is dan zou dat zelfs overbodig zijn....

[Milt]

Nou het valt mee. De call naar RegisterService.register() resulteert in een redelijk 1:1 API call naar Firebase. Dus ik snap dat men er hier voor gekozen heeft om nil door te geven want anders moet je dus eerst ook je backend code en API's nog weer aanpassen. Dat men eerst blijkbaar wel dacht dat het acceptabel was om de locatie mee te sturen is overigens wel opmerkelijk.

[svane]

Lijkt inderdaad te kloppen, thanks. Dat scheelt gelukkig weer iets van zorgen.

[Verwijderd]

Voor het lekken van gegevens ja, maar voor het maken van een app kun je moeilijk strafrechtelijk worden aangepakt. Ik snap dat iedereen dat graag zou zien hier, alle grote bedrijven weg en terug naar jagers en verzamelaars, maar even realistisch blijven denken is wel gepast.

Als jij een app publiceert die zegt geen gegevens te verzamelen maar wel lat en lon in de broncode heeft staan staat echt niet opeens de politie voor je deur. Strafrechtelijk is niet de manier om alles maar op te lossen, zeker niet bij een process zo snel als dit.

Dat ze hierdoor geen kans moeten maken, helemaal mee eens, maar even normaal blijven denken en niet in de US mindset komen van iedereen aanklagen voor de kleinste onzin zou ik wel fijn vinden.

[svane]

Deels mee eens. Als een bedrijf belooft om geen locatie te tracken, en het stiekem toch doet, dan vind ik persoonlijk wel dat hier op z'n minst een boete tegenover mag staan. Of dat wettelijk ook zo werkt weet ik niet.

Als jij een app publiceert die zegt geen gegevens te verzamelen maar wel lat en lon in de broncode heeft staan staat echt niet opeens de politie voor je deur. Strafrechtelijk is niet de manier om alles maar op te lossen, zeker niet bij een process zo snel als dit.

Mee eens, in dit geval lijkt het om een stuk oude code te gaan die nog niet verwijderd is, en op dit moment niks doet. Wat mij betreft geen probleem , ik was te voorbarig hierin.

[Verwijderd]

Nee ik ben het er ook mee eens dat er niet niks mee moet worden gedaan hoor, en daarmee vind ik dus ook zeker dat zoiets mag betekenen dat ze geen kandidaat app meer zijn in dit geval.
Maar inderdaad een bedrijf meteen voor de rechter slepen omdat ze een stuk oude code hebben gebruikt vind ik helemaal niet passen in de context van de situatie.

[SuBBaSS]

Nou lekker dan.
Vroeg me van de week al af wie of wat er achter deze app zouden zitten.
Ze schermen zelf met allerhande expertise, maar een blunder als dit is natuurlijk dodelijk voor de betrouwbaarheid.

Daarnaast: de initiatiefnemer kreeg de ruimte bij rtl om zijn product aan te prijzen en deed daarbij wat (imo) opvallende uitspraken:

In het geval van een eventueel datalek is zijn bedrijf overigens niet verzekerd. Dat komt op het bordje van de overheid, zegt hij. "Dit zetten we niet als bedrijf in de markt."

"Ik doe al jaren innovatieprojecten", vertelt De Vries. Een voordeel, zegt hij. "We hebben heel veel korte R&D's (research & development-trajecten, red.) voor EU-subsidies gedaan. Dat is voor grote bedrijven vaak lastig, die kunnen niet zo snel schakelen."

Ik ben tegen inbreuk op je privacy, maar vóór een app, want wat je ermee kunt oplossen is groter dan een veiligheidsprobleem."

https://www.rtlz.nl/busin...ona-apps-vws-immotef-deus

Heb zo'n vermoeden dat het niet zo erg is dat deze partij al zo vroeg door het mandje gevallen is....

[SpiceWorm]

Wat in zijn uitspraken maakt dan dat je geen vertrouwen hebt in deze partij?

De eerste opmerking geldt toch voor al deze corona-app ontwikkelaars? Hij is er eerlijk over dat de overheid de aansprakelijkheid op zich neemt.

Die tweede opmerking: "al jaren" kan natuurlijk net 3 jaar zijn, dat zou niet zo handig zijn.

En die laatste opmerking, wat vind je daar mis mee?

Ik probeer het oprecht te begrijpen (want ik snap de zorgen over privacy en een overheid die bijhoud waar je bent etc) maar ik vind dit geen rare uitspraken voor een eigenaar van een softwareontwikkelingsbedrijf.

[SuBBaSS]

Het is wat interpretatie maar ik lees het zo:

1- Dat komt dan mooi uit, helemaal in dit geval (vrij risicoloos, natuurlijk hadden ze kosten maar daar komt punt 2).
2- Hij weet hoe hij uit de subsidie-ruif kan eten.
3- Ondanks de wat gekunstelde zin (direct uit het artikel) zegt hij min of meer "ben voor privacy maar voor deze app moeten we een uitzondering maken".

En dan natuurlijk: ondanks het gescherm met allerhande experts zo'n blunder maken.
Ja, dan is het wantrouwen wellicht wel iets terecht.

[DJMaze]

Bij RTLZ krijg je geen ruimte, die koop je in

Zo ben ik ook gebeld of ik bij RTLZ mijn woordje wilde doen over beveiliging.
Of ik dan wel een "eigen bijdrage" wilde betalen die lager is dan die van Harrie Mens.

[Zidane007nl]

Echt een prutswerk. Als je een project opzet op basis van een ander project, moet je wel bestanden verwijderen die niet van toepassing zijn!
De broncode staat trouwens weer deels openbaar. Alleen de API niet: https://github.com/covid19-alert/covid19-alert-api.

Ik ben het eens met de kritiek van experts over de aanpak van de overheid. Het is erg gehaast (lees deze verklaring van PrivateTracker.

Ook als ik dit document lees waarin vrijwilligers alle apps hebben doorlopen, vraag ik mij af hoe deze 7 apps door de selectieprocedure zijn gekomen ...

[John]

Waar kan je een lijst van de code repo’s vinden? Staan deze gewoon openbaar op version control sites zoals GitHub?

[wildhagen]

De overheid publiceerd links naar alle sourecode van de deelnemende organisaties: https://www.rijksoverheid.../coronavirus-app/broncode

[NLkaiser]

Ik heb er even snel naar de iOS Apps gekeken.

- Bijna allemaal rusten ze op google firebase voor Storage, Authenticatie en Functions en soms zelfs op Analytics, voor mij is het gebruik van al deze diensten een show stopper.
- Daarnaast zijn volgens mij alle iOS apps vatbaar voor Man-in-the-middle attack's aangezien ik geen ssl pinning ben tegengekomen.

Tot nu toe ben ik het meest te spreken over de inzending van DEUS-BV, al is die helaas wel compleet geforked van DP^3T https://github.com/DP-3T met een beetje tekstuele aanpassingen.
Maar de SDK van DP^3T paast tenminste geen data door naar achterdeurtjes.

EDIT: scratch that, ik zie hier: https://github.com/DP-3T/...ces/DP3TSDK/DP3TSDK.swift
dat de private key van de gebruiker met corona wordt doorgestuurd naar de backend, ik vermoed dat je met de private key individuele gebruikers kan identificeren wat dus betekend dat je geen privacy hebt als corona gebruiker.

if let key = try self.crypto.getSecretKeyForPublishing(onsetDate: onset) {
let model = ExposeeModel(key: key, onset: dateFormatter.string(from: onset), authData: ExposeeAuthData(value: authString))
service.addExposee(model, completion: block)
}

[Reactie gewijzigd door NLkaiser op 23 juli 2024 08:26]

[slowdive]

Heb er even doorheen gekeken. De applicatie van Capgemini gebruikt telefoonnummer, merk en model van de telefoon. Dat lijkt me al.niet meer anoniem: een telefoonnummer is te herleiden tot een persoon...

[Zoijar]

Ik volg trouwens niet zo snel in hoe verre dit "van Capgemini" is: het is toch gewoon bestaande tsjechische open source van een non-profit groep vrijwilligers? Wat ik op zich nou wel weer een goed idee vind. Maar blijft de consultant-rol dan bij "laten we dit gebruiken dat al bestaat"?

[slowdive]

Zo komen we via een achterdeur toch nog tot een pan-Europese app.

[RptR]

Bijzonder. De app inzending van Capgemini linkt naar een repo van een Tsjechische organisatie.
"We are an initiative consisting of people from various Czech IT companies and volunteers called COVID19CZ. We are all unpaid volunteers." van https://github.com/covid19cz/erouska-android

In hoeverre heeft Capgemini hier mee te maken?

[MrOizo2005]

Volgens mij zijn dit ze:

https://www.rijksoverheid.../coronavirus-app/broncode

[dabronsg]

Hoe kan de database per ongeluk online zijn als code in de app daar naar verwijst? Volgens mij is het vanuit de ontwikkelaar gezien eerder per ongeluk gevonden...

[SanderBos]

In 1 van de 3 repositories die ze hadden gedeeld op github stond een postgres backup file in de root directory van het project, wat in ieder geval wel leek op een (kleine) productie database.
Dus het is niet echt een 'verwijzing', het was gewoon een file per ongeluk geupload naar github samen met de wel bedoelde source files.

Maar het ding is dan natuurlijk dat het op github geforked kan worden, en als je zomaar alleen die file wist in een commit dan staat het nog in de historie, en veel nieuwsgierigen (waaronder ik) hebben dan al een kopie getrokken.

Mijn mening: Heel vervelend, goed dat ze het toegeven, de hoeveelheid persoonlijke gegevens lijkt wel mee te vallen, fouten kunnen gebeuren, maar kom dan svp niet met "dit laat de kracht van open source zien" bullsh*t (https://twitter.com/danielverlaan/status/1251785198766895104).

[Reactie gewijzigd door SanderBos op 23 juli 2024 08:26]

[frickY]

Een developer hoort überhaupt niet bij productie data (!) te kunnen. Laat staan een backup kunnen maken naar zijn workstation.
Dit is niet alleen vervelend, dit duidt op amateurisme.

[SpiceWorm]

Een developer hoort überhaupt niet bij productie data (!) te kunnen.

Wat is daar mis mee dan? Lijkt mij heel praktisch, zeker later in het onwikkeltraject, om real world data te gebruiken voor je applicatie. Een systeembeheerder kan vaak ook altijd overal bij...

[Reactie gewijzigd door SpiceWorm op 23 juli 2024 08:26]

[frickY]

Ja, heel praktisch. Vooral voor je regressietests. Maar dat is geen excuus.

Het is zeer gevoelig. Bijvoorbeeld voor datalekken en oneigenlijk gebruik.
Denk aan een developer bij het RDW en bijv nieuws: Naw-gegevens uit RDW-database worden te koop aangeboden op internet

Systeem engineers hebben meer toegang, ook tot productie data. Maar niet tot decryptie-sleutels. Het is ook eenvoudiger te auditten wat een engineer doet (als iets lekt is het erg, als je niet weet hoe nog erger).
Ook kom je als starter net wat moeilijker aan de bak als system engineer met alle privileges, dan als developer.

[Reactie gewijzigd door frickY op 23 juli 2024 08:26]

[SpiceWorm]

Ja ik las je opmerking erg zwart wit.

Persoonsgegevens kunnen prima gefigneerd worden natuurlijk, zeker als het privacy gevoelig is. Maar verder lijkt het mij prima om met real world / productiedata te werken.

[kodak]

Als een ontwikkelaar real world data wil gebruiken omdat het praktisch lijkt dan is mijn vraag voor wie dat dan praktisch is. Want als gebruiker heb je er zelden praktisch voordelen bij dat een ontwikkelaar lekker makkelijk jou en andermans gegevens gaat gebruiken. Eerder de nadelen zoals de risico's op datalekken en verknoeien van productiegegevens.

Een goede ontwikkelaar kan leveren op basis van test- en acceptatie-gegevens en heeft geen productiegegeven van anderen nodig. En dat een ander er wel bij zou kunnen? Dat hoort ook afhankelijk zijn van wat er echt nodig is. Een beheerder vertrouw je bijvoorbeeld meestal meer omdat die ook zorgt voor bestaan van scheiding tussen omgevingen. Maar ook dat kent zijn beperkingen zoals alleen gegevens verwerken die echt nodig zijn of iets niet mogen doen zonder dat een ander daarbij is.

[R4gnax]

Lijkt mij heel praktisch, zeker later in het onwikkeltraject, om real world data te gebruiken voor je applicatie.

Helemaal niet. Het is zelfs heel on-praktisch om real-world data te gebruiken aangezien je daar geen controle op reproduceerbaarheid hebt. Tenzij je met een een snapshot/kopie werkt die bevroren is en evt. aanpasbaar is aan waar je op dat moment mee bezig bent.
In zo'n specifiek geval is het net zo makkelijk, zo niet makkelijker, om een gefingeerd persoon te maken.

Real-world data heb je alleen absoluut nodig als je een probleem gaat debuggen wat specifiek door die data getriggered wordt, en je nog niet weet wat de precieze trigger is. Op dat moment neem je een kleine bisectie van de data, isoleer je in die probleem-data de trigger, repliceer je dat in gefingeerde data, en gooi je de real-world data meteen weer weg. En vanaf dat moment ontwikkel en test je tegenover de gefingeerde data, totdat je helemaal aan het eind van je bugfix-scenario nog één maal een integratie test doet tegen opnieuw de echte data.

[Reactie gewijzigd door R4gnax op 23 juli 2024 08:26]

[hackerhater]

Daar heb je fixtures voor die real life data nabootsen.
Behalve als de productie-bug echt data gerelateerd is, is er geen enkele reden om productie-data voor test en develop doeleinden te gebruiken.

[binair]

hoe ga jij dan, eens een applicatie in productie is, een probleem oplossen waarbij één of andere edge case in de data de gehele boel doet crashen?
"Sorry, deze bug kan ik niet oplossen want ik kan de root cause niet analyseren. Maar geen probleem, het werkt wel in onze test omgeving met de door ons bepaalde test data."

[frickY]

Er zijn absoluut uitzonderlijke gevallen waarbij je een issue niet gereproduceerd krijgt, omdat je testdata onvolledig is.

In die gevallen kan een geanonimiseerd extract van de case in productie gemaakt worden om aan de test data toe te voegen.
Maar dat gebeurt dan niet door een willekeurige developer die een complete sql dump op zijn desktop neerzet, en later naar GitHub upload.

[Reactie gewijzigd door frickY op 23 juli 2024 08:26]

[binair]

ik ken de grootte van dit specifieke bedrijf niet maar in een startup (bijvoorbeeld) heb je natuurlijk niet de resources om een data officer (of wat dan ook) aan te nemen en zal dit door gewoon de eerste de beste developer gebeuren.
Hangt natuurlijk af van hoe privacygevoelig je data is maar als ik het goed begrijp ging het in dit geval over namen, adressen, telefoonnummers etc... Iets waar de meeste (kleine) bedrijven wel achter vragen.

Dus ja, jouw oplossing lijkt me niet echt gerechtvaardigd, laat staan haalbaar in dit geval.

[dez11de]

Een developer hoort überhaupt niet bij productie data (!) te kunnen.

Zo’n uitspraak duidt op een roepende stuurman. Aan wal, in de kroeg, op een kringverjaardag, met een rommelende onderbuik. En tevens de beste bondscoach van Nederland.

[frickY]

Over onderbuik gesproken

Buiten dat developers, zoals ikzelf, geen productie data nodig horen te hebben (voor bijv testen), mag dit ook niet conform de AVG (tenzij gebruikers nadrukkelijk toestemming hebben gegeven).

Denk eens verder dan bijv een developer bij Tweakers die zou kunnen zien hoe laat jij inlogt, aan bijv de developers bij het RDW die bij de kentekendatabase zouden kunnen, of bij Ziggo bij voip gesprekken.

[kodak]

De uitspraak gaat in de praktijk niet altijd op. Dat wil niet zeggen dat de mening onterecht is. Dat je als ontwikkelaar bijvoorbeeld ook directeur, consultant, tester en gebruiker bent wil niet zeggen dat je die rollen zonder te scheiden moet uitvoeren.

Als een developer aan het ontwikkelen is hoort er geen vermening te zijn met productiegegevens. Gaat die persoon hulp bieden aan de klant op een productieomgeving dan zorgt die er voor dat het niet vervuilt met de developer-gegevens.
Kan de developer het werk niet doen als die niet bij de productiegegevens kan? Dat lijkt me onzin. Maar het kost wel moeite, want je moet je dan baseren op bijvoorbeeld goede omschrijvingen en goede test-gegevens.

[BvdW1978]

Juist, en van jou drukken ze ook posters. ISAE, ISO en AVG hebben hier allemaal meningen over en met strikte rollenscheiding krijg je de auditor van je nek. Doe je dat niet, dan moet je andere maatregelen nemen om de integriteit van je proces aantoonbaar te bewaken. Hoe stel jij voor dat je dat gaat doen dan? Of kwam je alleen even langs om te gaan zitte boeren en daarmee een groot onderliggend probleem in IT-land aan te tonen: procesmatige onvolwassenheid?

[SuperDre]

Onzin, jij hebt dan denk ik nooit met een hoop gebruikers gewerkt die werkelijk de raarste zaken kunnen doen, en dan heb je soms geeoon toegang nodig tot de productiedata.
Maar productiedata zetten in je repository is een ander verhaal.

[StephanVierkant]

Het hilarische is nog wel dat juist deze partij een heel verhaal had over de voordelen van niet-muteerbare gegevens dankzij het cryptografische en decentrale karakter van de blockchain. Daardoor kon het veilig.

Nu hebben ze gegevens gelekt en die zijn nauwelijks meer te verwijderen. Dankzij het decentrale karakter van Git.

En dan zo'n sessie als "vlekkeloos" beschouwen is echt gênant.

[arbraxas]

Zal best, maar dit zal gebeuren met een echt gevulde database. Bij mij kwam de app er sowieso al niet in. Dit bevestigt alleen maar waarom. Een foutje en alles ligt op straat.

[vanDee898]

Copy / Paste van een ander project om sneller te kunnen starten gok ik.

[Sandor_Clegane]

Incompetentie. Plus dat alles tegenwoordig "in de cloud" draait en het dus direct ook voor jan en alleman beschikbaar is.

[Reactie gewijzigd door Sandor_Clegane op 23 juli 2024 08:26]

[nasdude]

Beetje flauw om in deze fase al te spreken van een datalek in de Covid Alert app, ze hebben een deel van de broncode online gezet om zo open als mogelijk te zijn, met een ontwikkeltijd van enkele dagen is het niet verrassend dat er dit soort dingen uit komen.

Is een van de doelen van het openbaar maken van de code nu juist om problemen zoals deze te tekkelen voor de go-live?

[Snors]

Ik denk niet dat dit flauw bedoeld is. Er zijn daadwerkelijk persoonsgegevens gelekt. Het gaat dus niet om een "mogelijk" lek wat in de source code is aangetroffen. Maar een daadwerkelijk lek waarbij "bijna tweeduizend volledige namen, e-mailadressen en versleutelde wachtwoorden te vinden van gebruikers van een andere app die aan de corona-app gelinkt is".

Lijkt mij een serieuze zaak die we niet moeten afdoen als "flauw".

[Creesch]

Dat is nog steeds een datalek, dat het komt door het gehaaste proces geeft wellicht ook aan dat dit wellicht niet de beste aanpak is omdat daarmee dus privacy in het geding komt.

[Xirt]

Dat is te kort door de bocht: dat dit bedrijf de processen voor dataprotectie niet op orde heeft / niet toe kan passen onder druk betekent niet dat andere bedrijven dat ook niet kunnen.

[Creesch]

Daarom kies ik ook bewust voor de verwoording met "wellicht". Het is zeker wel iets wat een risico is.

[Unsocial Pixel]

Ehm een complete database met gegevens die je van mensen hebt dmv een andere app die eerder gemaakt is onbeveilligd openstellen een beetje flauw? Nee dit is datalek101 zo een beetje, gewoon niet je prioriteiten en vereisten op orde hebben. Privacy en beveilliging worden de key features van deze app en ik ben bang dat geen van de bedrijven er voldoende kennis of oog voor heeft.

Ach gelukkig is een smartphone bijhebben geen verplichting nog noodzaak, zelfde als de app.
(ja i know de app kan mensen helpen maar helaas heb ik grote twijfels wat erna mee gebeurd, zeker wanneer apple en google het in hun core os gaan implementeren (niet onze nl-covid-app maar waar ze nu de api voor vrijgegeven hebben). En natuurlijk wat er tijdens gebruik heen en weer gaat en bij welke clubjes dit terecht komt ben ik ook heel benieuwd naar, wat dat soort dingen moet ik altijd denken aan de safe harbor (EU data zou in de EU blijven) overeenkomst en wat snowden ons vervolgens liet zien...

[Reactie gewijzigd door Unsocial Pixel op 23 juli 2024 08:26]

[tvanzal]

Dit is toch juist de bedoeling van het open source maken van de software en deze fase van de apps? Zodat er transparantie is.

[Horatius]

De bedoeling is vertrouwen wekken dat het goede apps zijn met een goed doel. Als er 12 uur later al data wordt gevonden en blijkt dat de software eigenlijk slecht getest is wekt dat absoluut geen vertrouwen.

[TheekAzzaBreek]

Het is een fout in de publicatie van de broncode (een bestand wat niets met de app te maken heeft is per ongeluk toegevoegd), dat zegt niets over testen.

Alle apps die hier meedoen zijn nog volop in ontwikkeling, dus testen is per definitie nog niet afgerond.

@Unsocial Pixel : Er is in de haast een bestand aan de gepubliceerde code toegevoegd die bij een andere app hoort, die met hetzelfde framework is gemaakt. Dat zegt dus niets over deze app, maar wel iets over die andere.

Waarom die andere app bestanden met user namen en mailadressen in clear text heeft rondzwerven is de vraag. Het zijn kennelijk echte accounts en geen verzonnen testaccounts, want er is een lek gemeld bij de AP.

Iets anders is waarom die code met zoveel haast is gepubliceerd. De open source eis was een 'harde' voorwaarde, dus die had er zaterdagochtend al horen te staan. Van 3 apps is overigens nog helemaal geen code gepubliceerd.

[Reactie gewijzigd door TheekAzzaBreek op 23 juli 2024 08:26]

[Unsocial Pixel]

Wait ik volg je niet, zou ik verduidelijking mogen want wat ik lees is:
"de broncode heeft niks met de app te maken" en uhmmm de broncode is de app basically

@TheekAzzaBreek
ze spreken over een koppeling, daarmee zeggende dat ze van hetzelfde gebruik maken en gekoppeld zijn.
"... een koppeling naar een database van een andere app"

Ik heb nergens gevonden dat het stuk code niet bij de covid-app hoorde. Daarnaast heb ik het vaker gezien op de werkvloer dat een database voor meerdere producten gebruikt kan worden. Zou je dus kunnen toelichten waar staat dat deze database niet bij de app at all hoorde? Want koppeling, dat betekend gewoon dat het van elkaar gebruik maakt in mijn ogen, anders zou je nooit een koppeling maken. Dan heb je gewoon een random file bijstaan die niet aangesproken word in de app zelf.

Daarnaast zou ik het wel gigantisch stom vinden als een bedrijf zn producten niet in aparte repos heeft staan en al helemaal als een bedrijf als een blinde vink een copy pasta doet zonder ook maar enige goede deepdive in wat ze kopiëren.

[Reactie gewijzigd door Unsocial Pixel op 23 juli 2024 08:26]

[TheekAzzaBreek]

Uit het RTL artikel:

In de broncode van Covid19 Alert stond een database van een andere app die door dezelfde ontwikkelaar, Immotef, is gebouwd.

Als je even doorleest zie je dat de 'link' tussen de twee apps een blockchain is. Het lijkt dus niet te gaan om twee apps die op de een of andere samenwerken, maar van gemeenschappelijke infra en waarschijnlijk hetzelfde framework gebruik maken. Geen idee of die gedeelde blockchain ook zo bedoeld is voor een live situatie, of alleen voor prototyping is gebruikt.

In hun pitch stellen ze dat er geen persoonsgegevens in de cloud worden opgeslagen, uitsluitend (encrypted) op de telefoon. De blockchain zou gebruikt worden om de app zelf te valideren, om te voorkomen dat die door onbevoegden wordt aangepast.

[Horatius]

Kennelijk was de ontwikkelaar positief dat het een degelijke app/begin was. Ze zeggen dat de fout door haast is gemaakt, als er dit soort fouten door haast worden gemaakt zijn er duidelijk kwaliteitseisen ergens vermist geraakt (als die er waren).

[tvanzal]

Hier heb je gelijk in maar doordat de software opensource is kan er tenminste makkelijker ontdekt worden of er een lek inzit.

[Horatius]

Als het de broncode dus niet openbaar zou zijn gemaakt zou deze app gewoon zo op de markt zijn gekomen, dat is schandalig. Je kan het van beide kanten bekijken.

iig deze app komt er bij mij niet meer in want deze ontwikkelaar heeft duidelijk laten zien dat het (alle) kwaliteit eisen aan de kant wilt schuiven als de tijd dringt

[Creesch]

Transparantie qua code is goed, dat daarmee gelijk privacy gevoelige data komt bovendrijven is niet goed. Dat geeft aan dat er in het proces iets mis is gegaan waardoor dit mogelijk is.

Het doel van open code is meer van belang om mogelijke privacy issues vast te kunnen stellen op het moment dat de app in gebruik komt. Dit is dan ook echt een overtreffende trap.

[Snors]

De bedoeling van opensource lijkt mij niet dat er "bijna tweeduizend volledige namen, e-mailadressen en versleutelde wachtwoorden" worden gelekt maar juist het voorkomen van dergelijke lekken..

[Verwijderd]

De broncode van de software ... niet de data van gebruikers.

[E-Flex]

Goed, daar is deze sessie ook voor toch?

[Horatius]

Deze sessie is voor het testen van mogelijke apps die het worden. Dit bedrijf laat zien dat ze eigenlijk niet genoeg tijd hadden om de app goed te maken en te testen, daardoor leveren ze ongeteste software aan. Als je niks proper kan leveren, lever dan niks.

Ze hoopten met deze software erdoor heen te komen, geld te verdienen, terwijl ze wisten dat de kans groot was dat deze lek was.

[MadEgg]

Ongetest? Dit is wrong on so many levels. Gebruikersgegevens of credentials hebben nóóit een plaats in broncode. Dus het is slecht dat ze het "vergeten" zijn maar het is nog slechter dat het er in de eerste plaats in zat. Van een andere app nog wel. Dit roept ook ernstige vragen op over de kwaliteit van die "gekoppelde app".

[Reactie gewijzigd door MadEgg op 23 juli 2024 08:26]

[Xerxes249]

Zat niet in de broncode, er was per ongeluk een postgress database dump file meegecommit.

[livePulse]

Dus een link in de broncode... en dat noem jij "niet in de broncode"?

[Xerxes249]

Nee, wel in de repo, niet in de broncode.

Er stond een losse file die niet bij de source van de app hoort. De persoon die het gedaan had bevestigde op de livestream wat we al dachten, in de 'haast' om te opensourcen (requirement van dag 1 van de appathon) had hij vanuit zijn local repo gepushed naar github en daar per ongeluk deze files (3x database dump) bij in laten staan.

[R4gnax]

in de 'haast' om te opensourcen (requirement van dag 1 van de appathon) had hij vanuit zijn local repo gepushed naar github en daar per ongeluk deze files (3x database dump) bij in laten staan.

Waarbij de volgende vraag naar bovenkomt: developer die met productie-omgeving data bezig is?
En dan niet met maar één test set om één specifiek probleem wat echt niet anders opgelost zou kunnen worden, te debuggen - maar gewoon drie dumps. Wat dus aangeeft dat het gewoon de structurele gang van zaken bij dat bedrijf is.

Walgelijk.

[Xerxes249]

Haha knappe jongen als je een bedrijf vindt waar geen enkele developer bij de productiedata kan. Ik ga er niet vanuit dat bij hun elke developer zomaar overal bij kan dat zou zorgelijk zijn.

[R4gnax]

Haha knappe jongen als je een bedrijf vindt waar geen enkele developer bij de productiedata kan. Ik ga er niet vanuit dat bij hun elke developer zomaar overal bij kan dat zou zorgelijk zijn.

Het hoeft niet zo te zijn dat geen enkele developer er absoluut niet bij kan.
Maar er moeten controles en procedures zijn om dit te limiteren.

En dat is zeer duidelijk hier niet het geval geweest.

[Xerxes249]

Dat weet jij helemaal niet, dat er controles en procedures zijn betekend niet dat het nooit fout gaat. Heel makkelijk om aan de kant te staan en te gaan gillen.

Ik vind hun idee poep daar niet van, maar jouw geklets slaat ook nergens op.

[R4gnax]

Dat weet jij helemaal niet, dat er controles en procedures zijn betekend niet dat het nooit fout gaat. Heel makkelijk om aan de kant te staan en te gaan gillen.

1 database dump hebben staan omdat je een bug aan het analyseren bent, zou nog kunnen.
3 dumps tegelijk lokaal hebben staan is op z'n minst opmerkelijk. Zeer uitzonderlijk als je die allemaal nodig hebt voor een bug waar je op dat moment mee bezig was en absoluut productie-data bij nodig had.

Maar alle drie samen met de broncode van de originele app over kopiëren zonder het in de gaten te hebben? Dat is gewoon nalatig.

Ik vind hun idee poep daar niet van, maar jouw geklets slaat ook nergens op.

Door op de man te gaan spelen versterk je je eigen argument niet hoor.
Maar roep-toeter lekker, als je daar blij van wordt.

[Xerxes249]

its ok 😘

[livePulse]

Duidelijk! Bedankt voor het ophelederen!

[CEx]

Code wordt niet goed door het te testen en dan aan te passen, code wordt goed als het goed ontworpen wordt.

[Horatius]

Zekers maar goed ontworpen Software wordt nog steeds getest. Immers zijn mensen menselijk en maken ze fouten, ook wordt software in de praktijk nooit perfect ontworpen.

[dez11de]

Nee, deze ronde is niet om de apps te testen. Deze ronde is om de organisatie de app te presenteren en voor het publiek om vragen te stellen.

[arbraxas]

Gelukkig is het antwoord op de belangrijkste vraag gegeven zonder hem ooit te stellen.

[TwiekertBOB]

Dat laatste zullen ze vast niet geweten hebben, natuurlijk.

Kijk, op zich is het niet gek dat je nu nog gebruik maakt van snelle fixes om te laten zien dat je app kan gaan doen wat het moet gaan doen. De beveiliging wordt dan goedgezet in een iteratie als is gekozen voor jouw app.

Echter lijkt het erop dat hier een lek is gevonden van een andere app, die al live is, met behulp van de sourcecode van deze nieuwe app. Dat is natuurlijk zeer slordig en overgeeflijk.

Het zegt inderdaad wel iets over het bedrijf dat het een dergelijke fout maakt in de haast.

[Horatius]

Dat laatste zullen ze vast niet geweten hebben, natuurlijk.

De ontwikelaars weten iets van de betrouwbaarheid van de code en hoe groot de kans is dat ze dingen over het hoofd hebben gezien, althans dat zouden ze moeten weten.

Volgensmij was deze sessie niet om apps te bekijken die half af zijn.

[TwiekertBOB]

Dus het is aannemelijk dat ze het wel geweten hebben en als gevolg van die conclusie hebben ze willens en wetens een app met lek uitgegeven, met alle gevolgen van dien?


Het klinkt toch veel aannemelijker dat ze in de haast wat stappen in het proces hebben overgeslagen met als resultaat een lek.

Het toont dus aan dat je nooit zaken te snel moet live brengen. Er is een proces dat je moet volgen, ongeacht de druk die op je wordt uitgeoefend.

Anders krijg je zoiets als dit:
https://www.youtube.com/watch?v=5p8wTOr8AbU

[Snors]

"We hebben de code zo snel mogelijk openbaar gemaakt"

Iets met haastige spoed is zelden goed.. en dat geldt ook in dit geval. Het moet allemaal zo gehaast en snel met als gevolg dat dit soort fouten worden gemaakt. Nou heb ik al mijn sterke twijfels bij het hele selectieproces, met name doordat de gelekte gegevens uit een andere (gelinkte!?!?!) app afkomstig blijken te zijn?

Het is een goede zaak dat opensource een van de requirements is, al voldoen bij lange na niet alle apps hieraan (zie ook: https://zijndecovidappsalopensource.nl). De Nederlandse overheid heeft al niet de beste track-record als het op ICT projecten aankomt, en gezien de partijen die geselecteerd zijn vrees ik een nieuw fiasco.

[Favrile]

Update:https://www.rijksoverheid.nl/onderwerpen/coronavirus-app/broncode

[Snors]

Een deel van de broncode van de Covid-19 Alert (Zoals besproken in dit artikel) is al offline gehaald. Tot zover het volgen van de richtlijnen zoals voorgeschreven door de Rijksoverheid..

Ik ben vooral benieuwd of dit meegenomen wordt in de selectie van de apps. Op dit moment zijn er nieuwe presentaties bezig die live te volgen zijn (https://www.nu.nl/tech/60...ps-dit-moet-je-weten.html).

[Reactie gewijzigd door Snors op 23 juli 2024 08:26]

[Favrile]

''Een deel van de broncode van de Covid-19 Alert (Zoals besproken in dit artikel) is al offline gehaald". Ehm, ja, uiteraard?
Deze app is op dit moment al voorbij gekomen op de livestream.
Van 16.00 tot 17.30 uur "Presentatie en demo eindoplossing door de teams met nabeschouwing".

[Frubelaar]

Nou heb ik al mijn sterke twijfels bij het hele selectieproces, met name doordat de gelekte gegevens uit een andere (gelinkte!?!?!) app afkomstig blijken te zijn?

Voor de selectie was niet veel tijd. Tijdsdruk is ook voor die stap funest.
Dan krijg je al snel redenaties in de stijl van, dat is een groot bedrijf dus die weten wat ze doen. Dat kleine bedrijfje ken ik niet dus zal wel slecht zijn. Of te hoog risico dat het kleine bedrijfje volgende maand failliet is.

En de belangrijkste selectie... lobby.
Het is niet altijd snel (want het moest snel) te zien wat een app kan. Ja er documentatie, maar het bedrijf met de lobbyist heeft al flink zitten brainwashen. "Wij gebruiken abc, en iedere app die dat niet heeft..."
Dat werkt zo, zelfs zonder smeergeld. Als het niet zou werken bestonden lobbyisten niet