Corona tracking app idee

[sko]

Commentaar graag, wat is jullie idee wb. privacy?
Een app die alleen lokaal bluetooth id’s opslaat die in de buurt waren. Mocht iemand doorgeven dat hij/zij symptomen heeft dan wordt die bluetooth id centraal opgeslagen in een lijst, deze lijst wordt door de app 1x/ dag geraadpleegd en gecheckt tegen lokaal opgeslagen id’s

Volgens mij kun je dan geen privacy issues krijgen als de bluetooth id gehashed wordt opgeslagen, de hash is niet terug te leiden naar een specifieke telefoon maar de app kan wel zijn id’s vergelijken door dezelfde hash toe te passen op zijn opgeslagen id’s.

Er wordt dus ook niks getracked op centraal niveau, alleen de lokale app weet met wie het in contact is geweest en voor hoe lang, de app zelf kan zo’n id ook niet koppelen aan personen. Er wordt alleen inzichtelijk hoeveel id’s hebben gemeld dat ze klachten hebben.

Bij de melding in de app dat de gebruiker symptomen heeft of coronapositief is kan natuurlijk wel op vrijwillige basis persoonsgegevens worden opgegeven zodat er wel inzicht is waar er een brandhaard is.

[CyberMania]

Hoe gaat de app om met false-positives? Mensen die voor de grap aangeven dat ze Corona hebben (gehad).

[sko]

Er kan er bij een melding een code meegegeven worden van een dokter/ziekenhuis. Consult-id/opname id etc, bij melding dat je positief was/symptomen hebt mag wel iets van privacy ingeleverd worden. Dat is toch al bekend.

[ Voor 5% gewijzigd door sko op 09-04-2020 00:58 ]

[GlowMouse]

Waarom zou je het id niet kunnen koppelen aan een persoon? Je kunt toch gewoon zelf bijhouden wanneer je welke id's tegenkomt, zodat je kunt bijhouden wie er ziek zijn? Een hash kan dat niet voorkomen.

Los van dat het technisch niet werkt vanwege LE privacy (bluetooth mac address randomization).

[sko]

Is er vanuit de app niet een permanente id uit te zenden via bluetooth? Zodat alleen telefoons die die app hebben geïnstalleerd elkaar zien. Random mac’s van telefoons die het niet geïnstalleerd hebben is toch niet nuttig.

[sko]

Als je het 1x per dag synct en de app zegt dat je vandaag te dicht bij een persoon bent geweest die gemeld heeft positief te zijn, zonder vermelding van tijdstip, is het moeilijk terug te leiden tot 1 persoon normaal.

[Verwijderd]

Ik heb een ander voorstel. Maak een APP die heel simpel is en alle data alleen lokaal (op de telefoon zelf) opslaat.

1. De APP genereert een sleutel (encryptie-code), die voor niemand bekend is, zelfs de gebruiker van de APP niet.
2. Via de APP geef je toestemming om JOUW TEL NR naar andere APP-gebruikers te sturen, via BlueTooth.
3. De APP verzamelt de TEL NR's van andere APP-gebruikers die binnen een bepaalde straal via BlueTooth gevonden worden.
4. De verzamelde TEL NR's worden versleuteld opgeslagen (niemand kan ze lezen).
5. Officiële COVID19-instanties krijgen een AUTORISATIE APP.
6 Alleen de AUTORISATIE-APP maakt het mogelijk om een WAARSCHUWING via de gebruikers-APP te versturen.
7. De verblijftijd van de verzamelde data is 4 of 5 weken.

[GlowMouse]

Verwijderd schreef op donderdag 9 april 2020 @ 13:06:
1. De APP genereert een sleutel (encryptie-code), die voor niemand bekend is, zelfs de gebruiker van de APP niet.

Kan niet.

2. Via de APP geef je toestemming om JOUW TEL NR naar andere APP-gebruikers te sturen, via BlueTooth.

Nee, dankjewel.

4. De verzamelde TEL NR's worden versleuteld opgeslagen (niemand kan ze lezen).

Dan kan de APP ze ook niet meer LEZEN.

[Marzman]

Een beetje dubbel. Ik woon zelf in Belgie en er is in een maand een hoop veranderd
Belgie in Coronatijd:
- een niet democratisch gekozen regering heeft mandaat en voert veranderingen uit
- de politie beboet mensen die op bankjes zitten (ook ze alleen zitten), want je mag alleen fietsen of wandelen. Dat is pas uitgebreidt met skateboarden en steppen (hiervoor kreeg je hiervoor een boete en als je kinderen onder de vijf jaar hebt mag je nu weer wel met de auto)
- Je mag nergens naartoe met de auto tenzij het voor werk of levensmiddelen of medicijnen is.
- Drones met luidspreker worden ingezet die mensen aanmanen afstand te houden
- Drones met warmtecamera's worden ingezet om te kijken of mensen niet in hun tweede verblijf zitten wat niet mag.

En nu komt er dus een app die ons 24/7 gaat controleren. Ja voor Corona, maar de ANPR camera's waren in eerste instantie ook voor internationale boevenbendes op te sporen. Nu worden ze gebruikt voor Jan Modaal die onderweg is naar zijn tweede verblijf. Ik ben benieuwd wat er met die app gebeurd na Corona (als er zo'n app komt). Een maand geleden had ik het allemaal niet mogelijk geacht.

Er zijn ook wat practische bezwaren op zo'n app. Hoe weet je dat de eigenaar van de telefoon de telefoon op zak had? Hoe ga je dat doen met ilegalen zonder papieren? En wat als je geen smartphone hebt of de accu leeg is?

[azerty]

@sko Je idee is gelijkaardig aan dit: https://ministryofprivacy...t-een-van-de-corona-apps/

[MrMonkE]

CyberMania schreef op donderdag 9 april 2020 @ 00:51:
Hoe gaat de app om met false-positives? Mensen die voor de grap aangeven dat ze Corona hebben (gehad).

Of al die hypochonders.
Heb in mijn omgeving al 3 die 'het gehad hebben'.

@sko Mijn BT staat alleen aan als ik in de auto zit.

haha er is een user die TS heet..sorry.. @ aangepast naar at

[ Voor 19% gewijzigd door MrMonkE op 09-04-2020 15:58 . Reden: @ ]

[sypie]

MrMonkE schreef op donderdag 9 april 2020 @ 15:29:
haha er is een user die TS heet..sorry.. @ aangepast naar at

Als je een apenstaartje intikt krijg je automatisch de naam van TS als eerste suggestie, die kun je dus zo aantikken/klikken.

[Mavamaarten]

Het enige wat ik me bij dit soort apps bedenk is ... waarom?
Dan heb je een app die zegt "proficiat u hebt weinig of veel risico"... dat is het dan. Wat ga je met die informatie doen dan? Meer of minder buiten komen? Als het goed is kom je gewoon niet buiten, enkel voor het broodnodige. Dus in principe doet die app niks nuttigs.

Maar in de plaats daarvoor heb je een hoop super privacy gevoelige info prijsgegeven (je precieze locatiegegevens en met wie je in contact bent geweest).

Of je het nu (privacy)"veilig" bedenkt of niet, de uiteindelijke gain die je krijgt is praktisch onbestaande.

[Verwijderd]

GlowMouse schreef op donderdag 9 april 2020 @ 15:14:

Kan niet.

Dus wel !

GlowMouse schreef:
Nee, dankjewel.

Uhh ?

GlowMouse schreef:


Dan kan de APP ze ook niet meer LEZEN.

Dus wel.
Volgens mij heb je er niet veel van begrepen. Afijn, laat maar.

[pacificocean]

Hoe wordt voorkomen dat de app Bluetooth contact maakt met de telefoon van mijn onder of bovenbuurman waar ik voor de rest geen contact mee heb?

[Wintervacht]

Verwijderd schreef op donderdag 9 april 2020 @ 16:58:
[...]


Dus wel !

[...]

Uhh ?


[...]


Dus wel.
Volgens mij heb je er niet veel van begrepen. Afijn, laat maar.

Goeie onderbouwing ook.

Anyway, ik zie nogal wat haken en ogen aan het plan.
Afgezien van het feit dat niemand er op zit te wachten en je basically vaarwel aan je privacy kan bieden, mijn bluetooth staat altijd uit, alleen aan in uitzonderlijke gevallen dat ik een telefoontje verwacht of moet plegen in de auto, hoe ga je mij tracken dan?

Het lijkt me beter om de besmettingskans/risocoindicators globaler te houden en te tracken op locatie.
Als er iemand die positief getest is en ook die app gebruikt toevallig in de super is geweest waar ik normaal gesproken kom (ook te achterhale met locatietracking), zou het wel fijn zijn daar een waarschuwing voor te krijgen. Je hoeft niet te weten met wie je in contact bent geweest die het heeft, alleen dat je mogelijk in contact bent geweest.
Dat hele bluetooth tracking staat me helemaaaaal niet aan.

[kodak]

Verwijderd schreef op donderdag 9 april 2020 @ 13:06:
1. De APP genereert een sleutel (encryptie-code), die voor niemand bekend is, zelfs de gebruiker van de APP niet.

Een client zoals een mobiel of tablet is in principe een onvertrouwd apparaat. Daarbij is het zeer aannemelijk dat de persoon die er fysiek toegang toe heeft (zoals de gebruiker) er ook volledige controle over kan hebben of dat de software/firmware/OS meer rechten kan geven dan gewenst aan die gebruiker of andere apps. Daar heeft een app geen hogere controle over. Het is daarom geen realistische eis dat er sleutels of andere gegevens zijn die alleen toegankelijk zijn voor die apps.

2. Via de APP geef je toestemming om JOUW TEL NR naar andere APP-gebruikers te sturen, via BlueTooth.

Een telefoonnummer is een persoonsgegeven en het uitgangspunt is dat je persoonsgegevens niet naar willekeurige anderen laat delen. Dus ook niet communiceren en ook niet op een apparaat van een onbekende laten verwerken. Want wie geeft jou de garantie dat die ander echt niet bij die gegevens kan en er zorgvuldig mee zal om gaan? Niemand.

3. De APP verzamelt de TEL NR's van andere APP-gebruikers die binnen een bepaalde straal via BlueTooth gevonden worden.

De wet stelt strenge eisen aan het mogen verwerken van persoonsgegevens. Apps op apparaten van zzp'ers of bedrijven mogen wettelijk niet zomaar van willekeurige personen persoonsgegevens gaan verzamelen en verwerken.

4. De verzamelde TEL NR's worden versleuteld opgeslagen (niemand kan ze lezen).
7. De verblijftijd van de verzamelde data is 4 of 5 weken.

Zie het antwoord bij je eerste stap.

[Verwijderd]

kodak schreef op donderdag 9 april 2020 @ 17:46:
Een client zoals een mobiel of tablet is in principe een onvertrouwd apparaat. Daarbij is het zeer aannemelijk dat de persoon die er fysiek toegang toe heeft (zoals de gebruiker) er ook volledige controle over kan hebben of dat de software/firmware/OS meer rechten kan geven dan gewenst aan die gebruiker of andere apps. Daar heeft een app geen hogere controle over. Het is daarom geen realistische eis dat er sleutels of andere gegevens zijn die alleen toegankelijk zijn voor die apps.

In OOP worden Objecten gegenereerd. Tijdens het initialisatie-proces kan je de APP de Sleutel laten genereren. Niemand kan daarbij komen; en al helemaal niet lezen.

Een telefoonnummer is een persoonsgegeven en het uitgangspunt is dat je persoonsgegevens niet naar willekeurige anderen laat delen. Dus ook niet communiceren en ook niet op een apparaat van een onbekende laten verwerken. Want wie geeft jou de garantie dat die ander echt niet bij die gegevens kan en er zorgvuldig mee zal om gaan? Niemand.

Het uitwisselen van het TEL NR kan ook via een zgn PUBLIC KEY versleuteling.

De wet stelt strenge eisen aan het mogen verwerken van persoonsgegevens. Apps op apparaten van zzp'ers of bedrijven mogen wettelijk niet zomaar van willekeurige personen persoonsgegevens gaan verzamelen en verwerken.

En terecht !

Zie het antwoord bij je eerste stap.

Ik zie het.

[kodak]

Verwijderd schreef op donderdag 9 april 2020 @ 17:57:
In OOP worden Objecten gegenereerd. Tijdens het initialisatie-proces kan je de APP de Sleutel laten genereren. Niemand kan daarbij komen; en al helemaal niet lezen.

Dat geeft slechts onder bepaalde omstandigheden bescherming en over die omstandigheden heb je als maker van een app geen controle. Je voorkomt bijvoorbeeld niet dat iemand een app op een ontwikkelomgeving draait waarbij de ontwikkelaar wel bij de gegevens kan. Het voorkomt niet dat iemand hoge rechten zoals root op een apparaat heeft en bij de gegevens kan. Het voorkomt niet dat iemand zijn eigen app maakt en de gegevens kan lezen. Het voorkomt niet dat iemand malware in zijn besturingssysteem heeft dat alles kan uitlezen. Het voorkomt niet dat iemand backups kan uitlezen. Het voorkomt niet dat iemand fysiek het geheugen bekijkt terwijl het apparaat uit elkaar ligt. En zo zijn er nog meer voorbeelden waar je OOP oplossing geen bescherming gaat geven. En dat ook waarom het geen goed idee is om bijvoorbeeld een tel nr te gebruiken want als iemand die gegevens wel kan lezen dan heeft die er ook meteen heel veel meer aan die gegevens dan weten welke apps in de buurt waren en welke besmet zouden zijn.

Het uitwisselen van het TEL NR kan ook via een zgn PUBLIC KEY versleuteling.

Dat het veilig te communiceren is wil niet zeggen dat het verstandig is om te gebruiken. Neem als voorbeeld het bsn nummer dat men ook handig vond om als btw nummer te gebruiken en vervolgens dat het bsn nummer onnodig en ongewenst verspreiding kreeg. Persoonsgegevens die niet bedoeld zijn om voor andere zaken te gebruiken moet je zo ook niet inzetten. Daarbij is een tel nr ook niet uniek genoeg voor het doel, een persoon en ook niet voor een apparaat. Je hebt er niets aan als iemand bijvoorbeeld een tablet gebruikt zonder tel nr. Je mag het waarschijnlijk niet gebruiken als het een werknummer is omdat het nummer niet van de persoon is. Je hebt er niets aan als het apparaat door meerdere mensen in gebruik is.

[Ilmar]

Wintervacht schreef op donderdag 9 april 2020 @ 17:09:
[...]

Goeie onderbouwing ook.

Anyway, ik zie nogal wat haken en ogen aan het plan.
Afgezien van het feit dat niemand er op zit te wachten en je basically vaarwel aan je privacy kan bieden, mijn bluetooth staat altijd uit, alleen aan in uitzonderlijke gevallen dat ik een telefoontje verwacht of moet plegen in de auto, hoe ga je mij tracken dan?

Het lijkt me beter om de besmettingskans/risocoindicators globaler te houden en te tracken op locatie.
Als er iemand die positief getest is en ook die app gebruikt toevallig in de super is geweest waar ik normaal gesproken kom (ook te achterhale met locatietracking), zou het wel fijn zijn daar een waarschuwing voor te krijgen. Je hoeft niet te weten met wie je in contact bent geweest die het heeft, alleen dat je mogelijk in contact bent geweest.
Dat hele bluetooth tracking staat me helemaaaaal niet aan.

Het aantrekkelijke van de bluetooth tracking, zoals ook in azerty's link is natuurlijk wel dat je alleen lokaal een database hebt van apparaat-ids die je tegengekomen bent, ipv dat er een grote centrale database nodig is waar de locatie van alle gebruikers gecrossmatched moet worden.

Mavamaarten schreef op donderdag 9 april 2020 @ 15:48:
Het enige wat ik me bij dit soort apps bedenk is ... waarom?
Dan heb je een app die zegt "proficiat u hebt weinig of veel risico"... dat is het dan. Wat ga je met die informatie doen dan? Meer of minder buiten komen? Als het goed is kom je gewoon niet buiten, enkel voor het broodnodige. Dus in principe doet die app niks nuttigs.

Maar in de plaats daarvoor heb je een hoop super privacy gevoelige info prijsgegeven (je precieze locatiegegevens en met wie je in contact bent geweest).

Of je het nu (privacy)"veilig" bedenkt of niet, de uiteindelijke gain die je krijgt is praktisch onbestaande.

Het idee van dit soort apps is vooral om wanneer we met z'n allen weer een beetje naar buiten mogen te zorgen dat nieuwe besmettingen getraceerd en snel geïsoleerd kunnen worden voordat ze weer anderen besmetten. Wanneer dat efficiënt genoeg werkt kan het de epidemie onderdrukt houden terwijl de maatschappij toch een beetje op gang blijft.

[Verwijderd]

kodak schreef op donderdag 9 april 2020 @ 20:18:
[...]

Dat geeft slechts onder bepaalde omstandigheden bescherming en over die omstandigheden heb je als maker van een app geen controle. Je voorkomt bijvoorbeeld niet dat iemand een app op een ontwikkelomgeving draait waarbij de ontwikkelaar wel bij de gegevens kan. Het voorkomt niet dat iemand hoge rechten zoals root op een apparaat heeft en bij de gegevens kan.
[...]

Heb je weleens een APP gemaakt?

[japieb]

Volgens mij kan het wel veilig:
Maak een app met daarin een BLE beacon dat een random nummer A broadcast dat periodiek (ieder uur?) wisselt. Voeg aan de app ook een BLE listener toe die andere beacons detecteert en het random nummer B uitleest. Nu kun je een contact hash H bepalen met hash(concat(A,B)) als A<B of anders hash(concat(B,A)). A detecteert B en B detecteert A en beide berekenen dezelfde contact hash H!

Sla in een locale datastore een timestamp,A en H op.

Als de gebruiker van de app besmet blijkt kan hij zijn locale datastore aan bijvoorbeeld de GGD overhandigen. De GGD publiceert de contact hashes die relevant zijn via een webservice.

De app haalt periodiek de nieuwe lijst contact hashes op van de server en controleert welke hashes ook in zijn datastore voorkomen. Voor elke match wordt een webservice aangeroepen met als parameters A,H. De server kent B bij H en kan dus controleren of de contact hash inderdaad hoort bij A en B. Als dat zo is kan de GGD contactgegevens naar de app terugsturen met het verzoek om je te melden.

Op deze manier worden er geen persoonsgegevens gedeeld.

[kodak]

Dit is overigens het voorstel voor een ontwerp wat is gegeven om het privacy vriendelijker te kunnen maken.

Verwijderd schreef op donderdag 9 april 2020 @ 21:01:
[...]Heb je weleens een APP gemaakt?

Ik denk dat je beter de vraag kan stellen of iemand die kan programmeren ook met voldoende kennis over beveiliging en privacy heeft leren ontwerpen, programmeren en testen en bereid is om verder te leren als er onderbouwde kritiek komt. Ook als die kritiek in eerste instantie niet zo welkom is. OOP kennen en kunnen ontwerpen, programmeren en testen wil niet zeggen dat je dat dus ook veilig kan. Zeker niet als iemand antwoorden gaat geven dat OOP de oplossing is zonder in te gaan op de zwakke punten. Het voorstel geeft nog een belangrijk punt wat misschien wat duidelijker is: je moet het OS vertrouwen omdat het potentieel bij alle gegevens kan. Met andere woorden: je kan er maar beter vanuit gaan dat het niet betrouwbaar is als je het toch privacy vriendelijk wil maken. Ook al heb je nog zo veel vertrouwen in de OOP theorie, Apple, Google, Microsoft enz.

[SavageNL]

Verwijderd schreef op donderdag 9 april 2020 @ 21:01:
[...]

Heb je weleens een APP gemaakt?

Heb jij weleens een APP gemaakt? Ik hoop dat je dan een debugger gebruikt hebt. Moet je eens kijken hoe goed die debugger alle waarden van alle objecten op kan lepelen, over het algemeen ook de waarden die afgeschermd in objecten zitten... En dan eens voorstellen dat je ook een debugger kan gebruiken voor een APP die niet van jou is.

Kijk anders eens naar een gemiddelde CheatEngine achtige tool, dat is uiteindelijk ook niet heel veel meer dan een debugger. Ontwikkelaars van spellen gebruiken OOP en toch kunnen dat soort tools gegevens uitlezen en aanpassen.

Ook binnen de app biedt OOP vrijwel nooit bescherming. Er zijn programmeertalen zat waar je reflectie hebt waardoor je bij gegevens kunt komen waar de ontwikkelaar heeft bedacht dat dit afgeschermd moest zijn.
Alles wat jij in je APP in een object stopt staat in je werkgeheugen of op disk, beide zijn uit te lezen.

OOP is niet iets wat inherent veilig is.


Als je APP een private key heeft dan moet je er vanuit gaan dat de gebruiker daar gewoon bij kan.
Ook als je hasht wat je binnen krijgt moet je er vanuit gaan dat het al gelezen kan zijn voordat het binnen kwam.
En nee, een APP is niet anders dan een willekeurig ander stuk software op een apparaat.

[Verwijderd]

SavageNL schreef op vrijdag 10 april 2020 @ 07:50:
[...]


Heb jij weleens een APP gemaakt? Ik hoop dat je dan een debugger gebruikt hebt. Moet je eens kijken hoe goed die debugger alle waarden van alle objecten op kan lepelen, over het algemeen ook de waarden die afgeschermd in objecten zitten... En dan eens voorstellen dat je ook een debugger kan gebruiken voor een APP die niet van jou is.

Kijk anders eens naar een gemiddelde CheatEngine achtige tool, dat is uiteindelijk ook niet heel veel meer dan een debugger. Ontwikkelaars van spellen gebruiken OOP en toch kunnen dat soort tools gegevens uitlezen en aanpassen.

Ook binnen de app biedt OOP vrijwel nooit bescherming. Er zijn programmeertalen zat waar je reflectie hebt waardoor je bij gegevens kunt komen waar de ontwikkelaar heeft bedacht dat dit afgeschermd moest zijn.
Alles wat jij in je APP in een object stopt staat in je werkgeheugen of op disk, beide zijn uit te lezen.

OOP is niet iets wat inherent veilig is.


Als je APP een private key heeft dan moet je er vanuit gaan dat de gebruiker daar gewoon bij kan.
Ook als je hasht wat je binnen krijgt moet je er vanuit gaan dat het al gelezen kan zijn voordat het binnen kwam.
En nee, een APP is niet anders dan een willekeurig ander stuk software op een apparaat.

Wat denk je, krijg je bij het Installeren van een APP de SOURCE-CODE of de MACHINE-CODE?
Kan een DEBUGGER ook maar iets met de machine-code?

OOP is niets anders dan de algemene verzamelnaam van programmeertalen (JAVA, C#, Swift, etc.) waarmee APP vandaag de dag gemaakt worden. Bij het Installeren kan de APP (die zelf ook als Object gezien kan worden) het Object van de Sleutel aanmaken, waarmee de Sleutel dus in de machine-code verborgen ligt.

Knappe jongen die aan de hand van de machine-code de exacte geheugenlocatie van de Sleutel weet te vinden.

[SavageNL]

Verwijderd schreef op vrijdag 10 april 2020 @ 11:50:
Wat denk je, krijg je bij het Installeren van een APP de SOURCE-CODE of de MACHINE-CODE?
Kan een DEBUGGER ook maar iets met de machine-code?

Ja een debugger kan ook debuggen met machine-code. Daarbij heb je het in de talen waar je het hierna over hebt (mogelijk met uitzondering van Swift) niet eens over machine code maar over VM code die over het algemeen terug te brengen is naar gewoon leesbare broncode.

Ik kan bijvoorbeeld in Java perfect iedere third party library die ik gebruik debuggen zonder dat ik daarvoor de broncode nodig heb. Zodra ze obfuscated zijn wordt het lastiger maar zelfs bij die is het meestal nog best goed mogelijk om te vinden wat je zoekt.
Bij talen die echt naar machine code gecompileerd worden helpt het zeker om de broncode te hebben maar het is absoluut niet nodig.

waarmee de Sleutel dus in de machine-code verborgen ligt.

Ehm, nee, die staat in het geheugen. De machine code van een applicatie verandert over het algemeen alleen bij updates van de software.

Knappe jongen die aan de hand van de machine-code de exacte geheugenlocatie van de Sleutel weet te vinden.

Net zo knap als iemand die de health waarde van de speler gevonden krijgt in een taal die wel compiled naar machinecode? Als je het over Java en C# hebt dan is het gewoon te decompilen. Met obfuscation wordt dat lastiger gemaakt en er zijn technieken waarmee de locatie gerandomiseerd wordt maar zelfs daar is omheen te werken.


Je doet alsof het onmogelijk is maar letterlijk iedere game trainer doet precies wat jij onmogelijk lijkt te vinden.

[ Voor 6% gewijzigd door SavageNL op 10-04-2020 12:21 ]

[Verwijderd]

SavageNL schreef op vrijdag 10 april 2020 @ 12:19:
[...]

Ja een debugger kan ook debuggen met machine-code. Daarbij heb je het in de talen waar je het hierna over hebt (mogelijk met uitzondering van Swift) niet eens over machine code maar over VM code die over het algemeen terug te brengen is naar gewoon leesbare broncode.

Ik kan bijvoorbeeld in Java perfect iedere third party library die ik gebruik debuggen zonder dat ik daarvoor de broncode nodig heb. Zodra ze obfuscated zijn wordt het lastiger maar zelfs bij die is het meestal nog best goed mogelijk om te vinden wat je zoekt.
Bij talen die echt naar machine code gecompileerd worden helpt het zeker om de broncode te hebben maar het is absoluut niet nodig.


[...]

Ehm, nee, die staat in het geheugen. De machine code van een applicatie verandert over het algemeen alleen bij updates van de software.


[...]

Net zo knap als iemand die de health waarde van de speler gevonden krijgt in een taal die wel compiled naar machinecode? Als je het over Java en C# hebt dan is het gewoon te decompilen. Met obfuscation wordt dat lastiger gemaakt en er zijn technieken waarmee de locatie gerandomiseerd wordt maar zelfs daar is omheen te werken.


Je doet alsof het onmogelijk is maar letterlijk iedere game trainer doet precies wat jij onmogelijk lijkt te vinden.

Zou je mij een voorbeeld kunnen geven van de "debugger" die machine-code omzet naar broncode? Even een prinsscreen en de naam van de "debugger." Leer ik ook weer wat bij.

[JJerome]

Dit klinkt een beetje als wat ze in Singapore hebben ontwikkeld, en open source gemaakt hebben: https://github.com/opentrace-community/opentrace-android

[wolly_a]

Ik schrijf zelf geen apps, maar als je het nu eens zo maakt...

De telefoon houdt lokaal bij middels GPS waar je zoal bent geweest. Dit blijft X tijd op je telefoon staan.

Zodra je te horen krijgt dat je Corona hebt, krijg je van de GGD een meldcode die je in je telefoon moet invoeren. Je database met GPS locaties en tijdstippen wordt naar een centrale server gestuurd.

Apps controleren periodiek (dagelijks?) of jouw tijdstip en GPS (ongeveer) overeenkomen met de gegevens in de database van de centrale server. Zo ja? Melding (en uitnodiging voor testen als het even kan).

Dan heb je je eigen gegevens lokaal op je telefoon en wordt alleen een centrale database bijgehouden van tijdstip en lokatie waar een besmet persoon is geweest. Uiteraard wordt oudere data uit deze database ook automatisch weer verwijderd).

Lijkt me privacytechnisch redelijk oke en ik zie ook nog geen mogelijkheid om stiekem te melden dat je Corona hebt...

[SavageNL]

Verwijderd schreef op vrijdag 10 april 2020 @ 13:47:
[...]


Zou je mij een voorbeeld kunnen geven van de "debugger" die machine-code omzet naar broncode? Even een prinsscreen en de naam van de "debugger." Leer ik ook weer wat bij.

Ik zit nu niet achter een pc maar pak een willekeurige Java ide en klik door op iets waar je geen broncode van hebt. Eclipse zal vragen of je een decompiler wilt installeren, intellij doet dat out of the box. Dan heb je ook nog losse decompilers die niet gekoppeld zijn aan ide's zoals JadDecompiler.

Voor debuggen doe 'new DingWatNietVanJouIs()' en hover over het resultaat. Bij Java hoef je dan niet eens te decompilen en kun je vanuit dat object door naar alle variabelen en daar weer de info van.

Verder heeft bijvoorbeeld CheatEngine ook debug mogelijkheden maar doet dat volgens mij in Assembly. Maar nogmaals, je hoeft de code niet te hebben om het geheugen uit te lezen of dingen in het geheugen te doen.

[Verwijderd]

SavageNL schreef op vrijdag 10 april 2020 @ 14:45:
[...]

Ik zit nu niet achter een pc maar pak een willekeurige Java ide en klik door op iets waar je geen broncode van hebt. Eclipse zal vragen of je een decompiler wilt installeren, intellij doet dat out of the box. Dan heb je ook nog losse decompilers die niet gekoppeld zijn aan ide's zoals JadDecompiler.

Voor debuggen doe 'new DingWatNietVanJouIs()' en hover over het resultaat. Bij Java hoef je dan niet eens te decompilen en kun je vanuit dat object door naar alle variabelen en daar weer de info van.

Verder heeft bijvoorbeeld CheatEngine ook debug mogelijkheden maar doet dat volgens mij in Assembly. Maar nogmaals, je hoeft de code niet te hebben om het geheugen uit te lezen of dingen in het geheugen te doen.

Als je vanuit Java (broncode) begint met debuggen kan je "machine-code" tracen, waarbij die machine-code omgezet (een zgn dis-assembly) is in assembler-code, wat totaal iets anders is dan de broncode, die je van-ze-lang-zal-ze-leven nooit niet vanuit de machine-code kan optuigen, welke superslimme debugger (IDE of niet) je ook maar gebruikt.

[SavageNL]

Verwijderd schreef op zaterdag 11 april 2020 @ 12:54:
[...]
Als je vanuit Java (broncode) begint met debuggen kan je "machine-code" tracen, waarbij die machine-code omgezet (een zgn dis-assembly) is in assembler-code, wat totaal iets anders is dan de broncode, die je van-ze-lang-zal-ze-leven nooit niet vanuit de machine-code kan optuigen, welke superslimme debugger (IDE of niet) je ook maar gebruikt.

Je vraagt om voorbeelden en als je die krijgt dan negeer je ze en ga je door borduren op de kennis die je niet beheerst.

Dan toch maar een screenshot die ik na 2 seconde googlen gevonden krijg. Dit is een IntelliJ decompile plugin:

Als je in IntelliJ in de kantlijn voor deze regel klikt zet je een breakpoint en die zal ook triggeren als deze methode aangeroepen wordt.

Is dit niet genoeg, tik dan gewoon "Java decompile" in in Google en sta versteld over hoe fout je het hebt. Doe even iets meer dan geen onderzoek.

Dit werkt dus over hele applicaties. Maak maar eens een test applicatie en gooi die door JadDecompiler heen, je zult niet 100% dezelfde broncode krijgen als waar je mee begon maar het komt echt ontzettend in de buurt en het het resultaat gaat hetzelfde doen als jouw oorspronkelijke applicatie.

Ja, als je het over C of andere talen die naar machine code compileren hebt dan zul je uitkomen op assemly (wat overigens voor mensen die dat beheersen ook leesbaar is), maar Java en C# compileren niet naar machine code maar naar bytecode of MSIL. Voor Android is de meest gangbare programmeertaal Java en dat is dus te decompilen.

Dan kun je de hele discussie over obfuscation aanzwengelen waardoor de code minder (maar dus niet niet) leesbaar wordt, maar het punt is dat je een private key die je in je applicatie bewaart niet afgeschermd krijgt voor iemand die daar hard naar op zoek gaat. Niet in Java en niet in een willekeurige andere taal. Je kunt het die persoon lastiger maken maar het lukt je niet om het onmogelijk te maken dus kun je beter een kant op gaan waar de privacy van je gebruikers niet afhankelijk is van iets wat je niet kunt garanderen.

[Scrivs]

Wellicht lichtelijk off-topic (bij voorbaat mijn excuses), maar afgaande op de berichten hier lijkt niet iedereen zich te realiseren wat een dergelijke app zal impliceren, en dat baart mij enige zorgen...

Niet alleen zal het betekenen dat je te allen tijde je smartphone bij je zult moeten dragen wanneer je de deur uitgaat (ik begrijp dat dit voor de meesten onder ons reeds een gewone zaak is, maar zeker niet voor iedereen en dus is dat alleen al een, zij het een kleine, inperking van onze vrijheid), maar betekent het ook dat je vanaf dan dus nog enkel winkels, supermarkten, horecagelegenheden, uitgaansgelegenheden, overheidsgebouwen en andere publieke omgevingen zult mogen betreden wanneer je smartphone een groen scherm laat zien. Zo niet, geen toegang.

Realiseren wij ons wel wat een enorme impact dat zal hebben op ons sociale leven?

Maar sterker nog; dit zal als gevolg hebben dat wij in een continue staat van paranoia en angst zullen leven, omdat ieder van onze medemens immers een 'potentieel gevaar' voor ons kan zijn, waardoor wij vrijwel letterlijk ons gehele sociale leven zullen moeten overgeven aan onze smartphone. Telkens als je een stap buiten de deur hebt gezet zul je in spanning kijken of je nog steeds 'in het groen' staat en vrij bent.

Want zodra onze smartphone ons immers een rood scherm laat zien, zijn wij persona non grata voor de rest van de maatschappij, zullen wij met niemand meer in contact mogen komen, en zullen wij onszelf moeten opsluiten in ons huis. In werkelijkheid is er geen enkele manier voor ons om er zekee van te zijn dat we inderdaad in de buurt zijn geweest van een besmet persoon, maar op basis van goed (blind) vertrouwen zal onze bewegingsvrijheid en dus onze manier van leven geheel zijn overgeleverd aan de kleur die deze app zal aangeven. Onze levens zullen letterlijk geregeerd worden door rood of groen.

Dit gaat ervoor zorgen dat wij bij voorbaat ons sociale leven zullen gaan inperken om de kans te verkleinen dat wij buiten de deur onverhoopt te dicht bij iemand in de buurt komen die te dicht bij iemand in de buurt is geweest van iemand die ook in de buurt is geweest van iemand die besmet is. Dit alles zodat onze sociale privileges zoals boodschappen doen en naar ons werk gaan ons niet worden afgenomen door deze app.

Stel je voor dat je thuis rustig op de bank zit en je telefoon geeft je opeens de waarschuwing van een rood scherm. Dan zul je dus de komende twee weken in zelfisolatie moeten verblijven en je werkgever moeten bellen met het nieuws dat je de komende twee weken thuis moet blijven van je app. Maar wat als je niet thuis kunt werken en ook niet twee weken zonder salaris kunt? (Werkgevers zullen immers heel snel stoppen met doorbetalen wanneer werknemers regelmatig maar halve maanden werken.) En wat als je niet genoeg in huis hebt om de komende twee weken mee door te komen? (De supermarkten laten je immers niet meer binnen wanneer je telefoon een rood scherm laat zien.)

Na een aantal maanden op deze manier geleefd te hebben zullen wij automatisch angstig worden voor iedereen in het openbaar of op werk, en ons sociale contact zoveel mogelijk beperken tot het uiterst essentiële, omdat iedereen potentieel de oorzaak van een rood scherm op onze telefoon kan zijn.

'Ik heb een rood scherm.' zal vanaf dan de reden kunnen zijn voor het niet meer mogen bezoeken van vrienden, familie of geliefden; voor het niet meer mogen bezoeken van musea, theaters, bioscopen, clubs of cafés; en het niet meer mogen betreden van winkels en supermarkten.

Is dat werkelijk hoe wij vanaf nu willen leven? Zeker in het licht van het feit dat de huidige coronacijfers bij lange na nog niet in de buurt komen van de jaarlijke sterftecijfers van de griep of alle andere besmettingsziektes? Zijn wij werkelijk bereid ons sociale leven zoals wij het tot op heden hebben gekend daarvoor op te geven?

De discussie over privacy is mijns inziens niet eens aan de orde in het licht van de vergaande en onherroepelijke sociale gevolgen van een maatschappij dat gebaseerd is op, en afhankelijk is van, een app als deze.

[SavageNL]

Scrivs schreef op zaterdag 11 april 2020 @ 18:05:
Niet alleen zal het betekenen dat je te allen tijde je smartphone bij je zult moeten dragen wanneer je de deur uitgaat (ik begrijp dat dit voor de meesten onder ons reeds een gewone zaak is, maar zeker niet voor iedereen en dus is dat alleen al een, zij het een kleine, inperking van onze vrijheid), maar betekent het ook dat je vanaf dan dus nog enkel winkels, supermarkten, horecagelegenheden, uitgaansgelegenheden, overheidsgebouwen en andere publieke omgevingen zult mogen betreden wanneer je smartphone een groen scherm laat zien. Zo niet, geen toegang.

Hoe kom je tot deze conclusie? Ik heb het verhaal over de apps niet helemaal gevolgd maar wat ik meegekregen heb is dat het vrijwillig wordt. Je medische gezondheid is volgens mij een bijzonder persoonsgegeven en voor zover ik weet kan je niet verplicht worden om dat vrij te geven. We hebben het hier mogelijk om een groot maatschappelijk belang waar potentieel andere regels voor gaan gelden maar de situatie dat een supermarkt een groen scherm wilt zien voordat je binnengelaten wordt lijkt me niet van de orde.

De apps zoals ik ze voorgesteld gezien heb zijn allemaal meer gericht op ervoor zorgen dat mensen weten dat ze mogelijk in aanraking geweest zijn met iemand die corona heeft zonder dat de overheid weet wie dat dan zijn geweest en de personen zelf ook niet weten wie dan corona had. Dan kunnen de personen zelf bepalen of ze daar actie op willen ondernemen. Dat is voor zover ik weet het hele privacy verhaal waar het nu over gaat.

Als je de parallel legt met andere ziektes bijvoorbeeld, voor zover ik weet ben je ook niet verplicht om aan een partner te vertellen dat je bijvoorbeeld een soa hebt. Als je getest wordt en je blijkt bijvoorbeeld HIV te hebben dan zal je gevraagd worden of je mee wilt helpen om partners op te sporen maar dat wordt niet verplicht (tenminste, dat zegt een google zoekopdracht me). Als we niet wettelijk verplichten dat iemand mat HIV zijn partners op de hoogte stelt dan lijkt het me raar dat we daar nu met corona ineens wel mee gaan beginnen.

Daarbij is in de buurt geweest zijn van iemand met corona ook geen garantie dat je corona krijgt. Ik zou verwachten dat het enige wat zo'n app zou doen is aangeven dat je op moet letten met symptonen omdat je een hoger risico hebt. Het lijkt me sterk dat zodra er bij een persoon corona geconstateert wordt dat meteen iedereen die bij die persoon in de buurt geweest is meteen zichzelf moet gaan testen. Volgens mij hebben we al niet genoeg tests dus volgens mij kunnen we dat ook gewoon niet aan.

Dus waar heb je de informatie vandaan dat er een app gemaakt wordt waardoor we met zijn allen onze leefwijze aan moeten passen en onze privacy in het gevaar komt?

[Verwijderd]

SavageNL schreef op zaterdag 11 april 2020 @ 13:23:
[...]

Fijn dat je kan "Googlen," maar ik heb geprobeerd op vakinhoudelijke kennis met je te communiceren. Ik heb zelf 25 jaar ervaring in het ontwikkelen van programma's in assembler, daarnaast in C, C++, C#, Java, Javscript, en Swift.

Fijne Pasen, verder.

[martin_v_z]

Toch ben ik ook wel benieuwd hoe de app om zal gaan met mensen die zoals ik de woonkamer aan de voorkant hebben met een voortuin van ongeveer 1,5 meter. Worden alle voorbijgangers straks geregistreerd die langs lopen terwijl ik op de bank zit? Natuurlijk zit er een raam voor en staan de ventilatieroosters nu dicht, maar dat weet de app niet. Ik ben benieuwd of bluetooth door het raam nog bereik heeft.

[dogtagz]

Verwijderd schreef op zondag 12 april 2020 @ 18:22:
[...]


Fijn dat je kan "Googlen," maar ik heb geprobeerd op vakinhoudelijke kennis met je te communiceren. Ik heb zelf 25 jaar ervaring in het ontwikkelen van programma's in assembler, daarnaast in C, C++, C#, Java, Javscript, en Swift.

Fijne Pasen, verder.

Exact dit,

Ook al krijg je mogelijk iets van machinecode met loopjes, move instructies en assignments (want dit is t uiteindelijk allemaal), dan heb je geen enkele namen voor variabelen, logica in opbouw van eventuele objecten. Je houdt alleen maar een aantal geheugen adressen over die wat simpele instructies doen.

Veel plezier met daarna iets ervan proberen te maken.

Edit:

SavageNL schreef op zaterdag 11 april 2020 @ 21:42:
[...]


Hoe kom je tot deze conclusie? Ik heb het verhaal over de apps niet helemaal gevolgd maar wat ik meegekregen heb is dat het vrijwillig wordt. Je medische gezondheid is volgens mij een bijzonder persoonsgegeven en voor zover ik weet kan je niet verplicht worden om dat vrij te geven. We hebben het hier mogelijk om een groot maatschappelijk belang waar potentieel andere regels voor gaan gelden maar de situatie dat een supermarkt een groen scherm wilt zien voordat je binnengelaten wordt lijkt me niet van de orde.

Een simpel linkje naar o.a. de 6 grondslagen van het AVG.

https://autoriteitpersoon...ersoonsgegevens-verwerken

Daarin staat dat als het noodzakelijk is om gegevens te verwerken om een taak van algemeen belang of op openbaar gezag uit te oefenen, dit gewoon gedaan kan worden. Als de overheid het dan simpelweg verplicht: dan gaat het gewoon gebeuren.

[ Voor 41% gewijzigd door dogtagz op 12-04-2020 18:51 ]

[SavageNL]

Verwijderd schreef op zondag 12 april 2020 @ 18:22:
[...]


Fijn dat je kan "Googlen," maar ik heb geprobeerd op vakinhoudelijke kennis met je te communiceren. Ik heb zelf 25 jaar ervaring in het ontwikkelen van programma's in assembler, daarnaast in C, C++, C#, Java, Javscript, en Swift.

Fijne Pasen, verder.

Serieus? Je vraagt om bewijs met een screenshot, ik geef je bewijs met een screenshot en nu is dat ook niet meer genoeg?
Je hebt toegegeven dat programma's terug te leiden zijn naar assembly. Nu geef je aan dat je assembly beheerst. Alstjeblieft je hebt je eigen punt onderuit gehaald omdat daarmee dus automatisch de locatie van ieder geheim wat je in je applicatie zet te vinden is. Niemand heeft gezegd dat het makkelijk zou zijn om het te doen, maar dat het kan.

Ik heb ook geprobeerd je te overtuigen op basis van vakinhoudelijke kennis maar ik mijn argumenten onderbouwd met voorbeelden en externe bronnen. Jij hebt alleen maar aangegeven dat ik (en anderen) het niet goed hadden zonder enige onderbouwing.
Ik heb, wat mij betreft succesvol, aangetoond dat je vakinhoudelijke kennis foutief is. Jouw stellingen zijn demonstratief onjuist.
Er zijn in dit topic meerdere mensen geweest die je daarop gewezen hebben maar blijf vooral geloven wat je gelooft en doe vooral geen onderzoek. Als je het hele internet niet accepteert als bron dan kan ik daar ook niets aan doen.

Ik heb meer dan 15 jaar ervaring, grotendeels met Java, JavaScript (/TypeScript) en met C++. Meer of minder ervaring maakt echter geen enkel verschil in deze.

Fijne pasen.

dogtagz schreef op zondag 12 april 2020 @ 18:44:
Exact dit,

Ook al krijg je mogelijk iets van machinecode met loopjes, move instructies en assignments (want dit is t uiteindelijk allemaal), dan heb je geen enkele namen voor variabelen, logica in opbouw van eventuele objecten. Je houdt alleen maar een aantal geheugen adressen over die wat simpele instructies doen.

Veel plezier met daarna iets ervan proberen te maken.

Specifiek met Java krijg je dus veel meer dan dat. Tenzij je extra tools gebruikt om het minder duidelijk te maken blijven alle member variables, methode namen (parameter namen vallen weg) en klasse namen behouden in de gecompileerde code. Als je compiled zonder debug symbols vallen de regelnummers weg. Als je obfuscate vallen de klassen namen, member variable namen en de methode namen weg en wordt de logica minder leesbaar.

Hoe onleesbaar je code ook wordt, de beste security behaal je als je er vanuit gaat dat je broncode op straat ligt. Als het mogelijk is om iets secure te krijgen zonder te leunen op 'security through obscurity' is dat altijd de voorkeur. Dat houdt dus in dat je er vanuit moet gaan dat alle kennis op straat ligt en dan alsnog een veilige oplossing moet verzinnen. Een lokale key genereren en daarmee telefoonnummers encrypten is gewoon een slecht idee.

dogtagz schreef op zondag 12 april 2020 @ 18:44:
Daarin staat dat als het noodzakelijk is om gegevens te verwerken om een taak van algemeen belang of op openbaar gezag uit te oefenen, dit gewoon gedaan kan worden. Als de overheid het dan simpelweg verplicht: dan gaat het gewoon gebeuren.

Ik weet dat als de overheid het echt wil dat ze het er wel doorheen gedrukt krijgen, maar ik heb nog nergens vernomen dat ze het zo ver laten komen. Wederom, ik heb me daar ook niet echt mee bezig gehouden maar buiten dat ze het zouden kunnen doen heb ik nergens van vernomen dat ze dit ook echt zouden gaan doen.
Alles wat ik tot nu toe gehoord heb is dat de overheid aan het kijken is naar apps maar daarbij vooral nog de privacy wil waarborgen.
Het is mogelijk om een app te maken die een groen scherm geeft bij geen geregistreerd contact met corona besmettingen maar vooralsnog heb ik geen enkel bericht gezien dat de overheid deze kant op wil. Er wordt voor zover ik heb gehoord aangegeven dat er vooral gekeken wordt naar oplossingen waar de privacy gewaarborgd wordt.

[ Voor 47% gewijzigd door SavageNL op 12-04-2020 20:00 ]

[Thralas]

dogtagz schreef op zondag 12 april 2020 @ 18:44:
Ook al krijg je mogelijk iets van machinecode met loopjes, move instructies en assignments (want dit is t uiteindelijk allemaal), dan heb je geen enkele namen voor variabelen, logica in opbouw van eventuele objecten. Je houdt alleen maar een aantal geheugen adressen over die wat simpele instructies doen.

Je vergeet dat zowel Java (JVM) als Android (ART) gebruik maken van intermediate languages met een garbage collector. Dat heeft tot gevolg dat code goed decompileerbaar is en objecten uitstekend te volgen zijn.

Ook al raak je variabelenamen (meestal) kwijt, de algehele structuur van een Android-applicatie is zéér goed te achterhalen - een wereld van verschil met gecompileerde C++-code, bijvoorbeeld.

Maar, eigenlijk was het punt van @SavageNL (en @kodak) dat je, als je iemand een programma (of: app) laat uitvoeren op zijn eigen apparaat, je er dan (in het algemeen) niet vanuit kunt gaan dat je daar zaken in kunt verstoppen - hoogstens kun je barrières opwerpen in de hoop dat iemand er dan geen zin meer in heeft. Zie ook: Denuvo.

Maakt overigens voor deze kwestie weinig uit: voor alle oplossingen geldt dat er op het apparaat van de eindgebruiker niets gebeurt dat de eindgebruiker niet zou moeten mogen weten. Je eigen sleutels verraden enkel (mogelijk) je eigen identiteit als je ze besluit te publiceren. Bovendien werd er - ook de in de kamer - gesuggereerd dat men de applicatie(s) zelf sowieso open source zou moeten maken.

[ Voor 3% gewijzigd door Thralas op 12-04-2020 20:13 ]

[Marzman]

martin_v_z schreef op zondag 12 april 2020 @ 18:36:
Toch ben ik ook wel benieuwd hoe de app om zal gaan met mensen die zoals ik de woonkamer aan de voorkant hebben met een voortuin van ongeveer 1,5 meter. Worden alle voorbijgangers straks geregistreerd die langs lopen terwijl ik op de bank zit? Natuurlijk zit er een raam voor en staan de ventilatieroosters nu dicht, maar dat weet de app niet. Ik ben benieuwd of bluetooth door het raam nog bereik heeft.

Goede vraag, als ik in de keuken de afwas die is dat ook net 2 meter. Maar ik denk dat de tijdsduur ook wel meetelt? Anders is het ook elke auto die je tegemoet komt.

[Thralas]

Marzman schreef op zondag 12 april 2020 @ 22:03:
[...]

Goede vraag, als ik in de keuken de afwas die is dat ook net 2 meter. Maar ik denk dat de tijdsduur ook wel meetelt? Anders is het ook elke auto die je tegemoet komt.

De specs van Google en Apple beschrijven een beacon interval van 200-270 ms. De resolutie is er (in theorie).

Verder:

Scanning strategy that works best is opportunistic (leveraging existing wakes and scan windows) and with minimum periodic sampling every 5 mins

Uit de API (Google) blijkt dat je voor iedere hit een twee-tupel terugkrijgt: {datum, contactduur} waarbij voor de contactduur geldt: Length of contact in 5 minute increments.

Als je vijf minuten als threshold gebruikt vervallen alle passanten. Natuurlijk kun je ook daardoor besmet raken, maar die kans is héél wat groter als je de hele avond zit te tafelen met iemand.

Het burenscenario is deels te ondervangen als je een overzicht per dag te zien krijgt: als je iedere dag 8 uur contact hebt maar niemand is ziek op je werk of school dan kan dat bijna niet missen.

En het hoeft natuurlijk niet te betekenen dat je bij een 'hit' meteen 2 weken in quarantaine zit. Misschien fungeert het enkel een waarschuwing om heel goed op te letten als je niet weet wie het was (ervan uitgaande dat iemand die positief getest wordt ook zelf nog z'n best doet om contacten te waarschuwen).

[Verwijderd]

Ik kwam dit zeer lezenswaardig artikel tegen, dat de vinger exact op de zere plek legt: in centrale opslag schult een groot gevaar.

Dat Android zo lek is als een zeef behoeft geen betoog: wie kwaad wil hackt de telefoon en alle data ligt voor het oprapen, maar dat betreft dan slechts één telefoon. Het echte kwaad schuilt in bedrijven (Google, Apple, Microsoft, FaceBook, Amazon, etc) en overheden (China) die via big-data de hele maatschappij (kunnen) ontwrichten - lees "hun wil kunnen opleggen".

Afijn, ik herhaal nogmaals: Indien een APP nodig is voor "contact tracking and tracing" garandeer dan dat alle data lokaal wordt opgeslagen (het liefst versleuteld).

Maxim Februari :“We gaan toch niet de rechtstaat afschaffen omdat we ziek zijn?”
Het misverstand ‘privacy’ = ‘databescherming’.

https://www.nrc.nl/nieuws...is-het-punt-niet-a3996597