Bluetooth-Autobatterie-Monitor zapfte Standortdaten ab

 (haxrob.net)
2 Punkte von GN⁺ 2023-06-27 | 1 Kommentare | Auf WhatsApp teilen
  • Die BM2-App zum Prüfen des Fahrzeugbatterie-Zustands sammelte nicht nur GPS-Koordinaten, sondern auch Informationen zu umliegenden Wi-Fi-Netzen und Mobilfunkbasisstationen und übermittelte sie an entfernte Server
  • Die Daten gingen an den bm2.quicklynks.com-Server des Produkt-/App-Entwicklers Leagend sowie an Server des Location-Service-SDK-Entwicklers AMap; bestätigt wurden Hosts bei Alibaba Cloud in Hongkong bzw. Peking
  • Laut Google Play hatte die App 100K+ Downloads, doch die anfänglichen Datenschutzangaben im App Store wie „keine Datenweitergabe“, „keine Datenerhebung“ und „Verschlüsselung bei der Übertragung“ stimmten nicht mit dem tatsächlichen Verhalten überein
  • Unter Android ist für Bluetooth-Scans eine Standortberechtigung nötig, sodass Nutzer faktisch Standortzugriff erlauben mussten, um das Gerät zu verwenden; in der iOS-App funktioniert der Batteriemonitor auch dann, wenn die Standortberechtigung verweigert wird
  • Nach dem Update vom 25. Juli 2023 wurde das AMap SDK aus den Versionen in beiden großen App Stores entfernt, doch GPS-Standortdaten werden weiterhin an einen Alibaba-Cloud-Server in Hongkong gesendet, und die iPhone-App übermittelt zusätzlich die Straßenadresse des Nutzers

Standortdaten, die die Batteriemonitor-App sendete

  • Beim betroffenen Produkt handelt es sich um einen Bluetooth-Batteriemonitor, der an die Batteriepole eines Fahrzeugs angeschlossen, mit dem Smartphone gekoppelt wird und Spannung/Prozentwert anzeigt sowie einen Cranking-Test ausführt
  • Analysiert wurde ein unter der Marke PowerTech verkauftes Produkt des australischen Elektronikhändlers Jaycar Electronics; es scheint ein Rebranding von Leagends Bluetooth 4.0 Battery Monitor zu sein
  • Produkte derselben Familie wurden auch unter Bezeichnungen wie der Century-Marke von Repco, ZX-1689 und Li Battery Monitor identifiziert
  • Die Android-App BM2 verzeichnet bei Google Play 100K+ Downloads und 1.55K Bewertungen
  • Auch die BM2-App für das iPhone übermittelte laut Analyse des Netzwerkverkehrs Standortdaten an entfernte Server

Empfänger der Übertragung und Umfang der Erfassung

  • Die App sammelte nicht nur die Batteriespannung, sondern auch GPS-Koordinaten, Daten zu umliegenden Mobilfunkbasisstationen und Informationen zu umliegenden Wi-Fi-Access-Points
  • Für die damalige Übertragung der Standortdaten wurden zwei Zielgruppen bestätigt
    • Leagend-/BM2-App-Server: bm2.quicklynks.com, 47.244.125.231, Alibaba Cloud Hongkong
    • AMap-SDK-Server: dualstack-cgicol.amap.com, 106.11.130.194, Alibaba Cloud Peking
  • AMap ist ein von Alibaba übernommener chinesischer Anbieter digitaler Karten; das SDK erfasst nicht nur GPS, sondern auch andere standortbezogene Daten, die das Smartphone sammeln kann
  • Nach dem Update vom 25. Juli 2023 wurde das AMap SDK aus den Apps in beiden großen App Stores entfernt
    • Die Erfassung von GPS-, Wi-Fi- und Basisstationsdaten, die an Server von AMap auf dem chinesischen Festland gingen, wurde beendet
    • GPS-Standortdaten werden weiterhin an einen Alibaba-Cloud-Server in Hongkong übertragen
    • Die iPhone-App ermittelt und übermittelt zusätzlich die Straßenadresse des Nutzers

Datenschutzangaben im App Store und tatsächliches Verhalten

  • Zum 27. Juni 2023 aktualisierte der Entwickler der BM2-App die Datenschutzangaben bei Google Play und im Apple App Store und gab nun die Erfassung genauer Standortdaten an
  • Zuvor stimmten die Angaben bei Google Play nicht mit dem tatsächlichen Verhalten der App überein
    • „Keine Weitergabe von Daten an Dritte“: Zusammen mit Batteriestatistiken wurden Breiten- und Längengrad an Server von quicklynks.com gesendet, Crash-Analysen an umeng.com und Wi-Fi-, Basisstations- sowie GPS-Koordinaten an AMap
    • „Keine Datenerhebung“: Standortdaten und batterierelevante Daten wurden erfasst
    • „Verschlüsselung bei der Übertragung“: Daten an den BM2-Cloud-Server wurden über unverschlüsseltes HTTP gesendet
  • In den Details der Datenschutzerklärung kamen die Formulierungen „Hong Kong“ und „location information“ vor

Strukturelles Problem durch Android-Berechtigungen

  • Die Android-App verlangt für den Betrieb eine Standortberechtigung; ohne sie kann die Hardware nicht verwendet werden
  • Seit Android 6.0 sind die Berechtigungen ACCESS_FINE_LOCATION oder ACCESS_COARSE_LOCATION erforderlich, um über Bluetooth- und Wi-Fi-Scans auf Hardware-Identifikatoren externer Geräte in der Umgebung zuzugreifen
  • Für die BM2-App wäre tatsächlich nur ein BLE-Scan nötig, doch die weitreichende Standortberechtigung ermöglicht zusätzlich den Zugriff auf GPS-, Basisstations- und Wi-Fi-Daten und eröffnet damit Missbrauchsspielraum
  • Ab Android 12 ist ein BLE-Scan allein mit der Berechtigung BLUETOOTH_SCAN möglich
  • Laut Google-Dokumentation kann bei ACCESS_FINE_LOCATION android:usesPermissionFlags="neverForLocation" angegeben werden, allerdings nur, wenn die Ergebnisse des Bluetooth-Scans nicht zur Ableitung eines physischen Standorts verwendet werden

Im Netzwerkverkehr bestätigte Details

  • Der mobile App-Verkehr wurde mit dem WireGuard-Modus von Mitmproxy untersucht
  • BM2 verwendet kein HTTPS, sodass sich die Übertragung von Breiten- und Längengrad unter Android und iOS auch ohne installiertes Zertifikat bestätigen ließ
  • Nachdem die App eine Verbindung zum Batteriemonitor-Gerät hergestellt hatte, sendete sie eine POST-Anfrage an http://bm2.quicklynks.com:8080/api/bm2/userDevice/upload?
  • Die Anfrage enthielt neben Feldern für Breiten- und Längengrad auch Spannungsproben der Batterie, die Hardware-MAC-Adresse, nickname und serialNo
  • Laut damaliger DNS- und IP-Abfrage wurde bm2.quicklynks.com auf 47.244.125.231 aufgelöst; die IP-Informationen wiesen auf ein zu Alibaba gehörendes AS in Sham Shui Po, Hongkong, hin

Standortsignale, die das AMap SDK verarbeitete

  • Das AMap SDK sammelte GPS-, Wi-Fi- und Mobilfunkbasisstationsdaten
  • Zu den Mobilfunkdaten gehörte die Cell Global Identity
    • MCC: Mobile Country Code
    • MNC: Mobile Network Code
    • MCC + MNC: PLMN, Kennung des Mobilfunkanbieters
    • LAC: Bündel von Basisstationen innerhalb einer Region
    • CI: Kennung des Sende-/Empfangsteils einer Basisstation innerhalb einer Region
    • In 4G wird TAC verwendet
  • Die Wi-Fi-Daten umfassten die BSSID-MAC-Adresse und den Namen des Access Points (SSID)
  • AMap-Daten wurden vor dem Schreiben auf Datenträger oder der Übertragung ins Internet als verschlüsselter serialisierter binärer Blob verarbeitet
  • Die Standortdaten wurden mit einem temporären AES-Schlüssel verschlüsselt, und dieser AES-Schlüssel wurde anschließend nochmals mit einem öffentlichen RSA-Schlüssel verschlüsselt
    • Dieses Verfahren ist nicht auf Certificate Pinning angewiesen
    • Ohne Modifikation der App oder den passenden privaten RSA-Schlüssel ist es schwierig, den Inhalt per Man-in-the-Middle-Netzwerkanalyse einzusehen

Hardware und Testumgebung

  • Der Hardwareaufbau im Inneren ist einfach und besteht im Wesentlichen aus einem Spannungsregler und dem Bluetooth-Low-Energy-MCU CC2541 von Texas Instruments
  • Die CC2541-CPU basiert auf einem 8-Bit-Intel-8051; spätere SoCs der CC-Serie verwenden eine ARM-Cortex-Architektur
  • SoCs der CC-Serie unterstützen eine dedizierte On-Chip-Debugging-Schnittstelle; JTAG oder SWD waren nicht sichtbar
  • Das Gerät unterstützt OTA-Updates, und ein REST-Endpunkt, der Firmware per HTTP zurückliefert, wird in Teil 3 dokumentiert
  • Ein Shunt zur Strommessung oder andere Schaltungen zur Strommessung waren nicht zu sehen, was den Hardwareaufbau sehr einfach erscheinen lässt
  • Getestet wurde mit einer kleinen 12-V-Bleiakku-Batterie, einem BM2-Batteriemonitor und einem gerooteten Android-Gerät
  • Da AMap-Standortdaten nur dann aus dem Speicher in die Datenbank geschrieben werden, wenn physische Bewegung erkannt wird, wurde Laufzeit-Instrumentierung mit Frida und Objection eingesetzt

Verfahren der dynamischen und statischen Analyse

  • GPS-Koordinaten lassen sich mit Frida manipulieren, indem android.location.Location.getLatitude und getLongitude gehookt und auf beliebige Werte gesetzt werden
  • Mit dem Wallbreaker-Plugin von Objection wurden im Heap der App Instanzen von GPS-, Mobilfunkbasisstations- und Wi-Fi-Daten identifiziert
  • Das APK wurde auf dem Gerät per adb shell pm path lokalisiert, extrahiert und mit JADX dekompiliert
  • In der AndroidManifest.xml waren neben FINE_LOCATION auch Berechtigungen wie CAMERA, IMAGE_CAPTURE, ACTION_VIDEO_CAPTURE, MODIFY_AUDIO_SETTINGS und RECORD_AUDIO zu sehen; ob diese Funktionen tatsächlich genutzt werden, erfordert weitere Untersuchung
  • Der Einstiegspunkt der App ist com.stub.StubApp, und es wurde der kommerzielle Packer qihoo.util verwendet
  • Mit frida-dexdump wurde der ursprüngliche Dalvik-Bytecode aus dem laufenden Speicher gedumpt und mit dex2jar sowie JADX in lesbaren Java-Code umgewandelt
  • Der Hauptteil der BM2-App war nicht zusätzlich obfuskiert, das amap-Location-Service-SDK hingegen schon; mit der Deobfuskationsfunktion von JADX konnten einige Klassennamen wiederhergestellt werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-06-27
Meinungen auf Hacker News

  • Das ist das Ergebnis eines Reverse Engineerings eines BLE-Autobatteriemonitors. Die App wurde allein bei Google Play mehr als 100.000-mal heruntergeladen.
    Wie sich herausstellte, sendete sie fortlaufend GPS-Daten, Mobilfunkzellen-IDs und Wi-Fi-Beacon-Daten an Server in Hongkong und auf dem chinesischen Festland. Auf den Seiten im Google- und Apple-App-Store steht, dass keine personenbezogenen Daten erhoben oder an Dritte weitergegeben werden.
    Hoffentlich sind das ein paar Tipps für Leute, die Apps für vernetzte Geräte analysieren wollen.

    • Es scheint auch eine BM6-Variante zu geben; dort wird ausdrücklich angegeben, dass man ein persönliches Konto erstellen und Fahrzeug-Tracking nutzen kann.
      https://www.amazon.de/dp/B0BLG9Z462
      Wenn man auf das dritte Bild klickt, erscheint eine Vergleichstabelle. Interessant ist, dass es als besondere Funktion nur des BM6 vermarktet wird, obwohl es eigentlich nur eine App-Funktion ist.
      Der Geräte-QR-Code [0] verweist auf diese App: https://play.google.com/store/apps/details?id=com.dc.bm6
      Deshalb habe ich auch andere URLs wie https://link.quicklynks.com/bm3.html und https://link.quicklynks.com/bm4.html geprüft; letztere leitet zu https://www.leagend.com/ weiter, die diesen YouTube-Kanal betreiben: https://www.youtube.com/channel/UCqkvyOFP5cXQ02f3h1Ns42Q
      [0] http://link.quicklynks.com/bm6.html
    • Noch schlimmer ist, dass Android beim letzten Mal, als ich nachgesehen habe, für die Verbindung zu BLE-Geräten eine Standortberechtigung verlangte. Vermutlich, weil man über BLE-Scans den Standort abschätzen kann.
    • Ich verstehe nicht, warum 100.000 Menschen eine App zur Überwachung der Autobatterie brauchen. Das wird doch schon im Armaturenbrett angezeigt; ich frage mich, was diese App zusätzlich leisten soll.
      Ob es das wert ist, ständig auch noch den Handy-Akku zu belasten, nur um auf dem Handybildschirm etwas zu sehen, was einem das Armaturenbrett ohnehin schon sagt, weiß ich nicht. Bei einer stationären Batterie könnte man doch einfach ein analoges Voltmeter mit Zeiger verwenden.
      Heutzutage ist es viel zu schwer, eigenständige Geräte zu finden, die ohne App funktionieren. Zum Beispiel war es schon schwierig, eine LED-Lampe zu finden, bei der man die Farbe ohne App über Tasten am Gerät wählen kann; eine habe ich zwar gefunden, aber ein Farbwechsel-Zyklus ohne App war trotzdem nicht möglich.
      Wenn die Leute so einen Unsinn nicht bevorzugen würden, wäre es wieder einfacher, normale Elektronikprodukte zu finden.

  • Ich verstehe nicht, warum Nutzer unter Android eine App nicht daran hindern können, 1) beim Start ausgeführt zu werden und 2) im Hintergrund zu laufen. Das sollte doch zumindest eine zustimmungspflichtige Berechtigung sein.
    Damit ließen sich ziemlich viele Apps stoppen, die auf diese Weise Daten absaugen; ich sehe Google hier als Komplizen.

    • LineageOS konnte früher mit einem eigenen Berechtigungssystem, das Apps Fake-Daten lieferte, noch mehr als das, ohne dass die Apps sich beschweren konnten. Google hat dafür gesorgt, dass diese Funktion entfernt wurde.
    • Mobile ist in dieser Hinsicht viel schlechter als die Desktop-Erfahrung der 90er- und 00er-Jahre. Es fühlt sich wie ein klarer Rückschritt an; zumindest unter Windows 98 konnte man Einträge aus dem StartUp-Ordner löschen.
    • Was du willst, scheint eher in Richtung GrapheneOS zu gehen.
      https://grapheneos.org/
    • Ich hatte kürzlich unter Android eine App, die alle paar Stunden eine Benachrichtigung wie „App X wollte Standortdaten und hat deshalb den Standort aktiviert“ anzeigte.
      Ich weiß, dass Apps die Aktivierung von Standortdaten anfordern können, aber ich war überrascht, dass eine App sie einseitig einschalten kann, und ich habe auch keine Möglichkeit gefunden, das zu verhindern.
      Aus solchen Gründen fällt es mir schwer, irgendeinem Smartphone zu vertrauen.
    • Unter iOS gibt es pro App eine Einstellung für Hintergrundaktualisierung, die man ein- und ausschalten kann.

  • Wegen solcher Fälle dürfen wir den Kampf für digitale Privatsphäre und Gesetze zu ihrem Schutz nicht aufgeben.
    Es geht nicht um „ich habe nichts zu verbergen“, sondern darum, Dritte daran zu hindern, ohne ausdrückliches Wissen und Einverständnis zu überwachen und personenbezogene Daten zu verkaufen.
    Wir befinden uns gerade mitten in einem umfassenden Datenkrieg und müssen entschlossen dagegenhalten.

  • Es nervt, dass so etwas zum Standard geworden ist, obwohl böswillige Akteure praktisch keinerlei Preis dafür zahlen.
    Beim Lesen dieses Artikels war ich froh, GrapheneOS zu verwenden. Ich nutze es seit einigen Monaten im Alltag, und jede App muss bei der Installation ausdrücklich Netzwerkberechtigungen erhalten oder wird abgelehnt.
    Solchen lokalen Apps gebe ich niemals Netzwerkberechtigungen, und auch Keyboard-Apps nicht, bei denen ich immer ein ungutes Gefühl hatte.

    • Weil Berechtigungen versteckt werden und Nutzer gezwungen sind, fast vollständig genau der Partei zu vertrauen, der man am wenigsten trauen sollte, ist so etwas Standard und wird aktiv gefördert.
      Das ist nicht nur lächerlich, sondern offen feindselig gegenüber Privatsphäre und Sicherheit der Nutzer.
    • Ich überlege, zu GrapheneOS zu wechseln, zögere aber, weil es nur auf Google-Smartphones läuft. Andere Android-Alternativ-OS scheinen deutlich weniger kompatibel zu sein; vielleicht bin ich aber auch einfach zu misstrauisch.
    • Ich frage mich, ob man steuern kann, welche Apps beim Start ausgeführt werden und welche Apps im Hintergrund laufen dürfen.

  • Betriebssysteme sollten Internetzugriff zu einer Berechtigung machen, die Nutzer erlauben oder widerrufen können. Android hatte früher wohl so etwas, und iOS hatte es anscheinend nur für mobile Daten.
    Wenn ich ein Gerät kaufe, das angeblich Bluetooth nutzt, tatsächlich aber Internetzugriff braucht, würde ich es zurückgeben.

    • Androids Modell mit Erlauben/Widerrufen von Berechtigungen wurde erst später hinzugefügt. Früher musste man vor der Installation aus dem Store alle Berechtigungen auf einmal akzeptieren, und Internetzugriff gehörte dazu.
      Wenn man nicht zustimmte, konnte man die App nicht bekommen. Einige Berechtigungen funktionieren immer noch so, viele wurden aber auf das Erlauben/Widerrufen-Modell umgestellt.
      Internetzugriff ist weiterhin eine Berechtigung, aber Google Play fragt nicht mehr danach, sodass jede App sie haben kann. Wenn sie im Manifest nicht angefordert wird, funktioniert sie allerdings nicht.
    • Ich habe NetGuard ausprobiert, um unter Android den Internetzugriff bestimmter Apps zu blockieren.
      https://netguard.me/
    • Es wäre gut, wenn man die Netzwerkanfragen sehen könnte, die eine App sendet und empfängt.
      Für Einsteiger könnte man die Domains anzeigen und sie grün markieren, wenn Apple sie auf irgendeine Weise auf eine Allowlist gesetzt hat. Wenn sie weder auf einer Allowlist noch auf einer Blocklist stehen, könnte man sie gelb markieren; oder, falls Farben verwirrend sind, nur den Namen anzeigen.
      Apps, die Anfragen an Blocklist-Ziele stellen, könnte man bis zu einer zusätzlichen Prüfung aus dem App Store sperren.
      Fortgeschrittene Nutzer sollten darauf tippen können, um Details wie Payload und Header zu sehen. Diese Funktion ist wirklich nötig und scheint auch nicht besonders schwer hinzuzufügen zu sein.
    • Das ist der absurdeste Teil. Von allen Berechtigungen sind tatsächlich nur zwei wirklich wichtig: vollständiger Dateizugriff und Netzwerkzugriff. Wenn eine App keine Daten außerhalb ihres eigenen Speichers lesen oder schreiben kann, was spielt es dann für eine Rolle, ob sie Bluetooth-Berechtigungen hat oder nicht?
    • Es ist zwar keine vom Nutzer direkt erlaubte Berechtigung, aber sandboxed macOS-Apps haben ein Entitlement[1] für Netzwerkzugriff. Apple schreibt Sandboxing für alle Apps vor, die im Mac App Store verkauft werden.
      [1]: https://developer.apple.com/documentation/bundleresources/en...

  • App-Store-Anbieter sollten Formulierungen wie „Es werden keine personenbezogenen Daten gesammelt oder an Dritte übertragen“ wohl ganz abschaffen.
    Stattdessen sollten sie warnen: „Diese App hat netzwerkbezogene Berechtigungen und kann beliebige Daten an beliebige Orte senden“ oder „Der App-Hersteller behauptet, keine Daten an Dritte weiterzugeben, aber wir haben keinerlei Möglichkeit, das zu überprüfen.“
    Realistisch gesehen können Apple oder Google nicht wissen, was ein Dritter ist. Server in China und Hongkong könnten First Party sein – wer weiß das schon? Außer dem App-Hersteller weiß es niemand.

    • Wenn man mit digitaler oder elektronischer Technik zu tun hat, die mit China verbunden ist, sollte man davon ausgehen, dass alle verfügbaren personenbezogenen Daten, Standortdaten und sonstigen Daten extrahiert, gesammelt und der Kommunistischen Partei Chinas zugänglich gemacht werden.
      Die Kommunistische Partei Chinas hat vielleicht wenig Interesse an den Daten einzelner Personen, aber an aggregierten Daten hat sie ein sehr großes Interesse. Außerdem werden sie sehr nützlich, wenn sie mit bestimmten Zielen zusammenfallen, etwa mit den über Jahre gesammelten Daten von Millionen US-Regierungsangestellten [0][1].
      Das „große Experiment“, dass offener Handel und Austausch zu Demokratie und Freiheit in China führen würden, ist vollständig gescheitert. Im Ergebnis hat es nur eine rücksichtslose Diktatur gestärkt, die globale Expansion anstrebt. Man sollte keine Geschäfte mit China machen.
      [0] https://en.wikipedia.org/wiki/Office_of_Personnel_Management...
      [1] https://www.nbcnews.com/tech/security/china-spent-years-coll...

  • Man muss erkennen, dass ein überwachendes Gerät am Ende auch das überwachte Objekt selbst langsam verbraucht. Schließlich ist man an dem Punkt, an dem man den Monitor selbst wieder aktiv überwachen muss.
    Dieses BLE-Gerät entlädt die Autobatterie langsam, aber sicher. Irgendwann sendet es eine Warnung, dann muss man die Batterie laden – und kurz darauf wird es sogar aufhören, Warnungen zu senden.
    Außerdem saugt es auch noch die Daten des Handys ab und schickt sie nach China, und es verbraucht den Akku des Handys. Es fällt schwer, sich ein schlechteres Geschenk für die Feiertage vorzustellen; eine seltene dreifache Bedrohung für Verbraucher.

    • Bei einer typischen 70-Ah-Autobatterie würde der 1-mA-Verbrauchsstrom dieses Monitors acht Jahre brauchen, um die Batterie zu entladen. Wenn man die Warnung „25 % verbleibend“ bekommt, bleiben also nur noch zwei Jahre bis zum Nachladen.
      Ernsthaft gesagt: Die Selbstentladung ist ungefähr eine Größenordnung höher als der Verbrauch dieses Monitors.

  • Android braucht eine Funktion, mit der man echten Geräten gefälschte GPS-Daten liefern kann. Das wäre nützlich für Apps, die ohne jeden Grund GPS verlangen.
    Wenn eine Taschenlampen-App GPS braucht, um sich einschalten zu lassen: kein Problem. Mein aktueller Standort ist der Kilimandscharo.

    • Android warnt Nutzer, dass Standortberechtigungen erforderlich sind. Das Problem ist, dass diese Berechtigung für Bluetooth-Scans nötig ist und App-Entwickler das ausnutzen, um auch andere Standortdaten zu sammeln.
      App-Entwickler versuchen den Nutzern dann auch per Popup zu erklären: „Tippen Sie auf Erlauben, damit Bluetooth funktioniert.“
    • In den Entwickleroptionen gibt es eine mock location-Funktion. Soweit ich es verstehe, lädt man eine App herunter, die „gefälschte Standortdaten“ bereitstellt, wählt sie aus, und diese App liefert dann je nach ihrer Implementierung falsche Standorte.

  • An diesem Punkt ist es vernünftig anzunehmen, dass solche Geräte massenhaft Daten sammeln und an die Zentrale schicken. Es würde mich nicht wundern, wenn auch TP-Link-Router alles nach China senden.
    Allerdings ist das nicht auf China beschränkt; auch das iPhone, das man gerade nutzt, könnte möglicherweise jeden Tastendruck und alle Standortdaten in die USA schicken.

    • Diese Denkweise, einfach „davon auszugehen“, gefällt mir nicht besonders. Wenn ein TP-Link-Router zum Beispiel Daten zurücksendet, dann würde er sie – sofern keine echte Spionagetechnik im Spiel ist – als Pakete über das öffentliche Internet schicken. Das lässt sich überprüfen.
      Wenn man vermutet, dass ein TP-Link-Router alles an entfernte Server sendet, muss man eben den Traffic überwachen.

  • Wenn Freunde meine Besessenheit mit Privatsphäre und Datenerhebung belächeln, zeige ich ihnen genau solche Beispiele.
    Es gibt keinen Grund zu glauben, dass so etwas aus böswilligen Motiven geschieht, aber in der Praxis kann man das nicht wissen. Vielleicht ist es schlicht Unwissen oder Inkompetenz.

    • Eine meiner Motivationen, dies zu dokumentieren, ist, das Bewusstsein zu schärfen und andere dazu zu ermutigen, sich anzusehen, was die Geräte und Apps im eigenen Zuhause eigentlich tun.
      Die Menge an Standortdaten, die Gerätehersteller sammeln, ist beträchtlich. Falls sie damit Geld verdienen, frage ich mich, ob man das als böswillig werten kann, selbst wenn es den Endnutzern nicht offengelegt wurde.
      Das von der App verwendete AMap SDK sammelt noch deutlich mehr Standortdaten. Hier habe ich eher den Eindruck, dass es darum geht, die Genauigkeit von Location Services und Kartensoftware zu verbessern, und würde das an sich nicht als böswillig ansehen.
      Anders sieht es aus, wenn dieses Verhalten gegenüber Nutzern und Entwicklern nicht offengelegt wurde. Die Website ist auf Chinesisch [1], und ich frage mich, ob überhaupt jemand die detaillierten Bedingungen liest, um das zu prüfen.
      [1] https://lbs.amap.com/api/lightweight-android-sdk/download
    • Nur weil die Absicht nicht böswillig wirkt, heißt das nicht, dass es in Ordnung ist. Wenn es nichts zu verbergen gab, ist auch die Frage, warum die Datenerhebung nicht von Anfang an ehrlich offengelegt wurde.
      Das erinnert mich daran, wie früher alle die Facebook-„Like“-Buttons auf Websites für harmlos hielten, bis klar wurde, wie umfassend man ohne Einwilligung getrackt wurde.
      Die typische Vorgehensweise Chinas besteht darin, Daten absichtlich auf eine nach außen harmlos wirkende Weise zu sammeln oder Sicherheitslücken bewusst weit offen zu lassen, die später missbraucht werden können. Wenn sie erwischt werden, heißt es: „Entschuldigung, wir beheben das sofort.“
      Noch schlimmer ist, dass solches Verhalten keinerlei Konsequenzen hat. Google, die EU oder die FTC sollten Bußgelder verhängen.
    • Dass Menschen ihre Daten gedankenlos preisgeben, wirkt wie ein Sonderfall der Tragik der Allmende oder wie deren Umkehrung. Natürlich gilt das nicht überall, aber es hat seinen Preis, sich an die naivsten Nutzer anzupassen.