Blick in meine consolidated.db [Update 4]

Visualisierung meiner consolidated.db

Letzte Woche konnte man den Schlagzeilen rund um den neuesten „Datenskandal“ nicht entkommen. Selbst meine Mutter, die sich sonst nicht für IT interessiert, sprach mich Karfreitag darauf an, dass mich Apple bespitzeln würde.

An dieser Stelle möchte ich keine allgemeine Wertung des Vorgangs vornehmen, denn dies ist bereits an vielen Stellen erfolgt. Ich möchte hier nur auf heise, Spreeblick und fscklog verweisen. Immer wieder stößt man auf Verweise auf ein Blogposting von Alex Levinson, das aus meiner Sicht am aufschlussreichsten ist.

Ich möchte mich hier auf einen Blick in meine consolidated.db konzentrieren.

Aber vorher noch ein Hinweis: Seit iOS 4.3.3 ist die consolidated.db nicht mehr im Backup enthalten und die in der Folge beschriebenen Werkzeuge funktionieren nicht mehr. [Ergänzung 12.06.2011] 

Ein Blick mit dem iPhone Tracker

Als erstes Werkzeug bietet sich zunächst der iPhone Tracker von Alasdair Allan und Pete Warden an. Dieses Tool sucht die consolidated.db aus dem Backup heraus und visualisiert die gespeicherten Geokoordinaten auf einer Landkarte.

Hat man die Backups mehrerer iOS-Geräte, dann wird das Backup des iOS-Gerätes ausgewertet, dass zuletzt mit iTunes gesynct wurde (vgl. iPhone Tracker-FAQ) ist es eher zufällig, von welchem Gerät die Daten angezeigt werden. In der derzeitigen Version gibt es keine Möglichkeit, ein bestimmtes Gerät auszuwählen. Dies geht nur mittelbar durch einen Sync des gewünschten Gerätes.

Standardmäßig werden die gespeicherten Daten in einem Raster eingetragen, dessen Kantenlänge 1/100 eines Grades geografischer Länge bzw. Breite entspricht. Je mehr Datenpunkte in einem dieser Rasterfelder liegen, desto größer und dunkler wird der jeweilige Punkt dargestellt (vgl. iPhone Tracker-FAQ).

Im obigen Bild fehlen diese Megacluster, weil ich die Auflösung auf 1/10000 Grad verkleinert habe (geht nur über eine Änderung im Sourcecode).

Das obige Bild zeigt die Visualisierung der consolidated.db meines iPhones (Auschnitt mit Deutschland, südliche Bayern habe ich versehentlich abgeschnitten). Hier fällt auf:

  • Auf den ersten Blick zeigen sich flächige und eher bandförmige Cluster.
  • Wie andernorten beschrieben, folgen die bandförmigen Cluster meinen Reiserouten. Hier gibt es jedoch auch deutliche Lücken)
  • Da die meisten dieser bandförmigen Cluster in Berlin zusammenlaufen, könnte man zu dem zutreffedenden Schluss kommen, dass ich mich hauptsächlich in Berlin aufhalte.
  • Grobgranular betrachtet, nehmen die Bereiche in denen ich mich – zum Teil nur sehr – kurz aufgehalten habe, rein optisch den meisten Raum ein.
  • Es gibt versprengte Einzelpunkte entlang diese Bereiche, an denen ich definitiv nicht war.

Es wäre zu erwarten, dass sich in den Bereichen, in denen ich zumeist aufhalte (Zuhause, Büro), ganz massive Cluster zu beobachten sind. Dem ist jedoch nicht so. Wenn ich in diese Bereiche zoome, finden sich dort nur sehr wenige Punkte. Rund um unser Haus gibt es beispielsweise 25+ WLANe. In der Visualisierung finden sich fast keine Punkte.

Ein Blick direkt in die consolidated.db

Eine weiterer Ansatzpunkt für eine Betrachtung ist eine direkte Auswertung der Datenbank. Wenn man im Dateisystem nach consolidated.db sucht, wird man diese nicht finden. Die Datei ist zwar in lesbarer Form vorhanden, jedoch hat sie einen kryptischen Dateinamen. Wie man diese Datei findet, ist in der iPhone Tracker-FAQ beschrieben. Dort findet sich auch ein Link zu einem Python-Script, das einen die Auswertung abnimmt. Ich habe eine von kenny1987 beschriebene Anpassung des iPhone Tracker vorgenommen, die mir in der Konsole den Dateinamen der consolidated.db ausgibt. Für die Auswertung habe ich den SQLite Database Browser und OpenOffice Calc (Version ab 3.3, weil Calc vorher nur 65.536 Zeilen schafft) verwendet.

Die consolidated.db enthält mehrere Tabelle, die von der Namensgebung her, alle auf eine Erfassung von WLANs und Mobilfunkzellen sowie die Kompasskalibrierung hinweisen.

Positionsdaten finden sich nur in den Tabellen CellLocation (vermutlich (GSM)Mobilfunkstationen, bei mir 20.000+) und WifiLocation (vermutlich WLANs, bei mir 123.000+). Die Tabelle CompassCalibration enthält bei mir 60+ Datensätze ohne für mich erkennbare Georefenzen. Andere Tabelle sind leer oder scheinen Index zu enthalten.

Die ältesten Daten stammen vom 21.06.2010 (zur Umrechnung siehe zwei Absätze weiter).

CellLocation und WifiLocation enthalten neben dem Identifier des Senders (MAC-Adresse des WLAN-Accesspoint, MCC, MNC, LAC und CI bei den GSM-Zellen) einen Zeitstempel sowie geografische Länge und Breite. Weiterhin gibt es Spalten zur Höhe, Geschwindigkeit und Kurs, die jedoch mit gleichbleibenden Werten gefüllt zu sein scheinen. Die Spalte HorizontalAccuracy scheint eine Abweichung in der Ebene zu enthalten, die stark schwankt (bei GSM 500 bis 77440 Einheiten sowie bei WLAN von 50 bis 99 Einheiten). Die weiteren Spalten VerticalAccuracy und Confidence sind durchgehend mit gleichen Werten belegt.

Die Zeitstempel entsprechen nicht den Unix-Zeitstempeln. Nach Aussage von kenny1987 soll hier die Zählung auf den 01.01.2001 aufsetzen (vgl. Sourcecode in iPhoneTrackingAppDelegate.m Zeile 190).

Die Tabelle CellLocation und WifiLocation scheinen nach Zeitstempel aufsteigend sortiert zu sein. Es sind zumeist mehrere Einträge unter identischem Zeitstempel erfasst und die Zeitstempel zeigen deutliche Sprünge, was darauf hindeutet, dass es im Zeitraster eine deutliche künstliche Granularität gibt.

Bei der groben Auswertung der WLAN-Daten ergab, dass jede MAC-Adresse nur einmal in der Tabelle vorkommt. Da die hier lokal ansässigen WLAN-Accesspoints als Letzte mit den höchsten Zeitstempeln in der Tabelle stehen, liegt die Vermutung nahe, dass jeder Sender mit dem Zeitstempel des letzten Erscheinens geführt wird.

Ein stichprobenhafter Abgleich mit den MAC-Adressen der eigenen WLAN-Accesspoints sowie der aus der Nachbarschaft ergab, dass diese in der Tabelle enthalten sind. Damit wird es umso rätselhafter, weshalb der iPhone Tracker in der unmittelbaren Nachbarschaft keine Einträge visualisiert.

Eine Auswertung der Tabelle CellLocation habe ich noch nicht vorgenommen. (Vielleicht mal, wenn ich Zeit und Muße habe…)

Meine eigenen Erkenntnis erhärten für mich das auch anderswo erzielte Ergebnis, dass es sich bei der consolidated.db nicht um eine Datenbank zum Tracking des Benutzers, sondern um eine Sammlung von Sender für die Lokalisierung per AGPS handelt. In diesem Zusammenhang ist es natürlich fraglich, weshalb die Daten (vermutlich) dauerhaft gespeichert und nicht nach einer kurzen Zeitspanne gelöscht werden (Apple gibt ja an, diese Daten alle 12 Stunden anonym zu übermitteln, sodass sie dann gelöscht werden könnten).

Ein Erklärungsansatz wäre, dass über diese Datenbank versucht wird, anhand der vom Gerät selbst erhobenen Daten bereits lokal eine grobe Ortung vorzunehmen, bevor via Internet auf die entsprechende Infrastruktur von Apple bzw. Skyhook Wireless zugegriffen wird. Dies würde dann auch offline eine grobe Verortung zulassen, bevor der erheblich langsamere GPS-Fix vorliegt.

Update (2) – 27.04.2011:

Heute gab es zwei Veröffentlichungen, die meine Ergebnisse und Vermutungen bestätigen.

heise hat – IMHO reichlich spät – eine eigene Analyse rausgelassen. Diese Bestätigt meine Feststellung, dass jeder Sender nur einmal in der Datenbank enthalten ist und der Zeitstempel jeweils mit der aktuellsten Sichtung überschrieben wird. Man kommt zu dem Ergebnis, dass es sich hier nicht um ein (vollständiges) Tracking handelt.

Schlussendlich hat heute Apple – IMHO auch viel zu spät – sein Schweigen gebrochen: Es handele sich nicht um ein Usertracking, sondern um eine Datenbank mit Sendern und deren Standort, die für dies schnelle Standortermittlung verwendet werden. Dies bestätigt meine Vermutung über die Verwendung der Daten (wobei ich davon ausging, dass es die mit dem jeweiligen Gerät gesammelten Daten wären, während diese wohl tatsächlich von Apple übermittelte sind.)

Die Erklärung von Apple erklärt für mich die Angelegenheit schlüssig.

Update (3) – 28.05.2011:

Für Alle, die noch ihrer consoldidated.db suchen, gibt es hier einen Hinweis.

Update (4) – 12.06.2011:

Da auch weiterhin Besucher auf der Suche nach dem Weg zur consolidated.db hier aufschlagen und dann schnurstracks Richtung Pete Warden auf GitHub weiterklicken, habe ich den Hinweis aus dem Update 3 noch einmal etwas prominenter in den Teaserbereich reingeschrieben.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Kommentare abonnieren

Es erfolgt keine Weitergabe von Daten an externe Dienste wie WordPress.com.

eMail-Benachrichtigung bei weiteren Kommentaren.
Auch möglich: Abo ohne Kommentar.