qrios

IT ist kurios!

Spielereien mit iPhoneTracker

9 Kommentare

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.


Written by qrios

April 24th, 2011 at 12:33 pm

9 Responses to 'Spielereien mit iPhoneTracker'

Subscribe to comments with RSS or TrackBack to 'Spielereien mit iPhoneTracker'.

  1. Jetzt leistest Du aber allen Schnüffeleien Vorschub! Ich warte schon auf die Bild-Schlagzeile: “Betrogener Mann erschlägt Nebenbuhler mit iPhone!” 😉

    ff

    24 Apr 11 at 1:00 pm

  2. Es gab mal dieses Hobbyprojekt von Harald Bögeholz und anderen. Unter http://www.heise.de/ct/Redaktion/bo/mobilfunk/ konnte man die Positionsdaten von Viag Interkom eintragen. So eine Datenbank könnte man doch jetzt für alle Netze für OpenStreetMap bauen. Hast Du nicht Lust das zu machen?

    Lutgers

    24 Apr 11 at 4:16 pm

  3. Wo finde ich denn die Datei? Mir ist leider vollkommen schleierhaft wo die sein soll. Für jedwede Hinweise wäre ich dankbar!

    MarcoMacro

    24 Apr 11 at 11:33 pm

  4. @MarcoMacro: In der genannten Datei gibt es die Methode loadLocationDB dort wird die Datei ermittelt und als NSString* dbFilePath definiert. Wenn Du Dir die mit NSLog(dbFilePath); danachausgeben lässt hast Du den kompletten Pfad zu der consolidated.db. Auf die kannst du im Terminal zum Beispiel mit “sqlite3 ” zugreifen. Ein Abfrage sieht dann so aus: sqlite> SELECT * FROM CellLocation;

    qrios

    25 Apr 11 at 10:18 am

  5. Der Facebook Like Button wuerde sich gut im Blog machen, oder habe ich ihn uebersehen?

    Finn

    26 Apr 11 at 9:31 pm

  6. Siehe hier.

    qrios

    27 Apr 11 at 10:47 am

  7. I think that is one of the so much vital information for me. And i’m happy studying your article. However wanna statement on some normal issues, The web site taste is perfect, the articles is in reality great : D. Just right process, cheers

  8. I do not even understand how I stopped up right here, however I assumed this put up was once great. I don’t know who you’re but definitely you are going to a famous blogger for those who aren’t already. Cheers!

    Angelcenter

    1 Dec 11 at 12:25 pm

  9. Naja die ganze Positionsbestimmung ist mir noch nicht ganz geheuer. Auslesen eines Bewegungsprofil ist kein großes Hexenwerk mehr.

    Zeiterfassung

    12 Mar 12 at 10:14 am

Leave a Reply