qrios

In der öffentlichen Wahrnehmung hat Apple Google mal eben rechts überholt und das ohne zu blinken. Streetview war gestern, heute ist “consolidated.db”. Diese Datenbank der Positionen des iPhone/iPad existiert offensichtlich schon länger und wurde laut verschiedenen Quellen bereits von Forensikern genutzt. Die breite Öffentlichkeit und damit auch die tagesschau, heise, golem und ich erlangte erst Kenntnis davon als letzte Woche das Programm iPhoneTracker veröffentlicht wurde. (Sonst hätte ich mir damals nicht die Mühe mit dem iPhone moblog gemacht …). Wiedermal ein sehr schönes Beispiel dafür, dass das Verständnis von IT mit dem Userinterface steht und fällt (Hallo SAP?).

Meine Fahrradrouten durch Berlin in optimierter Auflösung von iPhoneTracker.

Ursprünglich klang für mich das ganze sehr stark nach einem typischen “Programmierer braucht für die Entwicklung ein Log und keiner denkt beim Release daran”. Immerhin basierte lange Zeit die ganze Webtracking-Branche auf den Serverlogs, die eigentlich nur zum debuggen gedacht waren.

Inzwischen kristallisiert sich aber raus, dass es sich keineswegs um ein Versehen handelt und die daraus zu ziehenden Schlussfolgerungen sind nicht schön, at least für Apple. Hervorragend zusammengefasst von Frank Rieger. Aber ich hätte mich nicht erst seit den aktuellen Erkenntnissen geweigert, mein Telefon am Empfang der US-Botschaft abzugeben, wie es – laut Max Winde im letzten mobilemacs-Podcast – mspro vor einiger Zeit machen musste.

Unabhängig von der Bewertung und dem extrem negativen Impact für Apple (den die echten Fanboys schäumen lassen) freue ich mich natürlich, dass ich ohne Jailbreak und entsprechende Tools jetzt eine Datenbank meiner Positionen habe.

Aber warum sind die Daten so ungenau und warum werden mir nur ganze Wochen angezeigt? Geht’s auch etwas genauer?

Die Macher von iPhoneTracker haben die Genauigkeit (sowohl Zeit als auch Position) aus zwei Gründen reduziert. Einerseits wollten sie laut eigener Aussage potentiellen Schnüfflern die Arbeit nicht allzu leicht machen (schwaches Argument) und andererseits – laut Kommentaren im Code – die Ladezeit bei sehr bewegten Leuten nicht dramatisch verschlechtern (starkes Argument). Dankenswerterweise haben die Programmierer den Code freigegeben (Downloadlink) und daher kann man mit wenigen Handgriffen die Genauigkeit selbst bestimmen. Selbstverständlich unter der Voraussetzung, dass man auf einem Mac arbeitet und XCode installiert ist.

Genauigkeit:

In der Datei “iPhoneTrackingAppDelegate.m” findet sich unter tryToLoadLocationDB die Konstante precision mit dem Wert 100. Damit wird die Genauigkeit für Latitude und Longitude jeweils auf zwei Kommastellen reduziert. In Nord-Süd-Richtung beträgt die Genauigkeit dann ca. 1,2 km und in Ost-West etwas über 500 m (τ/2 mal Daumen).

In der Datenbank selbst sind die Koordinaten mit sechs Stellen angegeben womit man genauere Daten hätte als die verschiedenen Verfahren (ausser GPS) der Positionsbestimmung eigentlich liefern. Wenn man mit dem Wert rumspielt und ihn zum Beispiel auf 3000 setzt, landet man bei einem guten Kompromiss zwischen Genauigkeit der Sendemäste und der Anzahl der Ergebnisse ohne viel Rauschen (siehe Screenshot).

Zeitauflösung:

In der gleichen Datei, ebenfalls unter tryToLoadLocationDB findet sich die Einstellung für die Zeitauflösung der Darstellung und Animation. Es werden alle Daten auf eine Woche aggregiert, was für meine Zeiterfassung definitiv zu ungenau ist. Statt

const float weekInSeconds = (7*24*60*60);
const float timeBucket = (floor(unixTimestamp/weekInSeconds)*weekInSeconds);

verwende ich die stundengenaue Angabe:

const float hourInSeconds = (60*60);
const float timeBucket = (floor(unixTimestamp/hourInSeconds)*hourInSeconds);

Weiter unten muss man dann noch die Übergabe der Zeit anpassen. Aus:

NSString* timeBucketString = [timeBucketDate descriptionWithCalendarFormat:@"%Y-%m-%d" timeZone:nil locale:nil];

wird:

NSString* timeBucketString = [timeBucketDate descriptionWithCalendarFormat:@"%Y-%m-%dT%H" timeZone:nil locale:nil];

(Da wir jetzt mit Stunden arbeiten müsste allerdings noch die Sommerzeit berücksichtigt werden …)

Lässt man das jetzt laufen fällt als erstes auf, dass erhebliche zeitliche Lücken existieren. Dies liegt zunächst mal daran, dass im Programm nur die Daten der Tabelle ‘CellLocation’ berücksichtigt werden. Diese werden nur upgedatet wenn ich mich tatsächlich bei einer neuen Funkzelle anmelde.

Eine weitere Tabelle namens WifiLocation verwendet das Programm nicht, weil – laut Kommentar im Code – die Daten zu ‘dodgy’ sind. Mir scheinen sie allerdings nicht unbedingt als unzuverlässig. Sie sind unter normalen Umständen wesentlich umfangreicher und man müsste sie normalisieren bevor man sie zusammen mit den Funkzellen zusammen darstellt. (Abgesehen davon, dass ich in meinen Daten eine WLAN-Station gefunden habe, die ich vor kurzem bei einer Freundin eingerichtet hatte, die grade aus Oslo nach Berlin gezogen war. Laut Datenbank war ich zu diesem Zeitpunkt mal kurz in Oslo.)

Die komplette Struktur der Datenbank mit realen Einträgen kann man übrigens unter iplaq.com/iphone ansehen.

Abseits von diesen Spielereien und dem iPhone im besonderen kann ich übrigens nur jedem den letzten ChaosRadio Express Podcast von Tim Pritlove empfehlen. Unter dem harmlosen Titel “GSM Security” geht es um haarsträubende Lücken im GSM-Netz und Telefonen, die sich ungefragt Software auf der SIM-Card installieren lassen.