Mal wieder das Blog Phänomen: einer Schreibt, alle scheiben nach, ohne zu wisse was da wirklich ist und erzeugen eine Riesen Welle – Ich weiss es auch nicht besser, aber ich lese nach bevor ich rumschreie.
Fangen wir von Vorne an: Alasdair Alien und Pete Warden haben im O’Reilly radar gepostet, das es im Dateisystem dem iOS eine Datei namens “consolidated.db” db gibt, in denen die Geodaten nach Länge und breite und Zeit gespeichert sind – das iOS speichert die Position ab. Ein kleines Programm von Ihnen kann dieses dann auf einer Karte zeigen – habe ich auch mal gemacht, zeigt auch relativ genau wo ich mich lang bewege, aber nicht wirklich genau – In der Liste stehen keine GPS Daten mit drin, nur die Funkmasten und WLAN Mac Adressen. Man sieht das ich mich in Solingen und Düsseldorf aufhalte und ganz oben noch, als mein iPhone kaputt war, Oberhausen um es im AppleStore umzutauschen und es befinden sich noch Mac (NUR) Adressen von WLAN Rouern drin – Selbst meinen finde ich in der Datenbank aber den Punkt im Bild nicht eindeutig. Woher die Punkte in Wuppertal kommen, kein Ahnung, da war ich 2011 nicht (habe nur 2011 im iPhone, da ich nach dem umgetauschten von Grund auf neu aufgebaut habe).
Und genau an dieser Stelle haben alle nicht richtig aufgepasst: Es wird gespeichert an welchem Turm man angemeldet war und welche in der nähe sind – nicht die 100% genauen GPS Daten.
Das schöne daran ist, das Alex Levinson dieses schon in einem Buch vom 30 Dezember 2010 geschrieben hatte und in Kapitel 10 dieses erklärt:
(Bild: Sein Blog)
Die beiden Herren von O’Reilly schreiben auch, da es dieses erst seit iOS 4 gibt, Alex Levinson schreibt, das es sie vorher h-cells.plist hieß als Apple noch mit Sky-Hook zusammen gearbeitet hatte.
Ich bin kein Programmierer ich kann mir gut vorstellen das diese Datei einfach eine Art Abfall Produkt ist um das Multitasking am Laufen zu halten, wenn Gowalla, Foursquare und wie sie alle heißen, ihre Position bestimmen möchten.
Wer hat was von den Daten? Da Apple sie nicht abruft, anscheinend keiner. Sie sind da und die Panikmache der Herren, das sie im Backup des iPhone drin ist und jeder drauf zugreifen, kann ist die schlimmste daran – einfach in iTunes auf das iPhone klicken->Übersicht und den Haken bei “iPhone-Backup verschlüsseln” schon kann kein Programm einfach so auf die Daten zugreifen <satire> und Diebe des MacBook Pro können diese Daten nicht “Weiterverkaufen” </satire>. Variante zwei man hat ein JB iPhone und installiert auf dem Cydia Store “untrackerd”, ein Programm von Ryan Petrich, was einen Deamon Installiert, der die Datei Periodisch löscht – ob das jetzt Sinnvoller ist…
Warum die Daten dauerhaft gespeichert werden weiss nur Apple, da Sie aber nicht abgerufen werden scheinen Sie wohl für das System gebraucht zu werden.
Jeder der Gowalla, Foursquare, Facebook Places, Google Latitude nutz, gibt ECHTE und GENAUERE Daten an die Anbieter raus, als das iOS System in dieser Datenbank Sammelt und das machen alle Freiwillig.
Und diese ganze Panikmache der Blog’s nervt einfach nur gewaltig. Angefangen von den beiden “Findern” bis hin zu allen die sich darauf gestürzt haben und daraus einen Elefanten gemacht haben und jetzt mal an alle die das so richtig wirklich stört: Kauft euch doch ein Android oder Windows Phone 7! Es Nervt!
[Update]
Wie @packetless berichtet, Speichert Android ebenfalls. Apple glaube ich das sie nichts mit den Daten anfangen, aber bei Google? Na wo bleibt die “Anti Google Medienwelle”?
Mehr Hier
Auszug:
Following the latest days internet outrage/overreaction to the revelation that iPhone has a cache for its location service, I decided to have look what my Android devices caches for the same function. This is a quick dumper I threw together to parse the files from the Android location provider. The files are named cache.cell & cache.wifi and is located in /data/data/com.google.android.location/files on the Android device. You will need root access to the device to read this directory. Usage: parse.py <cache file> Example output: $ ./parse.py cache.wifi db version: 1 total: 47 key accuracy conf. latitude longitude time 50:63:13:57:42:7e 80 92 57.689354 11.994763 04/11/11 10:03:51 +0200 e0:cb:4e:7e:cc:53 75 92 57.689340 11.994495 04/11/11 10:03:51 +0200 4c:54:99:14:47:68 57 92 57.708979 11.916581 04/11/11 01:14:53 +0200 00:26:18:0a:ad:cb 60 92 57.709699 11.917637 04/13/11 08:40:36 +0200 00:22:15:28:3f:7a 60 92 57.699467 11.979340 04/13/11 11:52:16 +0200 00:22:3f:a7:d9:fd 65 92 57.699442 11.979343 04/13/11 11:52:16 +0200 $ ./parse.py cache.cell db version: 1 total: 41 key accuracy conf. latitude longitude time 240:5:15:983885 1186 75 57.704031 11.910801 04/11/11 20:03:14 +0200 240:5:15:983882 883 75 57.706322 11.911692 04/13/11 01:41:29 +0200 240:5:75:4915956 678 75 57.700175 11.976824 04/13/11 11:52:16 +0200 240:5:75:4915953 678 75 57.700064 11.976629 04/13/11 11:53:09 +0200 240:7:61954:58929 1406 75 57.710205 11.921849 04/15/11 19:46:31 +0200 240:7:15:58929 -1 0 0.000000 0.000000 04/15/11 19:46:32 +0200 240:5:75:4915832 831 75 57.690024 11.998419 04/15/11 16:13:53 +0200 If you have any questions/info that you'd like to share, I can be reached via @packetlss on Twitter or packetlss+android@gmail.com