/dev/null
- Overig
Oxford univ. corona-app BS
Nederlands verderop.
ENGLISH
The worldwide introduction of Bluetooth-based Corona-apps was heavily influenced by research conducted by the research group of professor Christophe Fraser (Big Data Institute, Li Ka Shing Centre for Health Information and Discovery, University of Oxford, UK).
In particular a paper, "Quantifying SARS-CoV-2 transmission suggests epidemic control with digital contact tracing" written by Luca Ferretti et al., published in Science (and medrxiv.org) describes the simulation model and outcomes used in later advice to the NHS/NHSx and has influenced most later Bluetooth-based Corona-apps.
Remarkable difference
However, I noticed something fishy. A preliminary version of Ferretti's paper was published by Science on 31 Mar 2020, while the final version was published on 08 May 2020. These versions are mostly identical, except for two things:
1) Minor corrections with irrelevant impact on the simulation results. For example, the preliminary version mentions
"The App we propose ..." while the final version mentions "The app we propose ..."
2) Significant differences in Figure 4 and the text accompanying Figure 4.
Differences in text accompanying Figure 4
From https://web.archive.org/web/20200401215425/https://science.sciencemag.org/content/early/2020/03/30/science.abb6936 of 31 Mar 2020 (emphasis added by me):
From https://science.sciencemag.org/content/368/6491/eabb6936 of 08 May 2020 (emphasis added by me):
W.r.t. Figure 4 itself: the older version (https://web.archive.org/web/20200401215425/https://science.sciencemag.org/content/sci/early/2020/03/30/science.abb6936/F4.large.jpg?download=true) refers to GPS and QR-codes, while the final version (https://science.sciencemag.org/content/sci/368/6491/eabb6936/F5.large.jpg?download=true) refers to Bluetooth in all instances.
Additional references
In a similar paper posted March 12, 2020, Figure 4 is not yet present: https://www.medrxiv.org/content/10.1101/2020.03.08.20032946v1.full-text. However, in an update posted March 31, 2020, Figure 4 is present (referring to GPS and QR-codes): https://www.medrxiv.org/content/10.1101/2020.03.08.20032946v2.full-text.
In https://www.coronavirus-fraser-group.org/for-media "Digital contact tracing slide deck" (direct link: https://www.coronavirus-fraser-group.org/files/files/stopping-the-spread-of-the-covid-19-epidemic-is-possible-if-cases-are-identified-fast-and-efficiently.pdf) contains the "old Figure 4" (implying the use of GPS and QR-codes) while it also mentions, w.r.t. uptake:
At least 60% uptake, or 56%?
I don't know whether the drop of initially a minimum 60% uptake to 56% in the advice to NHS/NHSx of 16 April 2020 (https://045.medsci.ox.ac.uk/files/files/report-effective-app-configurations.pdf) may have been caused by switching the app from GPS + QR-Codes to Bluetooth (Low Energy, BLE). However, this document also mentions that, according to OFCOM, 70% of the UK population owns a smartphone; if 80% (a convenient number?) of those smartphone owners installs the app, one ends up with 56%. Interestingly this paper includes the following text in the Discussion section:
Conclusion
It appears that the type of app, based either GPS + QR-codes or Bluetooth, was not taken into account in the simulations described by Ferretti et al. (otherwise one would expect different results). Perhaps more importantly, the large inaccuracies of, on the one hand location determination using GPS, and on the other hand "distance" measurements using Bluetooth, seem not to have been incorporated in the simulations at all. Hence, the minimum uptake percentages of 56% and 60% seem to be wild guesses not even taking into account technical inaccuracies of proximity protocols. Given that such uptakes are not realised anywhere, while the effectiveness of such apps increases quadratically with uptake (actually worse if less than 100% of positively diagnosed app-users actually upload app-data), it should not come as a surprise that such apps hardly, if at all, contribute to combating the epidemic. Worse, even if a small percentage of app-users believe that they cannot be infected if their app does not warn them, the net effect of such apps is probably that more people get infected.
NEDERLANDS
De wereldwijde introductie van op Bluetooth gebaseerde Corona-apps is sterk beïnvloed door onderzoek uitgevoerd door de onderzoeksgroep van professor Christophe Fraser (Big Data Institute, Li Ka Shing Centre for Health Information and Discovery, University of Oxford, UK).
In het bijzonder een wetenschappelijk artikel, "Quantifying SARS-CoV-2 transmission suggests epidemic control with digital contact tracing" geschreven door Luca Ferretti et al., gepubliceerd in Science (en in medrxiv.org) beschrijft het simulatiemodel en uitkomsten die later zijn gebruikt om de NHS (Britse National Health Service) te adviseren en heeft de meeste latere op Bluetooth gebaseerde Corona-apps beïnvloed.
Opmerkelijk verschil
Echter, er viel mij iets op dat stinkt. Een vroege versie van Ferretti's artikel is door Science gepubliceerd op 31 maart 2020, terwijl de uiteindelijke versie op 08 mei 2020 is gepubliceerd. Deze versies zijn grotendeels identiek, op twee zaken na:
1) Kleine correcties met irrelevante impact op de simulatieresultaten. Bijvoorbeeld, de vroege versie spreekt van
"The App we propose ..." terwijl in de uiteindelijke versie staat: "The app we propose ..."
2) Significante verschillen in Figuur 4 en het bijschrift bij Figuur 4.
Voor de verschillen in de bijschriften bij Figuur 4 zie "Differences in text accompanying Figure 4" in de Engelstalige versie hierboven, en voor additionele referenties zie Additional references.
Tenminste 60% adoptie, of 56%?
Ik weet niet of de daling van de aanvankelijke minimaal benodigde adoptie van 60% naar 56% in het advies aan de NHS
van 16 april 2020 (https://045.medsci.ox.ac.uk/files/files/report-effective-app-configurations.pdf) zou kunnen zijn veroorzaakt door het switchen van de app van GPS + QR-Codes naar Bluetooth (Low Energy, BLE). Echter, in dit document staat ook dat, volgens de Britse telecomwaakhond OFCOM, 70% van de Britse bevolking een smartphone bezit; als 80% (een mooi afgerond en geloofwaardig percentage?) van die smartphone-bezitters de app installeert, kom je uit op 56%. Interessant is dat het Discussie-deel van dat document de volgende tekst bevat:
Conclusie
Het lijkt erop dat het type app, gebaseerd op ofwel GPS + QR-codes ofwel Bluetooth, niet is meegenomen in de simulaties beschreven door Ferretti et al. (anders zou je verschillende resultaten verwachten). Wellicht belangrijker, de grote onnauwkeurigheden van, aan de ene kant locatiebepaling middels GPS en aan de andere kant "afstand"-metingen middels Bluetooth, lijken geheel niet te zijn meegenomen in de simulaties. Daarom lijken de minimale adoptiepercentages van 60% en 56% wilde gokken te zijn waarbij zelfs geen rekening is gehouden met de onnauwkeurigheden van proximity protocollen. Gegeven dat zulke adoptiecijfers nergens worden gerealiseerd, terwijl de effectieviteit van zulke apps kwadratisch toeneemt met de adoptie (in werkelijkheid slechter als minder dan 100% positief geteste app-gebruikers app-date uploaden), mag het geen verrassing heten dat zulke apps nauwelijks of niet bijdragen aan het bestrijden van de epidemie. Erger, zelfs als maar een klein percentage van de app-gebruikers denkt dat zij niet besmet kunnen zijn zolang hun app hen niet waarschuwt, is het netto effect van dit soort apps waarschijnlijk dat meer mensen geïnfecteerd raken.
ENGLISH
The worldwide introduction of Bluetooth-based Corona-apps was heavily influenced by research conducted by the research group of professor Christophe Fraser (Big Data Institute, Li Ka Shing Centre for Health Information and Discovery, University of Oxford, UK).
In particular a paper, "Quantifying SARS-CoV-2 transmission suggests epidemic control with digital contact tracing" written by Luca Ferretti et al., published in Science (and medrxiv.org) describes the simulation model and outcomes used in later advice to the NHS/NHSx and has influenced most later Bluetooth-based Corona-apps.
Remarkable difference
However, I noticed something fishy. A preliminary version of Ferretti's paper was published by Science on 31 Mar 2020, while the final version was published on 08 May 2020. These versions are mostly identical, except for two things:
1) Minor corrections with irrelevant impact on the simulation results. For example, the preliminary version mentions
"The App we propose ..." while the final version mentions "The app we propose ..."
2) Significant differences in Figure 4 and the text accompanying Figure 4.
Differences in text accompanying Figure 4
From https://web.archive.org/web/20200401215425/https://science.sciencemag.org/content/early/2020/03/30/science.abb6936 of 31 Mar 2020 (emphasis added by me):
Fig. 4 A schematic of app-based COVID-19 contact tracing.
Contacts of individual A (and all individuals using the app) are traced using GPS co-localisations with other App users, supplemented by scanning QR-codes displayed on high-traffic public amenities where GPS is too coarse. Individual A requests a SARS-COV-2 test (using the app) and their positive test result triggers an instant notification to individuals who have been in close contact. The App advises isolation for the case (individual A) and quarantine of their contacts.
Contacts of individual A (and all individuals using the app) are traced using GPS co-localisations with other App users, supplemented by scanning QR-codes displayed on high-traffic public amenities where GPS is too coarse. Individual A requests a SARS-COV-2 test (using the app) and their positive test result triggers an instant notification to individuals who have been in close contact. The App advises isolation for the case (individual A) and quarantine of their contacts.
From https://science.sciencemag.org/content/368/6491/eabb6936 of 08 May 2020 (emphasis added by me):
Fig. 4 A schematic of app-based COVID-19 contact tracing.
Contacts of individual A (and all individuals using the app) are traced using low-energy Bluetooth connections with other app users. Individual A requests a SARS-CoV-2 test (using the app) and that person’s positive test result triggers an instant notification to individuals who have been in close contact. The app advises isolation for the case (individual A) and quarantine of the individual’s contacts.
Contacts of individual A (and all individuals using the app) are traced using low-energy Bluetooth connections with other app users. Individual A requests a SARS-CoV-2 test (using the app) and that person’s positive test result triggers an instant notification to individuals who have been in close contact. The app advises isolation for the case (individual A) and quarantine of the individual’s contacts.
W.r.t. Figure 4 itself: the older version (https://web.archive.org/web/20200401215425/https://science.sciencemag.org/content/sci/early/2020/03/30/science.abb6936/F4.large.jpg?download=true) refers to GPS and QR-codes, while the final version (https://science.sciencemag.org/content/sci/368/6491/eabb6936/F5.large.jpg?download=true) refers to Bluetooth in all instances.
Additional references
In a similar paper posted March 12, 2020, Figure 4 is not yet present: https://www.medrxiv.org/content/10.1101/2020.03.08.20032946v1.full-text. However, in an update posted March 31, 2020, Figure 4 is present (referring to GPS and QR-codes): https://www.medrxiv.org/content/10.1101/2020.03.08.20032946v2.full-text.
In https://www.coronavirus-fraser-group.org/for-media "Digital contact tracing slide deck" (direct link: https://www.coronavirus-fraser-group.org/files/files/stopping-the-spread-of-the-covid-19-epidemic-is-possible-if-cases-are-identified-fast-and-efficiently.pdf) contains the "old Figure 4" (implying the use of GPS and QR-codes) while it also mentions, w.r.t. uptake:
Ideally 60+ %
Opt-out automatic installation?
Opt-out automatic installation?
At least 60% uptake, or 56%?
I don't know whether the drop of initially a minimum 60% uptake to 56% in the advice to NHS/NHSx of 16 April 2020 (https://045.medsci.ox.ac.uk/files/files/report-effective-app-configurations.pdf) may have been caused by switching the app from GPS + QR-Codes to Bluetooth (Low Energy, BLE). However, this document also mentions that, according to OFCOM, 70% of the UK population owns a smartphone; if 80% (a convenient number?) of those smartphone owners installs the app, one ends up with 56%. Interestingly this paper includes the following text in the Discussion section:
The accuracy with which bluetooth low-energy signatures can be converted to useful proxies of transmission risk is currently uncertain.
Conclusion
It appears that the type of app, based either GPS + QR-codes or Bluetooth, was not taken into account in the simulations described by Ferretti et al. (otherwise one would expect different results). Perhaps more importantly, the large inaccuracies of, on the one hand location determination using GPS, and on the other hand "distance" measurements using Bluetooth, seem not to have been incorporated in the simulations at all. Hence, the minimum uptake percentages of 56% and 60% seem to be wild guesses not even taking into account technical inaccuracies of proximity protocols. Given that such uptakes are not realised anywhere, while the effectiveness of such apps increases quadratically with uptake (actually worse if less than 100% of positively diagnosed app-users actually upload app-data), it should not come as a surprise that such apps hardly, if at all, contribute to combating the epidemic. Worse, even if a small percentage of app-users believe that they cannot be infected if their app does not warn them, the net effect of such apps is probably that more people get infected.
NEDERLANDS
De wereldwijde introductie van op Bluetooth gebaseerde Corona-apps is sterk beïnvloed door onderzoek uitgevoerd door de onderzoeksgroep van professor Christophe Fraser (Big Data Institute, Li Ka Shing Centre for Health Information and Discovery, University of Oxford, UK).
In het bijzonder een wetenschappelijk artikel, "Quantifying SARS-CoV-2 transmission suggests epidemic control with digital contact tracing" geschreven door Luca Ferretti et al., gepubliceerd in Science (en in medrxiv.org) beschrijft het simulatiemodel en uitkomsten die later zijn gebruikt om de NHS (Britse National Health Service) te adviseren en heeft de meeste latere op Bluetooth gebaseerde Corona-apps beïnvloed.
Opmerkelijk verschil
Echter, er viel mij iets op dat stinkt. Een vroege versie van Ferretti's artikel is door Science gepubliceerd op 31 maart 2020, terwijl de uiteindelijke versie op 08 mei 2020 is gepubliceerd. Deze versies zijn grotendeels identiek, op twee zaken na:
1) Kleine correcties met irrelevante impact op de simulatieresultaten. Bijvoorbeeld, de vroege versie spreekt van
"The App we propose ..." terwijl in de uiteindelijke versie staat: "The app we propose ..."
2) Significante verschillen in Figuur 4 en het bijschrift bij Figuur 4.
Voor de verschillen in de bijschriften bij Figuur 4 zie "Differences in text accompanying Figure 4" in de Engelstalige versie hierboven, en voor additionele referenties zie Additional references.
Tenminste 60% adoptie, of 56%?
Ik weet niet of de daling van de aanvankelijke minimaal benodigde adoptie van 60% naar 56% in het advies aan de NHS
van 16 april 2020 (https://045.medsci.ox.ac.uk/files/files/report-effective-app-configurations.pdf) zou kunnen zijn veroorzaakt door het switchen van de app van GPS + QR-Codes naar Bluetooth (Low Energy, BLE). Echter, in dit document staat ook dat, volgens de Britse telecomwaakhond OFCOM, 70% van de Britse bevolking een smartphone bezit; als 80% (een mooi afgerond en geloofwaardig percentage?) van die smartphone-bezitters de app installeert, kom je uit op 56%. Interessant is dat het Discussie-deel van dat document de volgende tekst bevat:
The accuracy with which bluetooth low-energy signatures can be converted to useful proxies of transmission risk is currently uncertain.
Conclusie
Het lijkt erop dat het type app, gebaseerd op ofwel GPS + QR-codes ofwel Bluetooth, niet is meegenomen in de simulaties beschreven door Ferretti et al. (anders zou je verschillende resultaten verwachten). Wellicht belangrijker, de grote onnauwkeurigheden van, aan de ene kant locatiebepaling middels GPS en aan de andere kant "afstand"-metingen middels Bluetooth, lijken geheel niet te zijn meegenomen in de simulaties. Daarom lijken de minimale adoptiepercentages van 60% en 56% wilde gokken te zijn waarbij zelfs geen rekening is gehouden met de onnauwkeurigheden van proximity protocollen. Gegeven dat zulke adoptiecijfers nergens worden gerealiseerd, terwijl de effectieviteit van zulke apps kwadratisch toeneemt met de adoptie (in werkelijkheid slechter als minder dan 100% positief geteste app-gebruikers app-date uploaden), mag het geen verrassing heten dat zulke apps nauwelijks of niet bijdragen aan het bestrijden van de epidemie. Erger, zelfs als maar een klein percentage van de app-gebruikers denkt dat zij niet besmet kunnen zijn zolang hun app hen niet waarschuwt, is het netto effect van dit soort apps waarschijnlijk dat meer mensen geïnfecteerd raken.
Reacties (13)
Daarom lijken de minimale adoptiepercentages van 60% en 56% wilde gokken te zijn waarbij zelfs geen rekening is gehouden met de onnauwkeurigheden van proximity protocollen.
Beetje koffiedik kijken dit.Het idee was gebaseerd op een wiskundig model met heel veel aannames als input.
Niet zozeer uit de lucht gegrepen aannames, maar op basis van wat er toen over bekend was vanuit China.
In [1] lees ik dat volgens het wiskundige model minstens 56% van de totale bevolking de app moest gebruiken om de epidemie te stoppen, onder voorwaarde dat alle 70-plussers (vaak geen smartphone gebruikers) ondertussen goed worden afgeschermd. Mogelijk heeft men pas later aan die 70-plussers gedacht, en maakt dat het verschil van 4%(?)
[1] https://www.research.ox.ac.uk/Article/2020-04-16-digital-contact-tracing-can-slow-or-even-stop-coronavirus-transmission-and-ease-us-out-of-lockdown
Ik denk niet dat de nauwkeurigheid van de meettechniek er toe doet (zolang men er maar voldoende rekening mee houdt)
als het enige doel uitdoving van de epidemie is,ook al is er best wel verschil in nauwkeurigheid tussen afstandmeting met BT en afstandsmeting met GPS en is er een verschil in randverschijnselen.
Het achterliggende idee is dat mensen die mogelijk een verhoogd risico hebben gelopen (omdat ze een tijdje niet ver verwijderd waren van een besmet persoon) zo snel mogelijk in quarantaine gaan en worden getest, zodat ze geen andere mensen meer besmetten.
Het verschil met BT is dat vanwege de onnauwkeurigheid van GPS men een groter gebied moet selecteren rond de gegeven GPS-coördinaten dan bij BT. En als je een groter gebied selecteert, bevinden zich daarin meestal meer mensen.
In drukke gebieden kan het zelfs gaan om behoorlijk veel meer mensen.
Dus bij gebruik van GPS worden er meestal meer mensen getest dan bij BT, maar dezelfde mensen als bij een
BT-meting (dus inclusief eventueel besmette personen) maken nog wél steeds deel uit van van deze grotere groep,
of anders heeft men in de instelling van de app het gebied rond de gegeven GPS-coordinaten niet groot genoeg gedefinieerd.
Weliswaar kan in het grotere gebied in geval van GPS toevallig nóg een besmet persoon aanwezig zijn, die met BT niet zou worden gedetecteerd. Maar tegen de tijd dat de epidemie volledig is uitgedoofd, is de kans dat dit gebeurt zó klein geworden dat het verwaarloosbaar is. Immers er zijn dan in het hele land nog maar heel weinig mensen besmet)
Dus puur en alleen gelet op of de epidemie uitdoofd of niet, maakt het vrijwel geen verschil of men BT of GPS gebruikt. Alleen de randverschijnselen zijn anders.
Door Anoniem: Ik denk niet dat de nauwkeurigheid van de meettechniek er toe doet (zolang men er maar voldoende rekening mee houdt) als het enige doel uitdoving van de epidemie is,ook al is er best wel verschil in nauwkeurigheid tussen afstandmeting met BT en afstandsmeting met GPS en is er een verschil in randverschijnselen.
GPS was voor de CornaMelder app nooit een serieuze optie. GPS werkt sowieso niet in gebouwen van gewapend beton en ook buiten is het op mobieltjes veel te onnauwkeurig, gegeven het doel van het meten van social distancing. We spreken hier over een straal van 4,9 meter, onder de meest ideale omstandigheden van een heldere, open hemel.
How accurate is GPS?
GPS-enabled smartphones are typically accurate to within a 4.9 m (16 ft.) radius under open sky (view source at ION.org). However, their accuracy worsens near buildings, bridges, and trees.
https://www.gps.gov/systems/gps/performance/accuracy/
Van BLE beacons weten we inmiddels ook dat het gebruik daarvan in bussen en treinen problematisch is, vanwege de reflecties door de wanden, en de hoge kans op valsnegatieven en valspositieven, zoals Erik breed heeft uitgemeten hier op Security.NL. Daar waar je juist zou willen dat het goed werkt, in het openbaar vervoer, werkt het domweg niet.
Door Anoniem: Het verschil met BT is dat vanwege de onnauwkeurigheid van GPS men een groter gebied moet selecteren rond de gegeven GPS-coördinaten dan bij BT. En als je een groter gebied selecteert, bevinden zich daarin meestal meer mensen.
In drukke gebieden kan het zelfs gaan om behoorlijk veel meer mensen.
Dus bij gebruik van GPS worden er meestal meer mensen getest dan bij BT, maar dezelfde mensen als bij een
BT-meting (dus inclusief eventueel besmette personen) maken nog wél steeds deel uit van van deze grotere groep,
of anders heeft men in de instelling van de app het gebied rond de gegeven GPS-coordinaten niet groot genoeg gedefinieerd.
In drukke gebieden kan het zelfs gaan om behoorlijk veel meer mensen.
Dus bij gebruik van GPS worden er meestal meer mensen getest dan bij BT, maar dezelfde mensen als bij een
BT-meting (dus inclusief eventueel besmette personen) maken nog wél steeds deel uit van van deze grotere groep,
of anders heeft men in de instelling van de app het gebied rond de gegeven GPS-coordinaten niet groot genoeg gedefinieerd.
Inderdaad is GPS veel te grof voor dit soort doelen, als ik mijn telefoon thuis op tafel leg, springt de aanduiding van mijn locatie soms 2 straten verder. Maar er is nog een andere reden om BT te gebruiken. Met GPS zou iedereen continue zijn locatie moeten doorgeven aan een centrale database (Ik hoor hier iedereen al moord en brand schreeuwen). Bij BT kunnen de apparaten onderling gegevens uitwisselen en dat is wat de app ook doet, ik ben bij jou in de buurt, mocht mijn eigenaar ziek zijn, dan zie je deze code verschijnen. Door alleen die code uit te wisselen en de codes van de laatste paar dagen te uploaden naar een centrale locatie, zou de patient anoniem moeten blijven en dus de privacy beter gegarandeerd moeten zijn. Uitzonderingen zijn er altijd, want wanneer ik afgezonderd woon en werk en maar 1 bezoeker per maand heb, weet ik de bron toch wel.
05-02-2021, 08:12 door
Bitje-scheef
Inderdaad is GPS veel te grof voor dit soort doelen, als ik mijn telefoon thuis op tafel leg, springt de aanduiding van mijn locatie soms 2 straten verder. Maar er is nog een andere reden om BT te gebruiken. Met GPS zou iedereen continue zijn locatie moeten doorgeven aan een centrale database (Ik hoor hier iedereen al moord en brand schreeuwen). Bij BT kunnen de apparaten onderling gegevens uitwisselen en dat is wat de app ook doet, ik ben bij jou in de buurt, mocht mijn eigenaar ziek zijn, dan zie je deze code verschijnen. Door alleen die code uit te wisselen en de codes van de laatste paar dagen te uploaden naar een centrale locatie, zou de patient anoniem moeten blijven en dus de privacy beter gegarandeerd moeten zijn. Uitzonderingen zijn er altijd, want wanneer ik afgezonderd woon en werk en maar 1 bezoeker per maand heb, weet ik de bron toch wel.
Dat is ongeveer zoals het nu dus ook werkt. Er blijven uitzonderingen, je omgeving en mensen, vooral mensen creëren uitzonderingen. En nee niet iedereen, heeft de app, meldt zich ziek of wordt geregistreerd. Sommige contacten zijn niet bekend. Acceptatie en opvolging blijven cruciaal.
Nu vind ik de afstandsmeting met BT wel voldoende, met een kleine tweak. Maar een aantal mensen op dit forum gaan uit hun stekker als deze niet op 1 meter nauwkeurig inclusief uitzonderingen goed werkt (Erik van Straten heeft dit vrij aardig onderzocht en heeft theoretisch gelijk, maar met een beetje schaven....). Je een keer extra laten testen is in mijn ogen geen probleem en vangt een aantal onnauwkeurigheden af (weliswaar klein). Dus had het kunnen werken ?
Technisch ja, met kanttekeningen. Menselijk gezien, vul zelf maar in...
Door Bitje-scheef:
Dat is ongeveer zoals het nu dus ook werkt. Er blijven uitzonderingen, je omgeving en mensen, vooral mensen creëren uitzonderingen. En nee niet iedereen, heeft de app, meldt zich ziek of wordt geregistreerd. Sommige contacten zijn niet bekend. Acceptatie en opvolging blijven cruciaal.
Nu vind ik de afstandsmeting met BT wel voldoende, met een kleine tweak. Maar een aantal mensen op dit forum gaan uit hun stekker als deze niet op 1 meter nauwkeurig inclusief uitzonderingen goed werkt (Erik van Straten heeft dit vrij aardig onderzocht en heeft theoretisch gelijk, maar met een beetje schaven....). Je een keer extra laten testen is in mijn ogen geen probleem en vangt een aantal onnauwkeurigheden af (weliswaar klein). Dus had het kunnen werken ?
Technisch ja, met kanttekeningen. Menselijk gezien, vul zelf maar in...
Dat is ongeveer zoals het nu dus ook werkt. Er blijven uitzonderingen, je omgeving en mensen, vooral mensen creëren uitzonderingen. En nee niet iedereen, heeft de app, meldt zich ziek of wordt geregistreerd. Sommige contacten zijn niet bekend. Acceptatie en opvolging blijven cruciaal.
Nu vind ik de afstandsmeting met BT wel voldoende, met een kleine tweak. Maar een aantal mensen op dit forum gaan uit hun stekker als deze niet op 1 meter nauwkeurig inclusief uitzonderingen goed werkt (Erik van Straten heeft dit vrij aardig onderzocht en heeft theoretisch gelijk, maar met een beetje schaven....). Je een keer extra laten testen is in mijn ogen geen probleem en vangt een aantal onnauwkeurigheden af (weliswaar klein). Dus had het kunnen werken ?
Technisch ja, met kanttekeningen. Menselijk gezien, vul zelf maar in...
Je kunt inderdaad ook heel hoge eisen stellen. Het systeem zorgt ervoor, dat je een seintje krijgt dat testen zinnig kan zijn. Eerlijk is eerlijk, het testen is niet alles, maar liever een keer testen voor niets, dan je hele omgeving besmetten en zo een kwetsbare persoon die je dierbaar is in de problemen te helpen.
Door Bitje-scheef: Nu vind ik de afstandsmeting met BT wel voldoende, met een kleine tweak. Maar een aantal mensen op dit forum gaan uit hun stekker als deze niet op 1 meter nauwkeurig inclusief uitzonderingen goed werkt (Erik van Straten heeft dit vrij aardig onderzocht en heeft theoretisch gelijk, maar met een beetje schaven....).
In de pagina "Resultaten" in het "rapport" van de veldtest in Vught [1] staat:
> Nauwkeurige afstandsmeting met bluetooth is niet mogelijk, indicatie van afstand is wél te meten
en dat blijkt ook uit de "heatmap" rechts van die tekst. [1] https://www.tweedekamer.nl/downloads/document?id=5ca0984a-bae9-4282-8e04-d2ee481b5bc0&title=COVID-19%20Notificatie%20APP.pdf
Laat ik eens inzoomen op de getallen in die heatmap uit [1]. Als ik de rijen voor 3-17m samenvoeg, krijgen we:
Tabel 1:
34-51 52-63 64-73 74-100 Som
3-17m 14 216 468 698
2m 6 131 169 306
1m 2 24 148 51 225
-------------------------------------- +
Som 2 44 495 688 1229
34-51 52-63 64-73 74-100 Som
3-17m 14 216 468 698
2m 6 131 169 306
1m 2 24 148 51 225
-------------------------------------- +
Som 2 44 495 688 1229
Samenvoegen kolom 1 en 2 (de kleinste verzwakkingen t.g.v. "afstand"):
Tabel 2:
34-63 64-73 74-100 Som
3-17m 14 216 468 698
2m 6 131 169 306
1m 26 148 51 225
-------------------------------------- +
Som 46 495 688 1229
34-63 64-73 74-100 Som
3-17m 14 216 468 698
2m 6 131 169 306
1m 26 148 51 225
-------------------------------------- +
Som 46 495 688 1229
Laat ik niet zeuren en 2m als grens nemen, dus 1m en 2m samenvoegen:
Tabel 3:
34-63 64-73 74-100 Som
3-17m 14 216 468 698
1-2m 32 279 220 531
-------------------------------------- +
Som 46 495 688 1229
34-63 64-73 74-100 Som
3-17m 14 216 468 698
1-2m 32 279 220 531
-------------------------------------- +
Som 46 495 688 1229
Laat ik dit normaliseren op 1000 (1e rij x 1000/698 en 2e rij x 1000/531), om een realistische vergelijking te kunnen maken tussen het aantal denkbeeldige mensen op resp. meer en minder dan 2m:
Tabel 4:
34-63 64-73 74-100 Som
3-17m 20 309 671 1000
1-2m 60 526 414 1000
-------------------------------------- +
Som 80 835 1085 2000
34-63 64-73 74-100 Som
3-17m 20 309 671 1000
1-2m 60 526 414 1000
-------------------------------------- +
Som 80 835 1085 2000
Laat ik 73dB verzwakking als grens nemen voor meer of minder dan 2m, dus kolom 1 en 2 samenvoegen:
Tabel 5:
34-73 74-100 Som
3-17m 329 671 1000
1-2m 586 414 1000
-------------------------------------- +
Som 915 1085 2000
34-73 74-100 Som
3-17m 329 671 1000
1-2m 586 414 1000
-------------------------------------- +
Som 915 1085 2000
Dus geldt:
TP = 586
FP = 329
TN = 671
FN = 414
Deze getallen zitten erg dicht bij elkaar. Het is pure statistiek om daar gemiddeld wat redelijks uit te halen - met als prijs veel false positives en veel false negatives.
Ik heb vanalles geprobeerd (x4, x2, x1 voor de kolommen, interpoleren naar 1,5m etc.) maar kwam met deze cijfers nooit op 73%/73% voor sensitiviteit en specificiteit. Of VWS dat resultaat er eerlijk uit heeft kunnen persen, weet ik niet (maar dat geloof ik niet, dit waren de minimaal wenselijke getallen - die zich makkelijk naar de veelgenoemde 75% laten afronden, zoals in [3]; weer een leugentje "om bestwil"?). Dit is precies wat Anoniem in https://security.nl/posting/688568 schreef: "er zijn leugens, grotere leugens en statistiek".
Met de getallen uit tabel 5 kom ik op:
Sensitiviteit = 586 / (586 + 414) = 58,6%
Specificiteit = 671 / (671 + 329) = 67,1%
Door te gevoeligheidsgrens te variëren kun je de sensitiviteit verhogen - ten koste van de specificiteit en vice versa. En misschien heb ik ongelijk en kun je die 73%/73% wel uit deze getallen optimaliseren, maar dan zul je zien dat dit zo wiebelig is dat er in de praktijk en/of bij een volgende veldtest iets heel anders uitkomt.
Dat je met smartphones (op basis van BLE) geen afstanden kunt meten wordt zelfs niet verzwegen in [2]:
Hoe meet CoronaMelder de afstand tot andere gebruikers van de app?
CoronaMelder kan niet de precieze afstand meten tot andere mensen die de app gebruiken, en dat is ook niet nodig. Maar kan wel inschatten of je dichtbij andere gebruikers van de app bent of niet. De app gebruikt daarvoor een bepaalde vorm van bluetooth, Bluetooth Low Energy (lage energie-bluetooth). Hoe sterker het signaal, hoe dichterbij je bent. Als je een melding krijgt dat je risico loopt, was je zeker meer dan 15 minuten dicht in de buurt van iemand die later besmet bleek te zijn.
CoronaMelder kan niet de precieze afstand meten tot andere mensen die de app gebruiken, en dat is ook niet nodig. Maar kan wel inschatten of je dichtbij andere gebruikers van de app bent of niet. De app gebruikt daarvoor een bepaalde vorm van bluetooth, Bluetooth Low Energy (lage energie-bluetooth). Hoe sterker het signaal, hoe dichterbij je bent. Als je een melding krijgt dat je risico loopt, was je zeker meer dan 15 minuten dicht in de buurt van iemand die later besmet bleek te zijn.
[2] https://coronamelder.nl/nl/faq/5-hoe-meet-coronamelder-de-afstand/
[3] https://coronamelder.nl/nl/faq/17-hoe-betrouwbaar-is-een-melding/
Uit [3]:
Hoe betrouwbaar is een melding?
Uit de resultaten van de veldtest, waarin de technische werking van de corona-app is getest, bleek dat bij ontmoetingen die langer dan 15 minuten duurden:
Van alle test-meldingen tijdens de veldtest, ging 60% naar mensen die meer dan 1,5 meter van elkaar waren. Dit hoge aantal komt doordat ook relatief veel mensen van de testgroep (80%) meer dan 1,5 meter van elkaar waren. Van deze mensen die een melding kregen, waren de meesten binnen 3 meter. En het ging altijd om een ontmoeting van langer dan 15 minuten.
Wat men in deze pagina "vergeet" te noemen, is dat dit de betrouwbaarheid is van de "afstandsmeting" (die rooskleuriger wordt voorgesteld dan blijkt uit de veldtest), niet dat je daadwerkelijk besmet bent geraakt. Nb. nergens in de FAQ op coronamelder.nl staat "Hoe groot is de kans dat ik, na een app-melding, besmet ben geraak?" (Logisch, dan zouden de meeste app-gebruikers meteen afhaken).Uit de resultaten van de veldtest, waarin de technische werking van de corona-app is getest, bleek dat bij ontmoetingen die langer dan 15 minuten duurden:
- van de deelnemers binnen 1,5 meter:
- ongeveer 75% een melding kreeg
- ongeveer 25% geen melding kreeg
- van de deelnemers verder dan 1,5 meter:
- ongeveer 75% geen melding kreeg
- ongeveer 25% een melding kreeg (de meesten daarvan waren binnen 3 meter)
- ongeveer 75% een melding kreeg
- ongeveer 25% geen melding kreeg
- van de deelnemers verder dan 1,5 meter:
- ongeveer 75% geen melding kreeg
- ongeveer 25% een melding kreeg (de meesten daarvan waren binnen 3 meter)
Van alle test-meldingen tijdens de veldtest, ging 60% naar mensen die meer dan 1,5 meter van elkaar waren. Dit hoge aantal komt doordat ook relatief veel mensen van de testgroep (80%) meer dan 1,5 meter van elkaar waren. Van deze mensen die een melding kregen, waren de meesten binnen 3 meter. En het ging altijd om een ontmoeting van langer dan 15 minuten.
Door Bitje-scheef: Je een keer extra laten testen is in mijn ogen geen probleem en vangt een aantal onnauwkeurigheden af (weliswaar klein).
Goed voor de app-gebruikers is dat zij zich, sinds deze week, meteen na een app-melding kunnen laten testen. Sinds deze week, want aanvankelijk dacht VWS dat Ron Roozendaal verstand van zaken had toen hij op 29 oktober schatte dat er ca. 10.000 mensen per dag door hun app gewaarschuwd zouden worden [4]: dat zou veel te veel zijn voor de GGD'en om erbij te hebben (vooral omdat minder dan 10% daarvan positief test).Echter, in week 49 t/m 02 waren dat gemiddeld slechts 1.302 mensen per dag (waarvan gemiddeld 103 per dag positief).
[4] https://nos.nl/artikel/2354277-coronamelder-10-000-meldingen-per-dag-ook-op-meer-dan-anderhalve-meter.html
Conclusie
Linksom of rechtsom zijn er zeer veel false positives (slecht voor het vertrouwen in de app) en extreem veel false negatives - zowel veroorzaakt door de onbetrouwbare BLE afstandmeting, als door de lage adoptie, als doordat slechts ca. de helft van de besmettelijke app-gebruikers data uploadt (zie mijn eerstvolgende bijdrage, die ik binnenkort hoop te posten, voor een toelichting op dat laatste aspect).
Ik heb vanalles geprobeerd (x4, x2, x1 voor de kolommen, interpoleren naar 1,5m etc.) maar kwam met deze cijfers nooit op 73%/73% voor sensitiviteit en specificiteit. Of VWS dat resultaat er eerlijk uit heeft kunnen persen, weet ik niet (maar dat geloof ik niet, dit waren de minimaal wenselijke getallen - die zich makkelijk naar de veelgenoemde 75% laten afronden, zoals in [3]; weer een leugentje "om bestwil"?). Dit is precies wat Anoniem in https://security.nl/posting/688568 schreef: "er zijn leugens, grotere leugens en statistiek".
Met de getallen uit tabel 5 kom ik op:
Sensitiviteit = 586 / (586 + 414) = 58,6%
Specificiteit = 671 / (671 + 329) = 67,1%
Door te gevoeligheidsgrens te variëren kun je de sensitiviteit verhogen - ten koste van de specificiteit en vice versa. En misschiem heb ik ongelijk en kun je die 73%/73% wel uit deze getallen optimaliseren, maar dan zul je zien dat dit zo wiebelig is dat er in de praktijk en/of bij een volgende veldtest iets heel anders uitkomt.
Dan trek je je conclusies op basis van alleen de afstand. Met de getallen uit tabel 5 kom ik op:
Sensitiviteit = 586 / (586 + 414) = 58,6%
Specificiteit = 671 / (671 + 329) = 67,1%
Door te gevoeligheidsgrens te variëren kun je de sensitiviteit verhogen - ten koste van de specificiteit en vice versa. En misschiem heb ik ongelijk en kun je die 73%/73% wel uit deze getallen optimaliseren, maar dan zul je zien dat dit zo wiebelig is dat er in de praktijk en/of bij een volgende veldtest iets heel anders uitkomt.
Maar de tijdsduur doet ook mee. Het gaat niet om afstand, maar om afstand (op basis van attenuation) én tijdsduur,.
Dit verhoogt de betrouwbaarheid van de app vergeleken bij resultaten op basis van alleen maar de afstand.
Zie pagina 9 van https://www.tweedekamer.nl/downloads/document?id=5ca0984a-bae9-4282-8e04-d2ee481b5bc0&title=COVID-19%20Notificatie%20APP.pdf
De wegingsfactoren en drempelwaarde zijn in dit geval:*
– Attenuations < 63 dB krijgen score 4; tussen 64 – 73 dB score 2; en > 74 dB score 1
– Durations > 15 minuten krijgen score 4; tussen 10 – 15 minuten score 2; en < 10 minuten score 1
– Als het product van de AttenuationScore * DurationScore >= 8 volgt een notificatie[/b]; als < 8 volgt géén notificatie
– Attenuations < 63 dB krijgen score 4; tussen 64 – 73 dB score 2; en > 74 dB score 1
– Durations > 15 minuten krijgen score 4; tussen 10 – 15 minuten score 2; en < 10 minuten score 1
– Als het product van de AttenuationScore * DurationScore >= 8 volgt een notificatie[/b]; als < 8 volgt géén notificatie
Geen leugens dus, maar selectief (gebrekkig) gelezen door iemand met een bril op van "dit zouden leugens moeten zijn".
Door Anoniem:
Maar de tijdsduur doet ook mee. Het gaat niet om afstand, maar om afstand (op basis van attenuation) én tijdsduur,.
Dit verhoogt de betrouwbaarheid van de app vergeleken bij resultaten op basis van alleen maar de afstand.
Tijd en afstand zijn twee natuurkundige begrippen die totaal losstaan van elkaar (relativiteitstheorie buiten beschouwing latend).Ik heb vanalles geprobeerd (x4, x2, x1 voor de kolommen, interpoleren naar 1,5m etc.) maar kwam met deze cijfers nooit op 73%/73% voor sensitiviteit en specificiteit.
[...]
Door te gevoeligheidsgrens te variëren kun je de sensitiviteit verhogen - ten koste van de specificiteit en vice versa. En misschiem heb ik ongelijk en kun je die 73%/73% wel uit deze getallen optimaliseren, maar dan zul je zien dat dit zo wiebelig is dat er in de praktijk en/of bij een volgende veldtest iets heel anders uitkomt.
Dan trek je je conclusies op basis van alleen de afstand. [...]
Door te gevoeligheidsgrens te variëren kun je de sensitiviteit verhogen - ten koste van de specificiteit en vice versa. En misschiem heb ik ongelijk en kun je die 73%/73% wel uit deze getallen optimaliseren, maar dan zul je zien dat dit zo wiebelig is dat er in de praktijk en/of bij een volgende veldtest iets heel anders uitkomt.
Maar de tijdsduur doet ook mee. Het gaat niet om afstand, maar om afstand (op basis van attenuation) én tijdsduur,.
Dit verhoogt de betrouwbaarheid van de app vergeleken bij resultaten op basis van alleen maar de afstand.
Wel kun je, door langer te meten, het aantal false positives (t.g.v. korte ontmoetingen, alhoewel je ook dan besmet kunt raken) verlagen, dus de specificiteit verhogen.
Door langer te meten worden ontvangen BLE signalen niet sterker. Het aantal false negatives gaat dus niet omlaag.
Je kunt het aantal false negatives waarschijnlijk wel wat verlagen door met x4, x2 en x1 te spelen. Dat heb ik geprobeerd, maar nergens mee haalde ik een sensitiviteit van 73% (bij acceptabele specificiteit).
Laat maar zien hoe je, op basis van de getallen in de heatmap, op die 73%/73% uit kunt komen (maar dan nog is dat statistisch tweaken met niet reproduceerbare resultaten in de praktijk). Ik zal mijn excuses maken voor dit ene aspectje als jij dit kunt laten zien. Ik ben benieuw...
Waarom de effectiviteit van Corona-apps véél sneller afneemt bij minder gebruikers
De effectiviteit van CoronaMelder gaat sowieso kwadratisch omlaag met het aantal Nederlanders dat rondloopt met die app actief (de adoptie). Immers, om een gezond persoon via diens app voor een mogelijke besmetting te kunnen waarschuwen, moeten zowel de besmettelijke als de gezonde persoon een werkende app hebben tijdens hun ontmoeting.
LET OP: de werkelijke maximale effectiviteit is echter nóg lager omdat niet elke besmettelijke persoon zich laat testen (bijv. omdat deze nauwelijks of geen symptomen krijgt, geen wattenstaafjes in neus/keel wil of bang is dat diens persoonsgegevens op straat komen te liggen), én omdat niet iedereen die positief getest wordt en CoronaMelder gebruikt, daadwerkelijk app-gegevens uploadt. Dat licht ik hieronder toe.
Stel 40% van de Nederlandse bevolking heeft een smartphone met een werkende CoronaMelder, en stel dat de helft van de besmettelijke personen met app zich laat testen en data uit diens app uploadt (die 40% klopt niet voor Nederland en dient als voorbeeld). Als elk van 5 willekeurige gezonde personen (G1 t/m G5) één van 5 willekeurige besmettelijke personen (B1 t/m B5) ontmoet, zo lang en zo dichtbij elkaar dat CoronaMelder later de besmette persoon kan waarschuwen, kunnen we aan de hand van een plaatje laten zien hoe groot de kans is dat iemand gewaarschuwd wordt. Bij een gelijkmatige verdeling van de apps over de bevolking zullen 2 van 5 gezonde en 2 van 5 besmettelijke mensen de app hebben:
De volgende tabel begint steeds met een situatienummer. Als gezond persoon G1 de besmettelijke persoon B1 ontmoet, noteren we dat als "G1-B1" etc. App-waarschuwing, ja: '+'; nee: '-'. Daarna tussen () een verwijzing naar de tekst onder de tabel.
(1) Minstens één van beiden heeft geen app
(2) Beiden hebben de app maar de besmettelijke persoon uploadt niet
(3) Beiden hebben de app en de besmettelijke persoon uploadt wel
Gevolg: in slechts 2 van de 25 situaties, waarbij een gezond persoon G door een besmettelijk persoon B wordt besmet, wordt G door CoronaMelder gewaarschuwd. Dus in 8 van de 100 situaties = 8%.
Dit kun je ook uitrekenen door 40% (adoptie, aantal Nederlanders met app) te nemen van het percentage positief geteste Nederlanders dat app-data uploadt, 20% in dit voorbeeld; 40% van 20% (0,4 x 0,2) = 8%.
Met andere woorden, van de verwachte 16% (uit de eerste tabel in deze bijdrage) blijft nog maar 8% over doordat niet elke B met app uploadt.
Praktijkcijfers van CoronaMelder
Uit [1] en [2] weten we hoeveel mensen hebben geupload en hoeveel mensen positief zijn getest, dus weten we welk percentage van de positief geteste mensen app-data uploadt: over week 49 t/m 02 was dit 13,4%.
Uit [3]:
[1] https://github.com/minvws/nl-covid19-notification-app-statistics/blob/main/statistics/ggd_positive_test_authorisations.csv
[2] https://www.rivm.nl/coronavirus-covid-19/actueel/wekelijkse-update-epidemiologische-situatie-covid-19-in-nederland
[3] https://www.rivm.nl/gedragsonderzoek/maatregelen-welbevinden
Ik verwacht niet dat alle app-gewaarschuwden zich zullen laten testen, maar wel meer dan bovengenoemde 58% tot 66%. Als ik dit op 82% schat kom ik er mooi op uit dat (82% van 13,4% =) ca. 11% van alle besmettelijke app-gebruikers data uploadt (ja, ook ik maak me eraan schuldig dat ik naar ronde getallen toe redeneer, maar met 82% zal ik eerder aan de hoge dan aan de lage kant zitten - en hierbij heb ik niet eens meegenomen dat app-gebruikers met milde symptomen zich mogelijk niet zullen laten testen als zij geen app-melding hebben gekregen).
Maximaal haalbare effectiviteit van CoronaMelder bij 22% adoptie en de helft die uploadt
Als 22% van de Nederlanders CoronaMelder gebruikt en 11% van de positief geteste mensen app-data uploadt, is de maximaal haalbare effectiviteit van CoronaMelder 22% van 11% = 2,42%.
Die maximale procentuele effectiviteit van CoronaMelder van 2,42% haal je echter alleen onder alle volgende voorwaarden:
1) Indien een besmettelijke app-gebruiker uploadt en de gezonde app-gebruiker door die eerste persoon besmet is geraakt, moet CoronaMelder in alle gevallen waarschuwen - ongeacht de afstand tot elkaar, de oriëntatie en plaats van de smartphones, en de tijdsduur van het contact (dit haal je al niet, want je kunt binnen 15 minuten besmet raken - maar zie ook mijn vorige bijdrage hierboven);
2) Minstens 82% van de door hun app gewaarschuwde mensen moet zich laten testen;
3) Minstens 13,4% van de positief geteste app-gebruikers moet daadwerkelijk app-data uploaden;
4) Het aantal actieve app-gebruikers moet niet lager worden dan 22% (bijv. t.g.v. het grote aantal waarschuwingen zonder besmetting [*]);
Voor het optimaal bestrijden van de epidemie door CoronaMelder gelden de volgende aanvullende voorwaarden:
5) Alle besmette app-gebruikers moeten door hun app zijn gewaarschuwd voordat zij zelf besmettelijk worden.
6) Alle door hun app gewaarschuwde mensen moeten daadwerkelijk in quarantaine gaan en blijven totdat zij niet besmettelijk meer zijn.
[*] De Duitse Corona-Warn-App toont sinds kort statistieken. Onze oosterburen lijken nu pas te gaan inzien [4] dat van de 2,3 miljoen positief geteste Duitsers bijna 230.000 data hebben geüpload, dus slechts 10%! En dus begint men nu ook in te zien [5] dat een groen scherm met "Niedriges Risiko" tot een vals gevoel van veiligheid leidt, en zo'n app dus netto averechts kan werken.
Ook in Japan brokkelt het vertrouwen in hun "COCOA" app (eveneens gebaseerd op de Google + Apple notification API) af. Op 380,000 positief getestten hebben slechts 9.736 mensen data geüpload, minder dan 3%. Ook daar (net als in Duitsland) beginnen mensen te roepen dat de app veel te privacy-vriendelijk is.
[4] https://www.rtl.de/cms/desaster-corona-warn-app-nur-jede-zehnte-infektion-wird-gemeldet-4696231.html
[5] https://taz.de/Unverstaendliche-Corona-Warn-App/!5735104/
[6] https://www.japantimes.co.jp/news/2021/02/01/national/science-health/cocoa-tracing-troubles/
Onderzoek uit de tweede helft van 2020 door Oxford university
Interessant vind ik dat [6] verwijst naar nieuw onderzoek en een nieuwe publicatie van de bovenaan deze pagina genoemde groep van de Oxford university. In [7] is vaak sprake van een op BLE gebaseerde app, en wordt voor de wetenschap erachter verwezen naar [8]. Vanuit [8] wordt verwezen naar naar een (nog niet peer-reviewed) publicatie in [9].
[7] https://www.coronavirus-fraser-group.org/mobile-app
[8] https://www.ox.ac.uk/news/2020-09-03-new-research-shows-tracing-apps-can-save-lives-all-levels-uptake
[9] https://www.medrxiv.org/content/10.1101/2020.08.29.20184135v1.full-text
Uit [9] (vet en onderstrepen toegevoegd door mij):
De effectiviteit van CoronaMelder gaat sowieso kwadratisch omlaag met het aantal Nederlanders dat rondloopt met die app actief (de adoptie). Immers, om een gezond persoon via diens app voor een mogelijke besmetting te kunnen waarschuwen, moeten zowel de besmettelijke als de gezonde persoon een werkende app hebben tijdens hun ontmoeting.
Adoptie Max. effectiviteit
100% 100%
80% 64%
60% 36%
40% 16%
20% 4%
100% 100%
80% 64%
60% 36%
40% 16%
20% 4%
LET OP: de werkelijke maximale effectiviteit is echter nóg lager omdat niet elke besmettelijke persoon zich laat testen (bijv. omdat deze nauwelijks of geen symptomen krijgt, geen wattenstaafjes in neus/keel wil of bang is dat diens persoonsgegevens op straat komen te liggen), én omdat niet iedereen die positief getest wordt en CoronaMelder gebruikt, daadwerkelijk app-gegevens uploadt. Dat licht ik hieronder toe.
Stel 40% van de Nederlandse bevolking heeft een smartphone met een werkende CoronaMelder, en stel dat de helft van de besmettelijke personen met app zich laat testen en data uit diens app uploadt (die 40% klopt niet voor Nederland en dient als voorbeeld). Als elk van 5 willekeurige gezonde personen (G1 t/m G5) één van 5 willekeurige besmettelijke personen (B1 t/m B5) ontmoet, zo lang en zo dichtbij elkaar dat CoronaMelder later de besmette persoon kan waarschuwen, kunnen we aan de hand van een plaatje laten zien hoe groot de kans is dat iemand gewaarschuwd wordt. Bij een gelijkmatige verdeling van de apps over de bevolking zullen 2 van 5 gezonde en 2 van 5 besmettelijke mensen de app hebben:
G1 G2 G3 G4 G5
Gezond O O O O O
/|\ /|\[App] /|\ /|\[App] /|\
/ \ / \ / \ / \ / \
----------------------------------------------------------------------------------------
* * * * * * * * * * * * * * *
* * * * * * * * * * * * * * *
Besmet- *** O *** *** O *** *** O *** *** O *** *** O ***
telijk /|\[App] /|\ /|\ /|\ /|\[App+upload]
/ \ / \ / \ / \ / \
B1 B2 B3 B4 B5
Gezond O O O O O
/|\ /|\[App] /|\ /|\[App] /|\
/ \ / \ / \ / \ / \
----------------------------------------------------------------------------------------
* * * * * * * * * * * * * * *
* * * * * * * * * * * * * * *
Besmet- *** O *** *** O *** *** O *** *** O *** *** O ***
telijk /|\[App] /|\ /|\ /|\ /|\[App+upload]
/ \ / \ / \ / \ / \
B1 B2 B3 B4 B5
De volgende tabel begint steeds met een situatienummer. Als gezond persoon G1 de besmettelijke persoon B1 ontmoet, noteren we dat als "G1-B1" etc. App-waarschuwing, ja: '+'; nee: '-'. Daarna tussen () een verwijzing naar de tekst onder de tabel.
01 G1-B1 - (1) 06 G1-B2 - (1) 11 G1-B3 - (1) 16 G1-B4 - (1) 21 G1-B5 - (1)
02 G2-B1 - (2) 07 G2-B2 - (1) 12 G2-B3 - (1) 17 G2-B4 - (1) 22 G2-B5 + (3)
03 G3-B1 - (1) 08 G3-B2 - (1) 13 G3-B3 - (1) 18 G3-B4 - (1) 23 G3-B5 - (1)
04 G4-B1 - (2) 09 G4-B2 - (1) 14 G4-B3 - (1) 19 G4-B4 - (1) 24 G4-B5 + (3)
05 G5-B1 - (1) 10 G5-B2 - (1) 15 G5-B3 - (1) 20 G5-B4 - (1) 25 G5-B5 - (1)
02 G2-B1 - (2) 07 G2-B2 - (1) 12 G2-B3 - (1) 17 G2-B4 - (1) 22 G2-B5 + (3)
03 G3-B1 - (1) 08 G3-B2 - (1) 13 G3-B3 - (1) 18 G3-B4 - (1) 23 G3-B5 - (1)
04 G4-B1 - (2) 09 G4-B2 - (1) 14 G4-B3 - (1) 19 G4-B4 - (1) 24 G4-B5 + (3)
05 G5-B1 - (1) 10 G5-B2 - (1) 15 G5-B3 - (1) 20 G5-B4 - (1) 25 G5-B5 - (1)
(2) Beiden hebben de app maar de besmettelijke persoon uploadt niet
(3) Beiden hebben de app en de besmettelijke persoon uploadt wel
Gevolg: in slechts 2 van de 25 situaties, waarbij een gezond persoon G door een besmettelijk persoon B wordt besmet, wordt G door CoronaMelder gewaarschuwd. Dus in 8 van de 100 situaties = 8%.
Dit kun je ook uitrekenen door 40% (adoptie, aantal Nederlanders met app) te nemen van het percentage positief geteste Nederlanders dat app-data uploadt, 20% in dit voorbeeld; 40% van 20% (0,4 x 0,2) = 8%.
Met andere woorden, van de verwachte 16% (uit de eerste tabel in deze bijdrage) blijft nog maar 8% over doordat niet elke B met app uploadt.
Praktijkcijfers van CoronaMelder
Uit [1] en [2] weten we hoeveel mensen hebben geupload en hoeveel mensen positief zijn getest, dus weten we welk percentage van de positief geteste mensen app-data uploadt: over week 49 t/m 02 was dit 13,4%.
Uit [3]:
Resultaten onderzoek gedragsregels en welbevinden
Wijzigingsdatum 18-01-2021 | 11:18
[...]
Resultaten 9e ronde
[...]66 % van de mensen met nieuwe klachten (die niet worden toegeschreven aan een andere aandoening) heeft zich in de 7 weken voorafgaand aan het invullen van de vragenlijst laten testen (onder deelnemers die aan alle rondes hebben meegedaan was dit 58% in ronde 8).
[...]
Wijzigingsdatum 18-01-2021 | 11:18
[...]
Resultaten 9e ronde
[...]66 % van de mensen met nieuwe klachten (die niet worden toegeschreven aan een andere aandoening) heeft zich in de 7 weken voorafgaand aan het invullen van de vragenlijst laten testen (onder deelnemers die aan alle rondes hebben meegedaan was dit 58% in ronde 8).
[...]
[1] https://github.com/minvws/nl-covid19-notification-app-statistics/blob/main/statistics/ggd_positive_test_authorisations.csv
[2] https://www.rivm.nl/coronavirus-covid-19/actueel/wekelijkse-update-epidemiologische-situatie-covid-19-in-nederland
[3] https://www.rivm.nl/gedragsonderzoek/maatregelen-welbevinden
Ik verwacht niet dat alle app-gewaarschuwden zich zullen laten testen, maar wel meer dan bovengenoemde 58% tot 66%. Als ik dit op 82% schat kom ik er mooi op uit dat (82% van 13,4% =) ca. 11% van alle besmettelijke app-gebruikers data uploadt (ja, ook ik maak me eraan schuldig dat ik naar ronde getallen toe redeneer, maar met 82% zal ik eerder aan de hoge dan aan de lage kant zitten - en hierbij heb ik niet eens meegenomen dat app-gebruikers met milde symptomen zich mogelijk niet zullen laten testen als zij geen app-melding hebben gekregen).
Maximaal haalbare effectiviteit van CoronaMelder bij 22% adoptie en de helft die uploadt
Als 22% van de Nederlanders CoronaMelder gebruikt en 11% van de positief geteste mensen app-data uploadt, is de maximaal haalbare effectiviteit van CoronaMelder 22% van 11% = 2,42%.
Die maximale procentuele effectiviteit van CoronaMelder van 2,42% haal je echter alleen onder alle volgende voorwaarden:
1) Indien een besmettelijke app-gebruiker uploadt en de gezonde app-gebruiker door die eerste persoon besmet is geraakt, moet CoronaMelder in alle gevallen waarschuwen - ongeacht de afstand tot elkaar, de oriëntatie en plaats van de smartphones, en de tijdsduur van het contact (dit haal je al niet, want je kunt binnen 15 minuten besmet raken - maar zie ook mijn vorige bijdrage hierboven);
2) Minstens 82% van de door hun app gewaarschuwde mensen moet zich laten testen;
3) Minstens 13,4% van de positief geteste app-gebruikers moet daadwerkelijk app-data uploaden;
4) Het aantal actieve app-gebruikers moet niet lager worden dan 22% (bijv. t.g.v. het grote aantal waarschuwingen zonder besmetting [*]);
Voor het optimaal bestrijden van de epidemie door CoronaMelder gelden de volgende aanvullende voorwaarden:
5) Alle besmette app-gebruikers moeten door hun app zijn gewaarschuwd voordat zij zelf besmettelijk worden.
6) Alle door hun app gewaarschuwde mensen moeten daadwerkelijk in quarantaine gaan en blijven totdat zij niet besmettelijk meer zijn.
[*] De Duitse Corona-Warn-App toont sinds kort statistieken. Onze oosterburen lijken nu pas te gaan inzien [4] dat van de 2,3 miljoen positief geteste Duitsers bijna 230.000 data hebben geüpload, dus slechts 10%! En dus begint men nu ook in te zien [5] dat een groen scherm met "Niedriges Risiko" tot een vals gevoel van veiligheid leidt, en zo'n app dus netto averechts kan werken.
Ook in Japan brokkelt het vertrouwen in hun "COCOA" app (eveneens gebaseerd op de Google + Apple notification API) af. Op 380,000 positief getestten hebben slechts 9.736 mensen data geüpload, minder dan 3%. Ook daar (net als in Duitsland) beginnen mensen te roepen dat de app veel te privacy-vriendelijk is.
[4] https://www.rtl.de/cms/desaster-corona-warn-app-nur-jede-zehnte-infektion-wird-gemeldet-4696231.html
[5] https://taz.de/Unverstaendliche-Corona-Warn-App/!5735104/
[6] https://www.japantimes.co.jp/news/2021/02/01/national/science-health/cocoa-tracing-troubles/
Onderzoek uit de tweede helft van 2020 door Oxford university
Interessant vind ik dat [6] verwijst naar nieuw onderzoek en een nieuwe publicatie van de bovenaan deze pagina genoemde groep van de Oxford university. In [7] is vaak sprake van een op BLE gebaseerde app, en wordt voor de wetenschap erachter verwezen naar [8]. Vanuit [8] wordt verwezen naar naar een (nog niet peer-reviewed) publicatie in [9].
[7] https://www.coronavirus-fraser-group.org/mobile-app
[8] https://www.ox.ac.uk/news/2020-09-03-new-research-shows-tracing-apps-can-save-lives-all-levels-uptake
[9] https://www.medrxiv.org/content/10.1101/2020.08.29.20184135v1.full-text
Uit [9] (vet en onderstrepen toegevoegd door mij):
[...]
Smartphone apps may approximate pathogen exposure risk through the use of geolocation technologies such as GPS, and/or via proximity-based approaches using localized Radio Frequency (RF) transmissions like Bluetooth. Location-based approaches attempt to compare the places a user has been with a database of high-risk locations or overlaps with infected people (6), while proximity-based approaches directly detect nearby smartphones that can later be checked for “too close for too long” exposure to infected people (7).
[...]
There are many variables to consider when characterizing the behavior of any system of this type. Technology-dependent parameters, such as those needed to convert Bluetooth signal strength readings to proximity (13) (14), vary from device to device and require labor-intensive calibration. They will not be discussed in this paper. Here we seek to explore the general conditions and public health backdrop in which an ENS deployment may exist, and the policy characteristics that can accompany it.
[...]
M.a.w. ook in deze studie worden de problemen van de afstandmeting tussen smartphones middels BLE buiten beschouwing gelaten, en zo te zien ook het feit dat niet elke besmettelijke app-gebruiker app-data uploadt. Ook lijken de onderzoekers er vanuit te gaan dat elke app-gewaarschuwde in quarantaine gaat en lang genoeg blijft. Hoe deze wetenschappers dan konden concluderen dat 15% adoptie al echt zin zou hebben, is mij een raadsel. Ondertussen weten we uit de praktijk uit alle landen met dit soort apps dat dit compleet flauwekul is.Smartphone apps may approximate pathogen exposure risk through the use of geolocation technologies such as GPS, and/or via proximity-based approaches using localized Radio Frequency (RF) transmissions like Bluetooth. Location-based approaches attempt to compare the places a user has been with a database of high-risk locations or overlaps with infected people (6), while proximity-based approaches directly detect nearby smartphones that can later be checked for “too close for too long” exposure to infected people (7).
[...]
There are many variables to consider when characterizing the behavior of any system of this type. Technology-dependent parameters, such as those needed to convert Bluetooth signal strength readings to proximity (13) (14), vary from device to device and require labor-intensive calibration. They will not be discussed in this paper. Here we seek to explore the general conditions and public health backdrop in which an ENS deployment may exist, and the policy characteristics that can accompany it.
[...]
Door Erik van Straten:
Wel kun je, door langer te meten, het aantal false positives (t.g.v. korte ontmoetingen, alhoewel je ook dan besmet kunt raken) verlagen, dus de specificiteit verhogen.
Door langer te meten worden ontvangen BLE signalen niet sterker. Het aantal false negatives gaat dus niet omlaag.
Je kunt het aantal false negatives waarschijnlijk wel wat verlagen door met x4, x2 en x1 te spelen. Dat heb ik geprobeerd, maar nergens mee haalde ik een sensitiviteit van 73% (bij acceptabele specificiteit).
Laat maar zien hoe je, op basis van de getallen in de heatmap, op die 73%/73% uit kunt komen (maar dan nog is dat statistisch tweaken met niet reproduceerbare resultaten in de praktijk). Ik zal mijn excuses maken voor dit ene aspectje als jij dit kunt laten zien. Ik ben benieuw...
Door Anoniem:
Maar de tijdsduur doet ook mee. Het gaat niet om afstand, maar om afstand (op basis van attenuation) én tijdsduur,.
Dit verhoogt de betrouwbaarheid van de app vergeleken bij resultaten op basis van alleen maar de afstand.
Tijd en afstand zijn twee natuurkundige begrippen die totaal losstaan van elkaar (relativiteitstheorie buiten beschouwing latend).Ik heb vanalles geprobeerd (x4, x2, x1 voor de kolommen, interpoleren naar 1,5m etc.) maar kwam met deze cijfers nooit op 73%/73% voor sensitiviteit en specificiteit.
[...]
Door te gevoeligheidsgrens te variëren kun je de sensitiviteit verhogen - ten koste van de specificiteit en vice versa. En misschiem heb ik ongelijk en kun je die 73%/73% wel uit deze getallen optimaliseren, maar dan zul je zien dat dit zo wiebelig is dat er in de praktijk en/of bij een volgende veldtest iets heel anders uitkomt.
Dan trek je je conclusies op basis van alleen de afstand. [...]
Door te gevoeligheidsgrens te variëren kun je de sensitiviteit verhogen - ten koste van de specificiteit en vice versa. En misschiem heb ik ongelijk en kun je die 73%/73% wel uit deze getallen optimaliseren, maar dan zul je zien dat dit zo wiebelig is dat er in de praktijk en/of bij een volgende veldtest iets heel anders uitkomt.
Maar de tijdsduur doet ook mee. Het gaat niet om afstand, maar om afstand (op basis van attenuation) én tijdsduur,.
Dit verhoogt de betrouwbaarheid van de app vergeleken bij resultaten op basis van alleen maar de afstand.
Wel kun je, door langer te meten, het aantal false positives (t.g.v. korte ontmoetingen, alhoewel je ook dan besmet kunt raken) verlagen, dus de specificiteit verhogen.
Door langer te meten worden ontvangen BLE signalen niet sterker. Het aantal false negatives gaat dus niet omlaag.
Je kunt het aantal false negatives waarschijnlijk wel wat verlagen door met x4, x2 en x1 te spelen. Dat heb ik geprobeerd, maar nergens mee haalde ik een sensitiviteit van 73% (bij acceptabele specificiteit).
Laat maar zien hoe je, op basis van de getallen in de heatmap, op die 73%/73% uit kunt komen (maar dan nog is dat statistisch tweaken met niet reproduceerbare resultaten in de praktijk). Ik zal mijn excuses maken voor dit ene aspectje als jij dit kunt laten zien. Ik ben benieuw...
Okee, misschien heb ik het "lek" boven water.
Op pagina 9 staat:
– Attenuations < 63 dB krijgen score 4; tussen 64 – 73 dB score 2; en > 74 dB score 1
Attenuation betekent verzwakking.Dus naar mate de attenuation hoger is, is er sprake van minder signaal en dus een grotere afstand.
En grotere afstand betekent minder risico op besmetting. Dus dat attenuation > 74 de laagste score krijgt, klopt.
Maar kijk nu eens naar de resultatentabel (heatmap) op pagina 7.
De kolom 74-100 (aannemelijk lijkt mij dat het hier gaat over een range van attenuation in dB) zou de kolom moeten zijn die slaat op de gevallen met de grootste afstand tussen 2 smartphones.
Maar wat schetst mijn verbazing? Naar mate de afstand die wordt weergegeven in de kolom geheel links kleiner is,
loopt het aantal gevallen in kolom 74-100 steeds verder op!!!
Terwijl je juist zou verwachten dat het aantal gevallen dat in de categorie "74-100" valt, op zou moeten lopen naar mate de afstand groter is!
Het lijkt er dus sterk op dat men in die tabel een basale fout heeft gemaakt, zodat men tot een behoorlijk verkeerde conclusie kwam. Zo'n fout is wel enigszins begrijpelijk, want men moet oppassen als men het over verzwakking heeft.
Een grotere verzwakking leidt namelijk naar een kleinere signaalwarde.
Dat druist een beetje tegen onze inuïtie in wanneer we niet goed genoeg opletten. En dan is zo'n fout snel gemaakt.
Wat is jou kritische en weldoordachte kijk hierop?
05-02-2021, 23:31 door
Erik van Straten
Door Anoniem: Op pagina 9 staat:
Dus naar mate de attenuation hoger is, is er sprake van minder signaal en dus een grotere afstand.
Dat klopt alleen als er geen verstorende elementen zijn, met name reflecterende oppervlakken en dempende objecten.– Attenuations < 63 dB krijgen score 4; tussen 64 – 73 dB score 2; en > 74 dB score 1
Attenuation betekent verzwakking.Dus naar mate de attenuation hoger is, is er sprake van minder signaal en dus een grotere afstand.
Door Anoniem: En grotere afstand betekent minder risico op besmetting. Dus dat attenuation > 74 de laagste score krijgt, klopt.
In de basis wel, maar de radio-frequente wereld is niet zo simpel.Door Anoniem: Maar kijk nu eens naar de resultatentabel (heatmap) op pagina 7.
De kolom 74-100 (aannemelijk lijkt mij dat het hier gaat over een range van attenuation in dB) zou de kolom moeten zijn die slaat op de gevallen met de grootste afstand tussen 2 smartphones.
Maar wat schetst mijn verbazing? Naar mate de afstand die wordt weergegeven in de kolom geheel links kleiner is,
loopt het aantal gevallen in kolom 74-100 steeds verder op!!!
Terwijl je juist zou verwachten dat het aantal gevallen dat in de categorie "74-100" valt, op zou moeten lopen naar mate de afstand groter is!
Nee, dat verwacht ik niet. Wat je ziet is dat getallen in de cellen in kolom 74-100 verticaal iets hoger liggen dan vergelijkbare getallen in kolom 64-73.De kolom 74-100 (aannemelijk lijkt mij dat het hier gaat over een range van attenuation in dB) zou de kolom moeten zijn die slaat op de gevallen met de grootste afstand tussen 2 smartphones.
Maar wat schetst mijn verbazing? Naar mate de afstand die wordt weergegeven in de kolom geheel links kleiner is,
loopt het aantal gevallen in kolom 74-100 steeds verder op!!!
Terwijl je juist zou verwachten dat het aantal gevallen dat in de categorie "74-100" valt, op zou moeten lopen naar mate de afstand groter is!
Anders gezegd: de getallen in de kolommen 34-51, 52-63 en 64-74 lopen op van 1 t/m 6 meter (de verzwakking neemt toe met de afstand). Precies hetzelfde geldt voor kolom 75-100, met uitzondering van de onderste cel: tussen 51 smartphone-paren werd, ondanks dat deze zich op 1m van elkaar bevonden, toch een verzwakking van meer dan 74 dB gemeten.
Omdat de kolommen 34-51 en 52-63 nauwelijks data bevatten hebben factoren daarop ook niet veel zin (daarom heb ik ze in mijn bijdrage een stuk hierboven bij kolom 64-74 geveegd). De bulk van de data zit nou eenmaal in de kolommen 64-73 en 74-100; mede omdat er ongeveer evenveel data in die kolommen zit, leek mij dat een zinvolle scheidingslijn.
Bij afstanden groter dan 6 meter ga je "anomaliën" zien t.g.v. reflecties. Ik vermoed dat de meeste van deze anomaliën gemeten zijn in de treincoupé (zie de foto rechtsbovenaan pagina 6 in het rapport uit Vught).
Deze bevindingen zijn vergelijkbaar met wat de Ierse wetenschappers Prof. Doug Leith en Dr. Stephen Farrell van het Trinity College Dublin publiceerden in "Measurement-Based Evaluation Of Google/Apple Exposure Notification API For Proximity Detection In A Light-Rail Tram", peer-reviewed in https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0239943. Veel meer resultaten van onderzoek uitgevoerd door hen vind je in https://down.dsg.cs.tcd.ie/tact/.
Als je niet door lange wetenschappelijke publicaties wilt ploegen, geven de sheets in https://down.dsg.cs.tcd.ie/tact/tact-pearg-pressie.pdf een m.i. mooie samenvatting het werk van Prof. Leith en Dr. Farrell op dit gebied.
In Duitsland werd het "light rail tram" onderzoek van Prof. Leith en Dr. Farrell beschimpt: hun Frauenhofer instituut zei dat de app betrouwbaar was en zo'n gerenommeerd instituut heeft heus wel goed gemeten. Maar als je naar de bovenste foto in https://www.iis.fraunhofer.de/en/ff/lv/lok/social-distancing-technologie/validation-of-social-distancing-apps.html kijkt, snapt iedereen die iets van RF weet dat je op deze manier niet betrouwbaar een treincoupé simuleert (chapeau voor de testers in Vught dat zij, onder meer, wel in een echte coupé gemeten hebben).
Overigens vind ik het jammer dat de heatmap in het rapport uit Vught niet een kwartslag is gedraaid. Horizontaal afstand en verticaal signaalverzwakking zou wellicht meer tot de verbeelding spreken (en het zou beter zijn geweest als er ook en vaak op 1,5m was getest), maar verder ga ik ervan uit dat de getallen in de heatmap gewoon kloppen. En nogmaals, langer of korter meten verandert niets aan signaalsterktes (of, zo je wilt, verzwakking).
RF is een complexe aangelegenheid. Prof. Leith en Dr. Farrell ondervonden dat het simpelweg draaien van een smartphone al 10-20dB verandering in RSSI (en dus de verzwakking) kan geven. Menselijke lichamen dempen BLE (en 2,4GHz WiFi) signalen sterker dan niet al te dikke muren, dus een telefoon in een kontzak vormt al een probleem. Die afstandmeting hoeft echter niet zo precies, 3m of minder is ook al redelijk. Maar ook dan krijg je veel false negatives die meteen slecht zijn voor de effectiviteit bij de bestrijding van de pandemie, en ook veel false positives - die niet meteen slecht zijn, maar wel zodra gebruikers het vertrouwen in dit soort apps verliezen (bij een eerstvolgende golf zal dat meer en meer gebeuren).
Kortom, de problemen bij het afstandmeten tussen smartphones middels BLE zijn fundamenteel en zo groot, dat pielen met vermenigvuldigingsfactoren en ingewikkelde filters onder bepaalde omstandigheden best een verbetering kan opleveren, maar onder andere omstandigheden juist een verslechtering. Ik geloof er dan ook niet in dat de GAEN API v2 veel zoden aan de dijk kan zetten (hooguit als van veel toesteltypes nauwkeuriger calibratiegegevens beschikbaar zijn). Het blijft kiezen tussen twee kwaden: false positives en false negatives.
Sneu dat zoveel mensen in deze valse beloftes zijn gaan geloven, maar ik vind het vooral schandalig dat mensen dit soort beloftes hebben gedaan - en dat wetenschappers uit Oxford van adoptiepercentages variërend van 14% tot 60+% roepen dat deze allemaal helpen en in hun reclamepraatjes suggereren dat deze gelden voor op BLE- gebaseerde apps - terwijl in hun laatste wetenschappelijke publicatie staat dat BLE afstandmeting veel te ingewikkeld (lees: onnauwkeurig) is om rekening mee te houden. Helaas komt het voor dat wetenschappers, zelfs uit Oxford, publiceren belangrijker vinden dan de waarheid schrijven.
Okee bedankt voor het antwoord " 23:31 Erik van Straten".
Dan had men misschien in de tekst naast de heatmap beter kunnen vermelden
Ik heb een zwaar vermoeden dat de oorzaak te maken heeft met de aanwezigheid van 1 of meer menselijke lichamen tussen beide smartphones tijdens een testcasus. Het menselijk lichaam bestaat voornamelijk uit water,
en water absorbeert behoorlijk goed frequenties in de 2,4GHz band die ondermeer ook door Bluetooth wordt gebruikt.
Dan had men misschien in de tekst naast de heatmap beter kunnen vermelden
Zwak signaal (>74 dB verzwakking) duidt op grotere afstand > 2-12m
in plaats van Zwak signaal (>74 dB verzwakking) duidt op grotere afstand > 3-12m[/b].
Want maar liefst 169 van de 306 testcasussen (55%!) bij een afstand van 2 meter kwamen in de 74-100 range terecht.Ik heb een zwaar vermoeden dat de oorzaak te maken heeft met de aanwezigheid van 1 of meer menselijke lichamen tussen beide smartphones tijdens een testcasus. Het menselijk lichaam bestaat voornamelijk uit water,
en water absorbeert behoorlijk goed frequenties in de 2,4GHz band die ondermeer ook door Bluetooth wordt gebruikt.
06-02-2021, 23:47 door
Erik van Straten
Door Anoniem: Ik heb een zwaar vermoeden dat de oorzaak te maken heeft met de aanwezigheid van 1 of meer menselijke lichamen tussen beide smartphones tijdens een testcasus. Het menselijk lichaam bestaat voornamelijk uit water, en water absorbeert behoorlijk goed frequenties in de 2,4GHz band die ondermeer ook door Bluetooth wordt gebruikt.
Dat heb ik al vaak geschreven: veel mensen lopen/staan met hun smartphone in hun kontzak, en dan zit er een lichaam tussen (met phone in kontzak kun je het beste je hoofd 180 graden draaien en zo gesprekken voeren of achteruit lopen; als dat lastig is geeft opzij kijken en lopen als een krab ook al verbetering ;-)Uit de pagina met Resultaten van het veldtest-rapport:
> Real-life metingen geven zwakker signaal dan laboratorium-metingen (ca. 10-15 dB)*
Vermoedelijk komt dat deels door de oriëntatie van smartphones, deels door dempende lichamen en deels door interferentie als gevolg van reflecties.Ik heb er nog verder over nagedacht: er ontbreekt m.i. een kolom in de heatmap (rechts van 74-100 dB): "geen signaal". Die zou de app-cijfers gunstiger kunnen maken, want in die groep verwacht je vooral mensen op grotere afstanden (het percentage false positives wordt dan lager, en dan zou je, via een iets andere instelling, de sensitiviteit wellicht iets kunnen verhogen). Echter aangezien er bij 51 paren op 1m afstand een demping van 74-100dB werd vastgesteld, verwacht ik ook in deze groep "geen signaal" besmettings-false negatives - zeker als men aanzienlijk langer binnen 2 à 3 meter van elkaar zit in een slecht geventileerde ruimte en/of in een metalen rijtuig.
Hoe dan ook is het probleem niet zozeer dat je niet nauwkeurig afstanden kunt meten, het is veel groter:
1a) Een lage verzwakking tot 63 dB (hoge signaalsterkte) wordt zelden gemeten: 46 van 1229 testcases (ca. 4%);
1b) Het in 14 van die 44 gevallen om 3 meter of meer gaat (bijna 1 op 3);
2a) Een gemiddelde verzwakking van 64-73dB in 495 van 1229 testcases werd vastgesteld (ca. 40%);
2b) Het in 152 van die 495 gevallen om 3 meter of meer gaat (iets meer dan 30%);
3a) De hoogste verzwakking van 74-100dB in 688 van 1229 testcases werd vastgesteld (ca. 56%);
3b) Het in 220 van die 688 gevallen om minder dan 3 meter gaat (bijna 1 op 3).
Er is dus absoluut geen sprake van afstandmeting, maar van statistiek hoe groot de kans is dat twee smartphones zich binnen enkele meters van elkaar bevinden!
Een probleem daarbij is dat als je de zwakste signalen negeert (meer dan de helft, 56% tijdens de veldtest), je contacten met smartphones in kontzakken zult missen. Als je ze meeneemt, klopt het volgende niet meer (uit het rapport van de veldtest):
> Muren, auto’s e.d. geven meetbare signaalverzwakking, voldoende om die casussen uit te filteren
Er bestaat voor BLE namelijk geen technologie waarmee je muren wel en vlees niet "uitfiltert" (laat staan kunststof schermen of het dragen van mondkapjes). Bovendien hebben kleine wijzigingen aan de instellingen van CoronaMelder grote gevolgen, zo blijkt uit het veldtest-rapport:> Adhv de parametrisering kan de sensitiviteit of specificiteit worden aangepast, echter:
- Een verhoging van de sensitiviteit tot circa 80% leidt tot een sterke daling in de specificiteit tot circa 32% (maw: véél meer onterechte meldingen)
- Een verhoging van de specificiteit tot circa 85% leidt tot een sterke daling in de sensitiviteit tot circa 20% (maw: bijna niemand krijgt meer een melding)
> Disclaimer: de betrouwbaarheidswaarden gelden voor deze specifieke veldtest-opzet (scenario’s, variabelen, tijdsduren e.d.)
[...]
> Ontleen geen absolute conclusies aan deze veldtest [...]
- Een verhoging van de sensitiviteit tot circa 80% leidt tot een sterke daling in de specificiteit tot circa 32% (maw: véél meer onterechte meldingen)
- Een verhoging van de specificiteit tot circa 85% leidt tot een sterke daling in de sensitiviteit tot circa 20% (maw: bijna niemand krijgt meer een melding)
> Disclaimer: de betrouwbaarheidswaarden gelden voor deze specifieke veldtest-opzet (scenario’s, variabelen, tijdsduren e.d.)
[...]
> Ontleen geen absolute conclusies aan deze veldtest [...]
Iedereen die denkt dat je met smartphones via BLE wel afstanden kunt meten, moet maar eens goed naar die heatmap kijken (onder "Resultaten"), naar de tekst links daarvan en naar het (deels tegenstrijdige) advies op de laatste pagina van https://www.tweedekamer.nl/downloads/document?id=5ca0984a-bae9-4282-8e04-d2ee481b5bc0&title=COVID-19%20Notificatie%20APP.pdf.
Maar nogmaals, die gebrekkige "afstandmeting" is slechts één van de vele problemen van deze app (voor een overzicht daarvan zie https://www.security.nl/posting/687053/CoronaMelder+leugens).
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?