https://themarkup.org/privacy/2021/04/27/google-promised-its-contact-tracing...
Da frage ich mich, ob die Freie Software Implementierung des ENF das besser macht. Hier ist z.B. ein Fork der App für Android erhältlich
https://f-droid.org/de/packages/de.corona.tracing/
Gruß, Bernhard
Hi Bernhard,
On 4/29/21 4:54 PM, Bernhard E. Reiter wrote:
https://themarkup.org/privacy/2021/04/27/google-promised-its-contact-tracing...
Oh danke, darüber bin ich bisher noch nicht gestoßen!
Da frage ich mich, ob die Freie Software Implementierung des ENF das besser macht.
Ich hab mal im CCTG-Raum nachgefragt, und wurde auf die Antwort vom microG-Entwickler @larma (dessen ENF-Implementierung als Bibliothek in die von dir verlinkte freie Corona-Warn-App CCTG eingebunden ist) verwiesen:
https://chaos.social/@Kurt/106137591713162995
Demnach loggt die microG-Implementierung die RPIs (Rolling Proximity IDs), die ausgesendet werden und die Anzahl an gescannten Geräten mit aktiviertem EN, und dass EN aktiv ist.
Der im Markup-Artikel verlinkte Originalartikel erklärt detaillierter, was Google konkret loggt, und was das Problem damit ist:
https://blog.appcensus.io/2021/04/27/why-google-should-stop-logging-contact-...
Demnach loggt die Google-Implementierung zusätzlich zu den eigenen RPIs auch die empfangenen RPIs und die zugehörige Bluetooth-MAC-Adresse (die sich immer parallel mit den empfangenen RPIs ändert).
Der Artikel erklärt, warum das zusätzliche Loggen der empfangenen RPIs problematisch ist (ermöglicht, einen Social-Graph zu erstellen), und warum das gemeinsame Loggen von RPI und Bluetooth-MAC problematisch ist (ermöglicht Abgleich mit existierenden Location-Tracking-Datenbanken und damit Lokalisierung).
Dies ist beides mit den von der freien App geloggten Informationen nicht möglich. Nichtsdestotrotz werden die von der freien App (oder von Apple-Geräten) versendeten RPIs und MACs auch von anderen CWA-Apps, die das Google-Framework verwenden, geloggt.
Mit "nur" den eigenen RPIs und den öffentlichen Listen der RPIs positiv getesteter User lässt sich aber als privilegierte App auch ableiten, ob der Nutzer des Geräts positiv getestet wurde.
Allerdings ist die Situation mit den privilegierten Apps in der Realität nicht so gravierend wie im Artikel beschrieben, da der ROM-Vendor inzwischen jede "priviliged permission" explizit erteilen muss. Im Beispiel des Xiaomi-Phones haben aufgrund dieser Mechanismen nur 6 Apps (2 von Xiaomi, 4 von Google) die READ_LOGS-Permission, im Artikel wird von 54 Apps geschrieben.
Laut dem Markup-Artikel hat Google das Problem inzwischen gefixt (Roll-Out läuft, soll in ein paar Tagen durch sein), wenn auch nicht genauer beschrieben ist, ob das bedeutet, dass jetzt nichts mehr oder weniger geloggt wird.
Ich habe nun angeregt, auch das Logging der eigenen RPIs in CCTG/microG einzustellen, das ist nun hier implementiert:
https://github.com/microg/GmsCore/pull/1464
Viele Grüße
Nico
Hi Nicolas,
Danke für die ausführliche Antwort und die Anregung weniger zu loggen. (Das ist besser, weil Daten weniger exponiert sind.)
Am Donnerstag 29 April 2021 22:40:14 schrieb Nicolas Dietrich:
Der Artikel erklärt, warum das zusätzliche Loggen der empfangenen RPIs problematisch ist (ermöglicht, einen Social-Graph zu erstellen), und warum das gemeinsame Loggen von RPI und Bluetooth-MAC problematisch ist (ermöglicht Abgleich mit existierenden Location-Tracking-Datenbanken und damit Lokalisierung).
Dies ist beides mit den von der freien App geloggten Informationen nicht möglich. Nichtsdestotrotz werden die von der freien App (oder von Apple-Geräten) versendeten RPIs und MACs auch von anderen CWA-Apps, die das Google-Framework verwenden, geloggt.
Was ich mich zusätzlich frage ist, ob die Freie Software-Implementierung hier einen weiteren Vorteil hatte. (Zu den bestehenden Vorteilen, dass z.B. ältere Geräte unterstützt werden.) Wäre ein kleines Beispiel mehr.
Allerdings ist die Situation mit den privilegierten Apps in der Realität nicht so gravierend wie im Artikel beschrieben, da der ROM-Vendor inzwischen jede "priviliged permission" explizit erteilen muss. Im Beispiel des Xiaomi-Phones haben aufgrund dieser Mechanismen nur 6 Apps (2 von Xiaomi, 4 von Google) die READ_LOGS-Permission, im Artikel wird von 54 Apps geschrieben.
Der Heise Artikel wiederholt die hohe Zahl, auch für Samsung Galaxy A11 behaupten sie, es seien viele Apps: https://www.heise.de/news/Android-Schwachstelle-Einige-Apps-konnten-Bluetoot...
Gruß, Bernhard
Moin!
Am Donnerstag 29 April 2021 22:40:14 schrieb Nicolas Dietrich:
Der Artikel erklärt, warum das zusätzliche Loggen der empfangenen RPIs problematisch ist (ermöglicht, einen Social-Graph zu erstellen), und warum das gemeinsame Loggen von RPI und Bluetooth-MAC problematisch ist (ermöglicht Abgleich mit existierenden Location-Tracking-Datenbanken und damit Lokalisierung).
Dies ist beides mit den von der freien App geloggten Informationen nicht möglich. Nichtsdestotrotz werden die von der freien App (oder von Apple-Geräten) versendeten RPIs und MACs auch von anderen CWA-Apps, die das Google-Framework verwenden, geloggt.
Was ich mich zusätzlich frage ist, ob die Freie Software-Implementierung hier einen weiteren Vorteil hatte. (Zu den bestehenden Vorteilen, dass z.B. ältere Geräte unterstützt werden.) Wäre ein kleines Beispiel mehr.
Ich denke, der Hauptvorteil der freien Implementierung ist hier, dass man den Code angucken und auditieren kann. In diesem Fall war es ja eher Glück, dass das Logging der Google-Implementierung aufgefallen ist.
Ob (und wieviel) geloggt wird ist hingegen nicht davon abhängig, ob die Anwendung freie Software ist.
Allerdings ist die Situation mit den privilegierten Apps in der Realität nicht so gravierend wie im Artikel beschrieben, da der ROM-Vendor inzwischen jede "priviliged permission" explizit erteilen muss. Im Beispiel des Xiaomi-Phones haben aufgrund dieser Mechanismen nur 6 Apps (2 von Xiaomi, 4 von Google) die READ_LOGS-Permission, im Artikel wird von 54 Apps geschrieben.
Der Heise Artikel wiederholt die hohe Zahl, auch für Samsung Galaxy A11 behaupten sie, es seien viele Apps: https://www.heise.de/news/Android-Schwachstelle-Einige-Apps-konnten-Bluetoot...
Das haben sie wohl einfach beim Originalartikel abgeschrieben. Ich gebe mal wieder, was der microG-Entwickler im Chat dazu geschrieben hat:
"I think there is a lot of misconception how privileged permissions work on Android.
1. Apps must put the permission request directly in a manifest file. Google does not allow apps in Play Store to request privileged permissions without explanation. 2. Privileged permissions are only granted to apps that are part of the system image and have the permission request in the app version that is on the system image (= updates to system image apps cannot get access to more privileged permissions). 3. Since Android 4.4, apps that want to get a privileged permission must not only be part of the system image (ROM), but also need to reside in a special folder "priv-app". Manufacturers should not put third-party apps in this folder except if there is a very good reason. 4. Since Android 8.0, even if a manufacturer would accidentally put an untrusted third-party app in "priv-app", privileged permissions would not be granted as long as the manufacturer does not explicitly allowlist the specific privileged permission to that app through a configuration file in the system image.
The appcensus blogpost claimed that 54 apps have READ_LOGS permission on Xiaomi Redmi Note 9. That number seemed absurdly high to me, so I downloaded the latest system image for Xiaomi Redmi Note 9 (V12.0.7.0.QJOMIXM), it has a total of 6 apps that got READ_LOGS permission granted (another 7 apps requested, but were not in "priv-app"). Of those 6 apps, 2 are from Xiaomi (package name starts with "com.miui"), the remaining 4 are from Google."
Wie eine vorinstallierte App privilegierte Rechte erhält, hat Google hier beschrieben:
https://source.android.com/devices/tech/config/perms-allowlist
Viele Grüße
Nico
Moin,
On Thu, Apr 29, 2021 at 04:54:03PM +0200, Bernhard E. Reiter wrote:
https://themarkup.org/privacy/2021/04/27/google-promised-its-contact-tracing...
Da frage ich mich, ob die Freie Software Implementierung des ENF das besser macht. Hier ist z.B. ein Fork der App für Android erhältlich
Ohne den Links nachgegangen zu sein, könnte das mit dem Ticket hier in Zusammenhang stehen?
https://github.com/corona-warn-app/cwa-app-android/pull/3005
Grüße Alex
Hallo Alex,
Ohne den Links nachgegangen zu sein, könnte das mit dem Ticket hier in Zusammenhang stehen?
https://github.com/corona-warn-app/cwa-app-android/pull/3005
Nein. Das Logging passiert nicht in der App, sondern durch das Exposure-Notification-Framework von Android, das Teil der proprietären Google Mobile Services ist. Demnach muss auch der Fix von Google kommen, was ja anscheinend schon geschehen ist, wie im verlinkten Artikel steht.
In der freien Exposure-Notification-Implementation von microG, die die in F-Droid verfügbare Corona-Warn-App "Corona Contact Tracing Germany" verwendet, ist ein Fix hier vorgeschlagen:
https://github.com/microg/GmsCore/pull/1464
(Das hatte ich gestern schon geschrieben.)
Grüße
Nico