(Dieser Beitrag wurde geschrieben von Jörg Voss)

Interessanterweise teilte N24 im selben Beitrag auch mit, dass man in seiner eigenen, echten N24 App, Zitat: “nur die Zugriffsrechte auf die Telefon-ID und natürlich die Internetverbindung“ anfordern würde. Hier wurde Andreas dann hellhörig und hinterfragte, wofür die IMEI denn benötigt würde. Auch ich klinkte mich in die Frage mit ein und merkte an, dass es heutzutage nicht mehr notwendig sei, die IMEI zu verwenden und es andere Methoden gäbe, die datenschutztechnisch nicht so bedenklich sind wie die IMEI.

Die IMEI (international mobile station equipment identity)  ist eine weltweit eindeutige, 15-stellige Seriennummer, anhand derer man jedes GSM- oder UMTS-Endgerät eindeutig identifizieren kann. Nährere Erklärungen dazu findet man bei Wikipedia.
Das Grundproblem mit der IMEI ist, dass sie aufgrund der engen Verbundenheit des jeweiligen Mobiledevices und seinem Eigentümer einen schützenswürdigen Datensatz darstellt und nicht ohne weiteres den Weg auf irgend welche anderen Server finden sollte, auf denen wer weiß was mit diesen Daten geschehen kann.

Letztlich, nach mehrfachen insistieren von Usern,  hatte “N24 – wir kommen zur Sache“ dann zugesagt, die Verwendung der IMEI aus der App zu entfernen, was ich persönlich sehr positiv betrachte, auch wenn das Verhalten der Artikelverfasser sich im Verlauf der Diskussion zunächst als eher “kindisch“ darstellte.

Jedenfalls hatte ich im Rahmen des teilweise etwas merkwürdigen Diskussionsverlaufes versprochen, die App einmal unter die Lupe zu nehmen, sobald sie veröffentlicht wird. Dieses Versprechen möchte ich einlösen und habe somit die Version 1.0 der N24 App unter die Lupe genommen.

Vorgehensweise:

• Installation der N24 aus dem Google Play Store
• Aufruf der App nach der Installation
• Beenden der App
• Überprüfung des Logcat nach Beendigung der App mit Logman
• Genauere, manuelle Überprüfung des Logcat
• Erneuter Aufruf der App, Ausschalten der “Mobile App Senso Messung“ unter “Datenschutz“
• Beenden der App N24
• Einbuchen des Devices ins eigene  Wlan
• Starten eines Wlan-Sniffer Tools (Wireshark)
• Starten der App N24
• Aufruf eines Artikels
• Beenden der App
• Auswerten des Netzwerkverkehrs mit Hilfe von Wireshark

Ergebnisse:

Das erste Ergebnis der Überprüfung des Logcat durch meine eigene App Logman war positiv und lies zunächst keinen Grund zur Beanstandung erahnen. Es werden weder IMEI, noch IMSI, Telefonnummer, Email oder Location Daten von der N24 App ins Logcat geschrieben.

Das zweite Ergebnis, die manuelle und detaillierte Überprüfung des Logcat, brachte dann allerdings weniger Schönes ans Tageslicht. Gefunden habe ich im Logcat exakt folgende Zeilen:

“08-07 22:29:51.299: I/SmartAdServer(23744): Messages posted to the server : {“connexion”:”wifi”,”uid”:”ad5266a5a5aba24″,”platform”:”Android”,”lang”:”de”,”sdkversion”: ”2.0″,”sdkname”:”SDKAndroid”,”appname”:”SNS”}

08-07 22:29:51.299: I/SmartAdServer(23744): Will load ad at URL : http://mobile.smartadserver.com/call2/pubmj/38682/262488/12626/M/1344371391298// ad5266a5a5aba24/Mozilla%2F5.0%20%28Linux%3B%20U%3B%20Android%204.0.3%3B%20de-at%3B%20GT-N7000%20Build%2FIML74K%29%20AppleWebKit%2F534.30%20%28KHTML%2C%20like%20Gecko%29%20Version%2F4.0%20Mobile%20Safari%2F534.30

Rasch habe ich dann das Device per USB-Kabel an meinen PC angeschlossen und mich mit der am PC installierten Android Debug Brigde (ADB) davon überzeugt, dass es auch wirklich die App von N24 ist, die obige Zeilen ins Logcat schrieb.
C:\users\anonym\adb shell
shell@android:/ $ ps
ps
USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME
…..
app_15    23724 1700  468492 34784 ffffffff 00000000 S android.process.acore
app_125   23744 1700  552572 74620 ffffffff 00000000 S de.cellular.n24hybrid
app_61    23866 1700  462520 28996 ffffffff 00000000 S com.google.android.gsf.login
shell     23883 1711  812    408   c0248490 40072ec4 S /system/bin/sh
….
Wie aus der oben jeweils fett abgedruckten Zahl “23744“ der sogenannten PID klar zu erkennen ist, handelt es sich dabei eindeutig um die App N24.

Was sagen nun die beiden, oben gezeigten, Logzeilen aus?
Zum einen wird in der ersten Zeile angekündigt, dass etwas an einen Server gesendet werden soll, oder wurde, und in der zweiten Zeile wird ausgesagt, dass dies auch erfolgt ist, sowie an welchen Server. Genau genommen werden nun folgende Informationen an einen anderen Server übermittelt:

Verbindungstyp: wifi (wlan Verbindung)  <- “connexion”:”wifi”
eine Erkennungs ID : <- “uid”:”ad5266a5a5aba24″
Die Geräte OS Plattform: <- “platform”:”Android”
Die eingestellte Systemsprache: <- “lang”:”de”
Die verwendete SDK Version: <- “sdkversion”:”2.0″
Der SDK Name: <- “sdkname”:”SDKAndroid”
Der App Name: <- “appname”:”SNS”
sowie im tatsächlichen Request noch zusätzlich:

Die OS Version : Android 4.0.3
Der Geräte Typ: GT-N7000
Der Browser Typ: Mozilla 5.0
Die Sprachvariant: de-at
Die Webkit Verision: AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

Diese Informationen werden unverschlüsselt zu folgendem Server übermittelt:

http://mobile.smartadserver.com

Eine kurze Überprüfung am PC ergibt, dass dieser Server sich in Paris, Frankreich befindet:

C:\Users\anonym\>tracert mobile.smartadserver.com

Routenverfolgung zu itx5.smartadserver.com über maximal 30 Abschnitte:

1     1 ms     1 ms     1 ms  192.168.1.1
2     7 ms     2 ms     1 ms  192.168.0.1
3     18 ms    17 ms  vie-xxxxxxxxx.dsl.sil.at
4    19 ms    17 ms    17 ms  Te1-4-c2.oe6.sil.at
5    21 ms    17 ms    38 ms  81.189.132.89
6    18 ms    19 ms    17 ms  212.152.193.90
7    16 ms    17 ms    17 ms  wen3-core-1.tengigabiteth11-0.tele2.net
8    17 ms    17 ms    18 ms  wen1-core-1.pos0-0.tele2.net
9    35 ms    34 ms    35 ms  fra50-core-1.pos0-12-0-0.tele2.net
10    31 ms    31 ms    30 ms  fra36-peer-1.ae0-unit0.tele2.net
11    30 ms    33 ms    30 ms  peer-as3356.fra36.tele2.net
12    31 ms    40 ms    31 ms  vlan70.csw2.Frankfurt1.Level3.net
13    31 ms    32 ms    32 ms  ae-71-71.ebr1.Frankfurt1.Level3.net
14    40 ms    41 ms    44 ms  ae-48-48.ebr2.Paris1.Level3.net
15    44 ms    50 ms    48 ms  ae-57-222.csw2.Paris1.Level3.net
16    40 ms    39 ms    40 ms  ae-22-52.car2.Paris1.Level3.net
17    40 ms    39 ms    41 ms  SIPARTECH.car2.Paris1.Level3.net
18    41 ms    39 ms    39 ms  91.103.138.174
19    40 ms    40 ms    40 ms  91.103.142.194

Eine nachfolgende Überprüfung durch eine Whois Abfrage bestätige dies dann noch explizit.

Soweit so schlecht, aber was ist nun das Schlimme an diesen Dingen?

Nun, zum einen wird von der N24 App hier ein Merkmal des Android Devices verwendet, welches eine einwandfrei Identifizierung dieses Devices in Netzwerken ermöglicht, und zwar der sogenannte “net.hostname“ welcher die “Android Device ID“ darstellt und für die gesamte Lifetime des Gerätes gültig ist.
(Siehe: http://developer.android.com/reference/android/provider/Settings.Secure.html#ANDROID_ID)
Aussage: A 64-bit number (as a hex string) that is randomly generated on the device’s first boot and should remain constant for the lifetime of the device. (The value may change if a factory reset is performed on the device.)

Wir sind also auch, wenn nicht die IMEI verwendet wird, identifizierbar!

Darüber hinaus, werden diese Informationen über eine unverschlüsselte Internetverbindung, in sich UNVERSCHLÜSSELT übertragen und sind so nahezu von jedermann mit zu lesen.

Nun könnte einer sagen, OK .. das steht im Logcat, aber das heisst ja noch lange nicht, dass diese Daten auch tatsächlich übertragen werden. Um diesem Argument entgegen zu treten, habe ich den gesamten oben beschriebenen Netzwerkverkehr mit Hilfe eines Tools mitgeschnitten und analysiert. Die Daten werden demzufolge tatsächlich an den oben genannten Server in Paris/Frankreich übertragen.

Das Perfide an der hier von den Entwicklern gewählten Methode ist, dass der Standard User nun nicht wirklich etwas dagegen unternehmen kann. Zum einen handelt es sich bei der abgefragten Eigenschaft net.hostname, bzw. der Android_ID nicht um eine Eigenschaft, welche eine sogenannte Permission benötigt, noch werde ich über diesen Umstand an irgendeiner Stelle informiert.
In den online abrufbaren Datenschutzbestimmungen wird zwar auf die Verwendung eines Frameworks mit Namen: Mobile App Sensor hingewiesen, welches eine Gerätekennung verwenden soll, die gekürzt und verschlüsselt (und somit anonymisiert) übertragen wird. Ausserdem soll man sich davon per Opt-out (am Ende der Datenschutzerklärung) durch entfernen eines Hakens befreien können, jedoch betreffen diese Aussagen nach Lage der Dinge nicht die hier stattfindenden Prozesse, da trotz entfernten Haken bei mir dieser Übertragung standfindet. Das hier verwendete Framework ist im Gegensatz zu dem in der Datenschutzerklärung erwähnten, ein Werbeframework, dass Werbeeinblendungen generieren soll.

Die Fragen lauten also: Warum verschweigt N24 dieses den Benutzern seiner App und weshalb werden hier unnötigerweise, so offensichtlich unsichere Technologien verwendet?

Darüber hinaus muss man sich auch die Frage stellen, warum N24 trotz der Bitten der User hier Daten an DRITTE weiterreicht, die dazu benutzt werden können das Device des Benutzers in Netzwerken zu identifizieren?

Es wäre doch so einfach diese Dinge sicherer zu machen und den Benutzer nicht unnötigen Gefahren auszusetzen.
Es würde vollauf genügen, auf eine verschlüsselte Verbindung umzustellen. Also https anstelle von http zu verwenden. Dies in Verbindung mit einem gehashtem oder verkypteten ID Wert, würde den Benutzer in keinster Weise nachhaltig gefährden. Darüber hinaus wäre es natürlich wünschenswert und rechtlich, vermutlich sogar erforderlich, den Benutzer über diese Methoden zu informieren.

Also @N24 – wir kommen zur Sache , was sagt Ihr nun zu dieser Angelegenheit?