Opdatering til Smittestop: Flere vil få varsel om smittefare


Smittestop-appen får en opdatering, der ændrer på indstillingerne for, hvornår appen giver varsel om mulig smitte.
Det skriver DR Nyheder.
Siden appen blev lanceret har den været indstillet til at give en advarsel om mulig smittefare, hvis man har været tæt på en smittet person i et kvarter. Fremover bliver denne tidsgrænse ændret til at være ti minutter.
Appen har tidligere fået kritik for, at den i flere tilfælde ikke gav brugerne besked om smittefare, selvom de havde været tæt på en smittet.
Den nye version 1.2 kan hentes i App Store eller Google Play Store, og i forbindelse med opdateringen har Sundheds- og Ældreministeriet udgivet et dokument, der viser, hvordan appen fremover beregner smitterisiko.
- emailE-mail
- linkKopier link

- Sortér efter chevron_right
- Trådet debat
Nu er app’en åbenbart for følsom, og giver for mange alarmer, ihvertfald for kommunaldirektøren i Favrskov Kommune, der har beordret app’en slukket i arbejdstiden:https://ekstrabladet.dk/nyheder/samfund/kommune-til-medarbejdere-sluk-smittestop-appen/8367355
- more_vert
- insert_linkKopier link
min Google Pixel 2 XL pludselig mistede strøm på rekordtid
Prøv at aktivere btsnoop log for BT (I developer menu). Jeg gætter på at din telefon bliver oversvømmet med advertisements, så AP ikke kan sove. Det burde ikke ske hvis man scanner med 5 minutters interval, men det kan være de laver noget andet også. Men det vil være i den log
- more_vert
- insert_linkKopier link
Jeg har installeret EN på en Raspberry PI Zero (m/Wifi (& Bluetooth)) og sat strøm på fra en batteri pack. Det er faktisk ret informativt. Det er tydeligt at en del mennesker har installeret app'en, hvilket jeg f.eks. kan se når kører med metroen i København.
kig her, for dem som vil nørde https://github.com/ececli/Exposure-Notification-on-RPiOplevede dog en mærkelig ting, at min Google Pixel 2 XL pludselig mistede strøm på rekordtid - I starten var det konsistent med at jeg tændte og slukkede for Raspberry PI'en, men senere fortsatte den også med at miste strøm hurtigt også når jeg slukkede for Raspberry PI'en - så jeg ved ikke hvad der er op og ned, men vil undersøge det nærmere.
- more_vert
- insert_linkKopier link
Sidst der var en opdatering kunne man ikke se om det som lå på Google play var opdateret og nu kan man ikke se hvilken opdatering det er som ligger der.
Google elsker den her "feature" som kaldes rullende opdatering - at opdateringen ikke gøres tilgængelig for alle på en gang. Det kan du ikke klandre udvikleren for.
- more_vert
- insert_linkKopier link
Fra rapporten:
Varighed nær = Varighed med signalstyrke under 63 dBm (helt tæt kontakt), w1 = 250 pct.</p>
<p>Varighed mellem = Varighed med signalstyrke mellem 63 og 68 dBm, w2 = 50 pct.</p>
<p>Varighed fjern Varighed med signalstyrke over 68 dBm (fjern kontakt), w3 = 0 pct.
RSSI har negativt fortegn, dvs. -63dBm etc. Så et signal 'under 63 dBm' er altså > -63dBm. Ja, nitpicking, men det underbygger min konklusion nedenfor.
At definere en forskel på 5 dB mellem 'helt tæt' og 'fjern' er helt i hegnet. Bluetooth signaler kan variere 15-20dB helt rutinemæssigt i et indendørs miljø, ved samme afstand, alt efter hvor meget man (eller andre) bevæger sig. Og det over ganske korte tidsintervaller (måles i millisekunder).
Derudover er der usikkerheden omkring sendestyrke og modtagerfølsomhed, i begge ender af forbindelsen.
Det virker seriøst som om de ikke aner hvad de har med at gøre..
Suk.
- more_vert
- insert_linkKopier link
Så skal i bare have alle til at opdatere. Ddr er vist lidt rod i det hele. Sidst der var en opdatering kunne man ikke se om det som lå på Google play var opdateret og nu kan man ikke se hvilken opdatering det er som ligger der.
Og hvor bliver reklamen af? Er der mon ret mange som kender til det?
- more_vert
- insert_linkKopier link
Google skriver at der scannes hvert femte minut i ca. 4 sekunder (jeg kunne ikke finde noget tilsvarende fra Apple):
For at det vil virke på tværs så skal der være styr på disse intervaller. Men hvis der scannes hvert 5. minut så giver det god mening at sætte grænsen til 10 minutter for at være sikker på at ramme alle man har været i nærheden af i mindst 15 minutter
- more_vert
- insert_linkKopier link
Den dokumentation jeg kan finde nævner BLE Beacons. Det er en efterhånden gammel teknologi som både Google og Apple i forvejen understøtter. Intervallerne ser ikke ud til at være direkte styrbare - måske det er ændret siden den første version af Exposure Notification. Så vidt jeg kan se, kan man (som udvikler) spørge på hvor stor risikoen er for at man er blevet smittet af et specifikt id, og så holder Exposure Notification styr på risikoen.
https://developers.google.com/android/exposure-notifications/meaningful-exposures
https://developer.apple.com/documentation/exposurenotification/configuring_exposure_notifications
Google skriver at der scannes hvert femte minut i ca. 4 sekunder (jeg kunne ikke finde noget tilsvarende fra Apple):
I Google og Apples indledende dokumentation (april 2020) skriver de om broadcast-intervallet:
v1.1 via Google: The broadcasting interval is subject to change, but is currently recommended to be 200-270 milliseconds. (v1.2 kan hentes fra Apple men har samme definition).
- more_vert
- insert_linkKopier link
Findes der dokumentation for de intervaller der bruges for hhv. advertise og scan? At det er svært at estimere tæt nok på 15 minutter lugter af at intervallerne er længe på en måde hvor der kan gå lang tid imellem at den ene device scanner samtidig med at den anden advertiser der kan registreres et match. Det vil selvfølgelig give mening for at undgå at bruge for meget strøm
- more_vert
- insert_linkKopier link