wie geografischen Standort anhand der IP ermittlen

[Henry]

Hallo,

ich habe zwei Fragen zur IP:

1.) Wie kann man denn anhand der IP-Adresse den geografischen Standort eines Rechners ermitteln? Ich möcht jetzt nicht irgendein Tool, wo ich die IP eingebe und hinten kommt ein Standort raus. Ich möchte das technisch im Detail verstehen.

2.) Wie funktioniert dies beim Smartphone, hier ändert sich der Standort doch u.U. ständig wenn ich z.B. mit dem Auto fahre.

[Jörg Reinholz]

ich habe zwei Fragen zur IP:

1.) Wie kann man denn anhand der IP-Adresse den geografischen Standort eines Rechners ermitteln?

Gar nicht. Jedenfalls nicht zuverlässig. Man kann die whois-Daten nehmen und hoffen, dass eine korrekte Adresse drin steht. Das ist aber oft die der Firma, der die IP zugeordnet wird und nicht der Standort des Servers.

Man kann versuchen, ob man mit ping -r, traceroute, etc. den letzten Router herausbekommt und schauen ob für den Standortdaten ermittelbar sind. und hoffen, dass die stimmen und dass geroutet und nicht weiträumig geswitcht wurde, was aber inzwischen häufig der Fall ist.

Man kann auch schauen, ob es eine Webseite gibt und was diese hergibt.

Bei  mit steht:

<meta name="geo.region" 	content="DE-HE" />
<meta name="geo.position" 	content="51.316696; 9.518371" />
<meta name="ICMB" 		content="51.316696, 9.518371" />
<meta name="geo.placename"	content="Kassel; Hessen" /> 

im HTML-header.

Ob das stimmt? In meinem Fall: Ja. Hat aber mit der IP nichts zu tun und schon gar nicht mit dem Standort des Servers. Das ist meine Adresse.

Man kann die geolocation - Dienste fragen. Die spekulieren und haben z.B. bei DSL-Anschlüssen womöglich Daten darüber, was für eine Adresse z.B. bei einem Einkauf angegeben wurde und spekulieren dann, dass diese IP-Adresse relativ ortsnah vergeben wird.

Ich möcht jetzt nicht irgendein Tool, wo ich die IP eingebe und hinten kommt ein Standort raus. Ich möchte das technisch im Detail verstehen.

Da hast Du Dir was vorgenommen. Das ist oft "Glaskugelwissenschaft".

2.) Wie funktioniert dies beim Smartphone, hier ändert sich der Standort doch u.U. ständig wenn ich z.B. mit dem Auto fahre.

Tja. Wenn Du Deine Standortdaten frei gegeben hast? Die Position kann aus den Daten der hierfür genutzten Satelliten, der Funksendemasten und von bekannten WLANS ermittelt werden. Zudem gibt es außerdem die Möglichkeit eine Bewegung von einem bekannten Punkt aus durch Beschleunigungsmessungen fortzuschreiben. Dafür wird das selbe Ding genutzt, mit dem das Mobiltelefon so hübsch vibriert.

Richtig toll funktioniert davon regelmäßig nur die Positionsbestimmung per Satellit, teilweise (wo genügend bekannte da sind) auch der WLANS, der Rest ist reichlich ungenau.

Jörg Reinholz

[1UnitedPower]

Hakuna matata!

Die IP-Adresse allein ist nur ein sehr primtives Indiz bei der Standortbestimmung. Heutige technische Verfahren sind viel weiter entwickelt und beziehen zum Beispiel GPS-Daten und WLAN-Netzwerke in der Umgebungung in die Berechnung mit ein. Als Webentwickler müssen wir uns mit damit allerdings gar nicht erst abmühen, wir können diese schwierige Aufgabe einfach dem Browser überlassen und wir bedienen uns dann mit der Geolocation API einfach am Ergebnis.

Als i-Tüpfelchen obendrauf, können die Benutzer sogar selber wählen, wann und mit wem sie diese private Informationen teilen wollen. Die Browser fragen den Nutzer nämlich, wenn eine Webseite die Geolaction-API benutzen möchte.

[Encoder]

1.) Wie kann man denn anhand der IP-Adresse den geografischen Standort eines Rechners ermitteln?

Such dir verschiedene "ip locator service" oder ähnliche Suchbegriffe und gib denen deine IP. Dann staune über die Unterschiede die da ausgegeben werden. Ich hab das gerade für meine IP gemacht. Zwei Angaben liegen 100 bzw. 200 km von mir weg. Die dritte ist erstaunlich genau, da frage ich mich wie das funktioniert. In diesem Fall muss der Anbieter weitergeben welche Adresse in welchem Ort liegt. Weiß jemand darüber Bescheid?

Meine Meinung: Für genaue Navigationszwecke sind diese Informationen völlig unbrauchbar. Solche Dinge wie "Nächste Eisdiele 300 Meter links oder 500 Meter rechts" sind nicht drin. Selbst wenn du einen Dienst hast der (wie auch immer) den Standort sinnvoll eingrenzen kann, würde ich damit rechnen dass trotzdem völliger Mist rauskommen kann, sowas macht einen schlechten Eindruck wenn keine Erklärung dabei steht. Man sollte seinen Standort bei Bedarf korrigieren können.

Wenns wirklich gut werden soll -> GPS verwenden.

[hotti]

1.) Wie kann man denn anhand der IP-Adresse den geografischen Standort eines Rechners ermitteln? Such dir verschiedene "ip locator service" oder ähnliche Suchbegriffe und gib denen deine IP. Dann staune über die Unterschiede die da ausgegeben werden. Ich hab das gerade für meine IP gemacht. Zwei Angaben liegen 100 bzw. 200 km von mir weg. Die dritte ist erstaunlich genau, da frage ich mich wie das funktioniert. In diesem Fall muss der Anbieter weitergeben welche Adresse in welchem Ort liegt. Weiß jemand darüber Bescheid?

Möglicherweise SNMP: SysLocation auf den Routern setzen und die Public-Community zugänglich machen. Ein Dienst kann sich so von Router zu Router hangeln und den ersten Hop ermitteln, wo die SysLocation gesetzt ist. Sowas habe ich auch schonmal programmiert. Wenn die MIB gesetzt ist, kann mit diesen Daten eine Karte gezeichnet werden.

Was WLAN betrifft: Hier steikt mein Tablett. Vermutlich sucht navigator.geolocation.getCurrentPosition() eine Information direkt in den WLAN-Datenpaketen, wenn dazu jemand eine Hinweis hat, bitte her damit.

MfG

[Mattes]

Was WLAN betrifft: Hier steikt mein Tablett. Vermutlich sucht navigator.geolocation.getCurrentPosition() eine Information direkt in den WLAN-Datenpaketen, wenn dazu jemand eine Hinweis hat, bitte her damit.

Die Position wird nicht ermittelt, indem der Browser direkt an der Netzwerkschnittstelle schnüffelt.

Es gibt drei Möglichkeiten: GPS & Co. sowie die Kennungen der sichtbaren Mobilfunk- und WLAN-Zellen. Aus der Satelliteninfo ergibt sich logischerweise sofort ein Standort, mit den Kennungen werden Datenbanken abgefragt.

Die genauesten Datenbanken werden von Apple und Google geführt; Microsoft baut vermutlich Ähnliches auf. Es gibt genügend iOS- und Android-Geräte, die ständig auf Empfang sind und auch GPS eingeschaltet haben. Über GPS wird von den Betriebssystemen der Standort ermittelt und regelmäßig zusammen mit den gerade sichtbaren Mobilfunk- und WLAN-Zellen (einschließlich Signalstärke, so möglich) an die jeweilige Datenbank übermittelt.

Gerade die WLAN-Zellen sind aufgrund ihrer geringen Reichweite ein sehr genaues und obendrein schnelles Mittel zur Positionsbestimmung. Je nach Versorgung sind da 20 bis 50 Meter in Sekundenschnelle durchaus drin.

Es gibt neben Apple und Google auch mehr oder weniger freie Datenbanken, zum Beispiel Open WLAN Map oder Mozilla Location Service, die nach dem gleichen Prinzip arbeiten, aber natürlich mit eigenen Programmen.

Um nochmal auf die ursprüngliche Frage zu kommen: Die Position von Festnetz-Anschlüssen lässt sich auf diesem Wege ebenfalls zuordnen. Man braucht nur mit seinem iOS- oder Android-Gerät vor die Haustür gehen, GPS einschalten und Verbindung zum heimischen WLAN herstellen. Damit ist nach kurzer Zeit sowohl das WLAN lokalisiert als auch die IP-Adresse des Festnetz-Anschlusses, über den das WLAN am Internet hängt, mithin das Gerät zur Datenbank Kontakt aufnimmt.

Die Genauigkeit dieser Methode hängt vermutlich am Meisten von der Größe des Providers ab. Bei der Telekom als deutschlandweitem Anbieter kann es passieren, dass IP-Bereiche in ein anderes Netzsegment umziehen und die Ortung entsprechend in die Hose geht. Vor meinem Wechsel auf einen IP-Tarif hat Google Maps (Firefox -> Mozilla- und Google-Datenbank) meinen (WLAN-freien) PC auf etwa 1000 Meter genau lokalisiert; nach dem Wechsel hänge ich in einem anderen IP-Bereich und Maps meint, ich säße 400 km entfernt in der niedersächsischen Provinz.

[hotti]

hi,

Es gibt neben Apple und Google auch mehr oder weniger freie Datenbanken, zum Beispiel Open WLAN Map

Ah verstehe, meinen Hotspot hinterm Sofa kennt ja keiner ;)

Trotzdem müsste navigator.geolocation.getCurrentPosition() dann auf die IP-Addr. zurückfallen, was jedoch nicht passiert. Mit meinem PC im LAN (verkabelt) funktioniert das einwandfrei.

MfG

[Encoder]

Die Position von Festnetz-Anschlüssen lässt sich auf diesem Wege ebenfalls zuordnen. Man braucht nur mit seinem iOS- oder Android-Gerät vor die Haustür gehen, GPS einschalten und Verbindung zum heimischen WLAN herstellen. Damit ist nach kurzer Zeit sowohl das WLAN lokalisiert als auch die IP-Adresse des Festnetz-Anschlusses, über den das WLAN am Internet hängt, mithin das Gerät zur Datenbank Kontakt aufnimmt.

Wer führt das dann wo zusammen? Das nimmt ja erschreckende Ausmaße an, damit könnten einige Internetnutzer auf jeder beliebigen Webseite mit Namen begrüßt werden, nur anhand ihrer IP.

[hotti]

s. Thema. Der Browser, welcher das unterstützt, sendet einen Request mit verschlüsselten Daten, mit Perl nachgestellt, sieht der Request so aus:

use strict;
use warnings;
use LWP::UserAgent;
use HTTP::Request::Common qw(POST);

# User-Agent und URL
my $ua = LWP::UserAgent->new;
my $url = "https://www.googleapis.com/geolocation/v1/geolocate?key=AIzaSyD-s-mXL4mBzF7KMRkhTCIbG2RKnRGXzJc";

my $req = (POST $url, "{}");

my $res = $ua->request($req);

print $res->as_string;

Und hier die Response: HTTP/1.1 200 OK Cache-Control: no-cache, no-store, max-age=0, must-revalidate Connection: close Date: Sat, 14 Mar 2015 16:48:57 GMT Pragma: no-cache Accept-Ranges: none Server: GSE Vary: X-Origin Vary: Origin,Accept-Encoding Content-Type: application/json; charset=UTF-8 Expires: Fri, 01 Jan 1990 00:00:00 GMT Alternate-Protocol: 443:quic,p=0.5 Client-Date: Sat, 14 Mar 2015 16:48:57 GMT Client-Peer: 216.58.211.42:443 Client-Response-Num: 1 Client-SSL-Cert-Issuer: /C=US/O=Google Inc/CN=Google Internet Authority G2 Client-SSL-Cert-Subject: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.googleapis.com Client-SSL-Cipher: ECDHE-RSA-AES128-GCM-SHA256 Client-SSL-Socket-Class: IO::Socket::SSL X-Content-Type-Options: nosniff X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=block

{  "location": {   "lat": 49.9889241,   "lng": 8.2716688  },  "accuracy": 96456.0 }

Anmerkung: Wie obenstehender Key erzeugt wird, ist ein Geheimnis des Browsers. Das Beispiel ergibt sich mit meiner derzeitigen IP-Adresse, die Daten sehen ggf. anders aus.

MfG

[dedlfix]

Tach!

s. Thema. Der Browser, welcher das unterstützt, sendet einen Request mit verschlüsselten Daten, mit Perl nachgestellt, sieht der Request so aus: my $url = "https://www.googleapis.com/geolocation/v1/geolocate?key=AIzaSyD-s-mXL4mBzF7KMRkhTCIbG2RKnRGXzJc"; Anmerkung: Wie obenstehender Key erzeugt wird, ist ein Geheimnis des Browsers.

https://developers.google.com/maps/documentation/business/geolocation/#auth

dedlfix.

[hotti]

Anmerkung: Wie obenstehender Key erzeugt wird, ist ein Geheimnis des Browsers.

https://developers.google.com/maps/documentation/business/geolocation/#auth

Der Algorithmus wäre interessanter ;)

[dedlfix]

Tach!

Anmerkung: Wie obenstehender Key erzeugt wird, ist ein Geheimnis des Browsers. https://developers.google.com/maps/documentation/business/geolocation/#auth Der Algorithmus wäre interessanter ;)

Beantragen bei Google, in Empfang nehmen, dem Link hinzufügen.

dedlfix.

[Mattes]

Anmerkung: Wie obenstehender Key erzeugt wird, ist ein Geheimnis des Browsers.

https://developers.google.com/maps/documentation/business/geolocation/#auth

Der Algorithmus wäre interessanter ;)

Das ist eine Zufallszahl, sie dienst quasi als Kundennummer, um die die API nutzende Anwendung zu identifizieren. Läuft eine Anwendung Amok, kann Google dem Programmierer der Anwendung auf die Füße treten.

[hotti]

Anmerkung: Wie obenstehender Key erzeugt wird, ist ein Geheimnis des Browsers.

https://developers.google.com/maps/documentation/business/geolocation/#auth

Der Algorithmus wäre interessanter ;)

Das ist eine Zufallszahl,

Nicht ganz, es steckt ja die IP drin

sie dienst quasi als Kundennummer,

davon auch ein Teil,

um die die API nutzende Anwendung zu identifizieren.

irgendwas vom Browser,

Läuft eine Anwendung Amok, kann Google dem Programmierer der Anwendung auf die Füße treten.

Die hahm sich aber auch ;)

[Mattes]

Anmerkung: Wie obenstehender Key erzeugt wird, ist ein Geheimnis des Browsers.

https://developers.google.com/maps/documentation/business/geolocation/#auth

Der Algorithmus wäre interessanter ;)

Das ist eine Zufallszahl,

Nicht ganz, es steckt ja die IP drin

Nein, da steckt nichts drin, es ist eine reine Identifikationsnummer der Anwendung.

[hotti]

hi,

Nicht ganz, es steckt ja die IP drin

Nein, da steckt nichts drin, es ist eine reine Identifikationsnummer der Anwendung.

Wenn sich die IP ändert, wird eine Neue ausgehandelt, das macht der Browser. Guck mal, was Dein Browser hier an google sendet.

Bis dann.

[dedlfix]

Tach!

Nicht ganz, es steckt ja die IP drin Nein, da steckt nichts drin, es ist eine reine Identifikationsnummer der Anwendung. Wenn sich die IP ändert, wird eine Neue ausgehandelt, das macht der Browser.

Achwas, der Browser hat keine IP-Adresse, der handelt auch keine aus. Mein Netzwerkinterface hängt im LAN und hat da eine gleichbleibende interne Adressen. Der Browser hat auch keine Ahnung welche IP-Adresse mein Router hat.

Guck mal, was Dein Browser hier an google sendet.

Nichts.

dedlfix.

[hotti]

Tach!

Nicht ganz, es steckt ja die IP drin Nein, da steckt nichts drin, es ist eine reine Identifikationsnummer der Anwendung. Wenn sich die IP ändert, wird eine Neue ausgehandelt, das macht der Browser.

Achwas, der Browser hat keine IP-Adresse, der handelt auch keine aus.

Richtig aber in dem Zusammenhang bist Du total auf dem Holzweg: Der Browser handelt nicht die IP-Adresse aus sondern den API-Key.

Analytisch denken, mein Lieber ;)

[dedlfix]

Tach!

Nicht ganz, es steckt ja die IP drin Nein, da steckt nichts drin, es ist eine reine Identifikationsnummer der Anwendung. Wenn sich die IP ändert, wird eine Neue ausgehandelt, das macht der Browser. Achwas, der Browser hat keine IP-Adresse, der handelt auch keine aus. Richtig aber in dem Zusammenhang bist Du total auf dem Holzweg: Der Browser handelt nicht die IP-Adresse aus sondern den API-Key. Analytisch denken, mein Lieber ;)

Verständlicher schreiben! Es bleibt trotzdem falsch. Der API-Key wird nicht ausgehandelt, der ist von Gogle vorgegeben. Meine interne feste IP kann schon - analytisch denkend - keine Grundlage dafür sein, wenn sich die öffentliche oder vielleicht auch eine Proxy-IP-Adresse von dieser unterscheidet. Und was will man aus einer internen IP-Adresse für einen Standort ermitteln?

Geh du mal lieber auf den Link von 18:04 und lies da mal nach, wie man an den Key kommt. Kleiner Tipp, Bei "Finding your API key" muss man auf die Dreiecke klicken, um die Vorgenensweise angezeigt zu bekommen.

dedlfix.

[hotti]

Tach!

Geh du mal lieber auf den Link von 18:04 und lies da mal nach, wie man an den Key kommt. Kleiner Tipp, Bei "Finding your API key" muss man auf die Dreiecke klicken, um die Vorgenensweise angezeigt zu bekommen.

Siehst Du, da steht, wie ein normaler Benutzer den API-Key bekommt. Der Browser hat den API-Key ebenfalls von google bekommen und in places.sqlite lokal gespeichert. Ergo muss der Browser oder der Hersteller des Browsers diesen Key irgendwann einmal mit google ausgehandelt haben. Das ist sozusagen eine Untersuchung erster Ordnung.

Bei meiner Analyse war lediglich die Annahme, dass im Fall einer Änderung REMOTE_ADDR ein neuer API-Key ausgehandelt wird, nicht richtig. Dieses Aushandeln erfolgt nur einmal, danach kennen Client und Server den Key.

Schönen Sonntag.

[dedlfix]

Tach!

Siehst Du, da steht, wie ein normaler Benutzer den API-Key bekommt. Der Browser hat den API-Key ebenfalls von google bekommen und in places.sqlite lokal gespeichert. Ergo muss der Browser oder der Hersteller des Browsers diesen Key irgendwann einmal mit google ausgehandelt haben. Das ist sozusagen eine Untersuchung erster Ordnung.

Da könnte ja jeder Client kommen, und sich einfach mal so einen Lizenzschlüssel aushandeln. Was anderes stellt der API-Key ja nicht dar. Das macht er dann bei jeder Anfrage neu und ist nicht mehr vom Limit für kostenlose Keys (100 queries per 24 hours; 1 query per second, per user) betroffen. So unklug ist Google nun auch wieder nicht.

Bei meiner Analyse war lediglich die Annahme, dass im Fall einer Änderung REMOTE_ADDR ein neuer API-Key ausgehandelt wird, nicht richtig. Dieses Aushandeln erfolgt nur einmal, danach kennen Client und Server den Key.

Immer noch nicht richtig. Da wird nichts zwischen Client und Server ausgehandelt. Der Key wird vom Entwickler angefordert, gegebenenfalls nach Zahlung eines Obulus. Dann wird der Key per Copy und Paste aus der Google Developers Console in der Anwendung hinterlegt. Die Anwendung wird nun zum Endanwender ausgeliefert. Bei entsprechenden Requests kann der Key nun zum Server der Geolocation API mitgeschickt werden.

Solche API-Keys gibt es auch für andere Google-APIs zu anderen Themen als Geolocaton. Auch da dient der lediglich "to tie a request to a specific project in order to monitor traffic, enforce quotas, and handle billing". Da sind jedenfalls keinerlei themenrelevanten Informationen drin verschlüsselt.

dedlfix.

[hotti]

Jetzt guck doch endlich mal in Deinen Browser, welcher Key da hinterlegt ist und ob das derselbe ist wie in meinem FF. Diese Frage habe ich gestern schonmal gestellt.

Oder guck mal in places.sqlite.

key=AIzaSyD-s-mXL4mBzF7KMRkhTCIbG2RKnRGXzJc

Deine Antwort:

[a] Mein FF (Version ...) hat denselben API-Key [b] Mein FF (Version ...) hat einen anderen API-Key

Das wird Andere bestimmt auch interessieren.

Bis dann.

[dedlfix]

Tach!

Jetzt guck doch endlich mal in Deinen Browser, welcher Key da hinterlegt ist und ob das derselbe ist wie in meinem FF. Diese Frage habe ich gestern schonmal gestellt.

Du hast nach einem Request gefragt, den mein Browser (in dem Falle Chrome) nicht ausgeführt hat. Er hat Standortdaten ohne einen weiteren Request rausgerückt, nachdem ich ihm das für den Fall erlaubt hatte. Von FF fängst du jetzt erst zu reden an. Wo man genau den Key finden können soll, hast du auch noch nicht verlauten lassen. Nur den Namen der Datenbankdatei erwähntest du.

Oder guck mal in places.sqlite. key=AIzaSyD-s-mXL4mBzF7KMRkhTCIbG2RKnRGXzJc

Da sind eine Menge Tabellen mit vielen Datensätzen drin. Gehts noch ein wenig ungenauer zu beschreiben, was du konkret sehen möchtest?

Deine Antwort: [a] Mein FF (Version ...) hat denselben API-Key [b] Mein FF (Version ...) hat einen anderen API-Key

[c] Meine Browser haben garantiert keine API-Keys, die irgendeine Information zu meinem Standort enthalten, weil der Verwendungszweck der Keys die Identifikation der Anwendung ist, und nicht die Identifikation des Anwenders. Ansonsten verschickt mein FF denselben Key. Es ist schließlich dieselbe Anwendung, für die der Key ausgegeben wurde.

dedlfix.

[hotti]

Ansonsten verschickt mein FF denselben Key.

Danke. Bei einem Request https://www.googleapis.com/geolocation/v1/geolocate?key=AIzaSyD-s-mXL4mBzF7KMRkhTCIbG2RKnRGXzJc den ich mit diesem Key und jedem beliebigen Useragent ausführen kann, wird google die REMOTE_ADDR des UserAgent heranziehen um den Standort zu bestimmen.

MfG

[Mattes]

Bei einem Request https://www.googleapis.com/geolocation/v1/geolocate?key=AIzaSyD-s-mXL4mBzF7KMRkhTCIbG2RKnRGXzJc den ich mit diesem Key und jedem beliebigen Useragent ausführen kann, wird google die REMOTE_ADDR des UserAgent heranziehen um den Standort zu bestimmen.

Zwangsläufig, falls du keine weiteren Daten zur Verfügung stellst. Normalerweise ist das eine POST-Anfrage, die eine Liste der für das Gerät sichtbaren Mobilfunk- und WLAN-Zellen enthält, aber das steht in der Geolocation-API-Anleitung, auf die dedlfix schon hingewiesen hatte.

[hotti]

Bei einem Request https://www.googleapis.com/geolocation/v1/geolocate?key=AIzaSyD-s-mXL4mBzF7KMRkhTCIbG2RKnRGXzJc den ich mit diesem Key und jedem beliebigen Useragent ausführen kann, wird google die REMOTE_ADDR des UserAgent heranziehen um den Standort zu bestimmen.

Zwangsläufig, falls du keine weiteren Daten zur Verfügung stellst. Normalerweise ist das eine POST-Anfrage, die eine Liste der für das Gerät sichtbaren Mobilfunk- und WLAN-Zellen enthält,

Ah, klar. Deswegen die {}-Klammern, die bei mir leer sind.

MfG ;)

[hotti]

Bei einem Request https://www.googleapis.com/geolocation/v1/geolocate?key=AIzaSyD-s-mXL4mBzF7KMRkhTCIbG2RKnRGXzJc den ich mit diesem Key und jedem beliebigen Useragent ausführen kann, wird google die REMOTE_ADDR des UserAgent heranziehen um den Standort zu bestimmen.

Zwangsläufig, falls du keine weiteren Daten zur Verfügung stellst. Normalerweise ist das eine POST-Anfrage, die eine Liste der für das Gerät sichtbaren Mobilfunk- und WLAN-Zellen enthält, aber das steht in der Geolocation-API-Anleitung, auf die dedlfix schon hingewiesen hatte.

Eine kleine Anmerkung zu diesem Request: Ein POST-Request mit GET-Parametern ist nicht gerade eine zweckmäßige Empfehlung, ein Request erfolgt mit einer Methode. Des Weiteren ist es reichlich ungeschickt, einen API-Key, den nicht jeder gleich sehen soll, im URI als GET-Parameter unterzubringen. Der für den Request programmierte Content-Type: application/json passt außerdem besser zur Requestmethode PUT anstelle POST.

Ich würde klare Verhältnisse schaffen, ein PUT-Request und den API-Key im JSON-String unterbringen. Zumal der Request mit SSL erfolgt, in diesem Fall wird der API-Key gleich mit verschlüsselt. Anstelle PUT gäbe es auch die Möglichkeit den Content-Type: multipart/form-data zu verwenden, Request-Method POST, den JSON-String als application/json und als ein Attachment anzuhängen, hier wäre der API-Key ein eigenständiger Parameter im Request.

Wie navigator.geolocation mit der google-API zusammenspielt, ist ansonsten soweit klar.

Weiterhin schönen Sonntag.

[dedlfix]

Tach!

Eine kleine Anmerkung zu diesem Request: Ein POST-Request mit GET-Parametern ist nicht gerade eine zweckmäßige Empfehlung, ein Request erfolgt mit einer Methode.

Die Bezeichnung GET-Parameter kommt wohl aus dem PHP-Umfeld und allen anderen Systemen, die den Querystring aus dem Request auf eine Struktur mit GET im Namen abbilden. Ansonsten ist er einfach nur ein Querystring, der zu einer URL gehört. Und das ganz unabhängig davon, mit welcher Methode diese an einen Server gesendet wird.

Des Weiteren ist es reichlich ungeschickt, einen API-Key, den nicht jeder gleich sehen soll, im URI als GET-Parameter unterzubringen.

Der Request einer Anwendung wird in den meisten Fällen für den Anwender unsichtbar gesendet. Du musstest dich auch erst in die Niederungen der Entwicklertools begeben, um ihn zu sehen. Und ob er da in der Kopfzeile des Requests zu sehen ist oder erst einen Klick später in den POST-Daten zu sehen ist, spielt dann auch keine Rolle mehr. Zudem wird wohl der Request-Body einem gewissen Standard folgen, der die Übermittlung eines Google-spezifischen API-Keys nicht vorgesehen haben wird. Wie sollen da noch Extra-Daten eingearbeitet werden? Nimmt man da lieber eine hotti-Spezial-Lösung oder hängt ihn einfach an den Querystring an? Obendrein wird es für einen Türsteher-Server einfacher sein, den Key aus dem Querystring zu nehmen, als ein JSON/XML/wasauchimmer-Datenpaket aufzudröseln.

Der für den Request programmierte Content-Type: application/json passt außerdem besser zur Requestmethode PUT anstelle POST.

Für die Anwendung "gib mir Daten zu den Daten, die ich dir sende" passt PUT nicht wirklich, denn das ist zum Übertragen von Daten(sätzen) zwecks Speicherung vorgesehen. ("The PUT method requests that the enclosed entity be stored under the supplied Request-URI." RFC 2616)

Zumal der Request mit SSL erfolgt, in diesem Fall wird der API-Key gleich mit verschlüsselt.

Du meinst also, dass die URL bei einer HTTPS-Verbindung unverschlüsselt übertragen wird? Dann solltest du mal dein Wissen auffrischen. Es ist nicht so, dass die HTTP-Header im Klartext und der Body verschlüsselt übertragen werden. Lediglich der Hostname wird mit dem SNI-Zusatz zum TLS schon während des Handshake-Prozesses übertragen, damit man mehrere eigenständige (und damit mit separaten Zertifikaten und Schlüsselgedöns ausgestattete) VHosts auf derselben IP-Adresse betreiben kann. Alles andere geht verschlüsselt auf die Reise, inklusive Header und URL. Dass du bei dir im Browser quasi Quellen-TKÜ machst und die Requests unverschlüsselt sehen kannst, steht auf einem anderen Blatt.

dedlfix.

[hotti]

hi,

Der Request einer Anwendung wird in den meisten Fällen für den Anwender unsichtbar gesendet. Du musstest dich auch erst in die Niederungen der Entwicklertools begeben, um ihn zu sehen. Und ob er da in der Kopfzeile des Requests zu sehen ist oder erst einen Klick später in den POST-Daten zu sehen ist, spielt dann auch keine Rolle mehr. Zudem wird wohl der Request-Body einem gewissen Standard folgen, der die Übermittlung eines Google-spezifischen API-Keys nicht vorgesehen haben wird. Wie sollen da noch Extra-Daten eingearbeitet werden?

Guck Dir den Enctype multipart/form-data an. Der API-Key wäre ein Parameter, der JSON wäre ein Parameter. Multipart: Jeder Part kann einen eigenständigen Content-Type haben. Der JSON-Part kriegt außerdem den Parameter filename='blob' denn das ist ja nichts weiter als eine Datei.

Ein solcher POST schafft klare Verhältnisse und serverseitig gibt es entsprechende Libs für alle PLs die überhaupt serverseitig eingesetzt werden.

Ich würde die Frage eher andersherum stellen: Warum ein POST-Request an einem URL mit Query_String? Wer sowas serverseitig verarbeiten will, muss den Parser seiner PL schon sehr genau kennen, die arbeiten nämlich unterschiedlich von PL zu PL. Aber die Kollegen dürfen gerne weiter pfuschen, vielleicht gibt es demnächst ein Update für LiveHTTPHeaders und vieleicht sorgen die auch dafür, dass bestimmte URLs mit bestimmten Query_Strings nicht in places.sqlite landen. Das sind alles Abhängigkeiten, die keine Rolle spielen würden mit Standards, die sich jahrelang bewährt haben.

Und ja, die Hotti-Speziallösung: Einen JSON musst Du auftrödeln, wenn da noch was rein soll. An eine mit meinem Algorithmus serialisierte Binärsequenz kannst Du es einfach anhängen oder am Anfang einfügen. Ebenfalls seit Jahren bewährt ;)

MfG

[1UnitedPower]

Hakuna matata!

Ich würde die Frage eher andersherum stellen: Warum ein POST-Request an einem URL mit Query_String?

Eine REST-API besteht im Allgemeinen aus vielen Anfragemöglichkeiten, die nicht alle nur auf POST basieren, zumindest auch die GET-Methode wird wohl von den meisten APIs rege genutzt. GET-Anfragen haben allerdings keinen Body, deshalb ist es auch nicht möglich dort den API-Key zu übertragen. In diesem Fall müsste man den API-Key also anderorts kodieren. Dies ginge in einem Cookie oder in einem benutzerdefinierten Header, oder eben im Querystring der URL. Jetzt hat man blöderweise den Fall, dass der API-Key bei POST-Anfragen im Body übertragen wird und bei GET-Anfragen im Header oder in der URL. Das erfordert schon zwei verschiedene Lösungen für das selbe Problem. Da sollten dann die Alarmglocken angehen.

Wer sowas serverseitig verarbeiten will, muss den Parser seiner PL schon sehr genau kennen, die arbeiten nämlich unterschiedlich von PL zu PL.

PL? Programming-Language? Man muss nicht den JavaScript-Parser der V8-Engine kennen, wenn man eine REST-Schnittstelle nutzen möchte. Ebenso wenig muss man den PHP-Parser der Zend-Engeine kennen.

Du meinst vermutlich, dass man die Schnittstellen des URL-Parsers bzw. des HTTP-Body-Parsers kennen muss. Diese Sache wird einem heutzutage von modernen Web-Frameworks allerdings schon abgenommen und man erhält über eine vereinfachte Schnittstelle Zugriff auf die Anfrage-Parameter. In PHP folgen die bekanntesten Frameworks zum Beispiel diesem Muster.

Und ja, die Hotti-Speziallösung: Einen JSON musst Du auftrödeln, wenn da noch was rein soll.

Wenn man die Daten erst unmittelbar vor der Übetragung kodiert, ergibt sich dieses Problem erst gar nicht. Über streamable JSON habe dich ja auch schon mal unterrichtet, damals ging es zwar um Dekodierer, aber den Weg gibt es auch für die Umkehrrichtung, dem Kodierer.

[hotti]

hi,

PL? Programming-Language? Man muss nicht den JavaScript-Parser der V8-Engine kennen, wenn man eine REST-Schnittstelle nutzen möchte. Ebenso wenig muss man den PHP-Parser der Zend-Engeine kennen.

Wenns Dich interessiert, für Perl steckt der Parser in CGI.pm und sobald der eingebunden wurde, ist es nicht mehr möglich, Daten aus STDIN zu lesen. Ein Zugriff auf POST oder PUT-Daten sind nach Einbinden CGI.pm nur dann möglich, wenn der im Request gesendetet Content-Type abweichend von  application/x-www-form-urlencoded or multipart/form-data ist, in diesem Fall sind die Daten in param('POSTDATA') bzw. param('PUTDATA') zu finden. Das wäre also der Fall, wenn ein Request mit dem Content-Type: application/json gesendet wurde. Mit CGI::param() kann natürlich auch der  QUERY_STRING geparst werden um an Schlüssel und Werte zu kommen.

Ansonsten unterscheidet die param()-Funktion anhand der Request-Methode, d.h., entweder POST oder GET und param() liefert das Ergebnis auch nur dann, wenn der gesendete Content-Type application/x-www-form-urlencoded or multipart/form-data ist.

Wenn ein POST vorliegt, wird param('key') im konkreten Fall keine Daten liefern, es bleibt jedoch stets die Möglichkeit, den QUERY_STRING zu parsen und mit param('POSTDATA') an die Rohdaten zu kommen. Oder es wird auf den Parser CGI.pm verzichtet, so können die Rohdaten direkt aus SDTIN gelesen werden. Oder der Request sendet ein multipart/form-data und CGI::param() kann auf alle Daten zugreifen: param('key'), param('json').

Noch ein Benchmark:           Rate  ini  bin ini 28702641/s   -- -38%  32,87 kB, 114 Objekte, INI-Datei, Parser Config::Tiny bin 46382189/s  62%   --  1,352 MB, 338 Objekte, Binärdatei, Eigener Serializer

Die gespeicherten Datenstrukturen sind dieselben (Entity, Attribute, Value). In Perl gibt es binär arbeitende Serializer, die sind noch wesentlich performanter, aber die Sequenzen sind inkompatibel zu PHP oder JavaScript. Für XML, JSON gibt es :XS Erweiterungen, die auch nochmal einen Schub bringen.

MfG

[hotti]

Hakuna matata!

Eine REST-API besteht im Allgemeinen aus vielen Anfragemöglichkeiten, die nicht alle nur auf POST basieren, zumindest auch die GET-Methode wird wohl von den meisten APIs rege genutzt. GET-Anfragen haben allerdings keinen Body, deshalb ist es auch nicht möglich dort den API-Key zu übertragen. In diesem Fall müsste man den API-Key also anderorts kodieren. Dies ginge in einem Cookie oder in einem benutzerdefinierten Header, oder eben im Querystring der URL. Jetzt hat man blöderweise den Fall, dass der API-Key bei POST-Anfragen im Body übertragen wird und bei GET-Anfragen im Header oder in der URL. Das erfordert schon zwei verschiedene Lösungen für das selbe Problem. Da sollten dann die Alarmglocken angehen.

Wenn Du's genau nehmen willst: Der Request an die google-API ist idempotent. D.h., dass mehrere aufeinanderfolgende Anfragen dasselbe Ergebnis liefern. Hier würde sich POST oder PUT sowieso verbieten, also wenn Du's genau nehmen willst mit irgendwelchen Richtlinien bezüglich REST. Bei der lächerlich geringen Datenmenge ein GET und gut isses. Den JSON-String in Percent-Encoding ist überhaupt kein Problem.

MfG

[1UnitedPower]

Hakuna matata!

Wenn Du's genau nehmen willst: Der Request an die google-API ist idempotent. D.h., dass mehrere aufeinanderfolgende Anfragen dasselbe Ergebnis liefern. Hier würde sich POST oder PUT sowieso verbieten,

PUT Anfragen müssen ebenfalls idempotent sein. POST-Anfragen dürfen natürlich auch ohne beobachtbare Nebenwirkungen sein, das wird von der Spezifikation nirgendwo „verboten“.

Ob die Anfrage an die Google-API idempotent ist, kann man ohne Einblick in die Software nicht sagen. Ich kann mir gut vorstellen, dass hinter der API eine künstliche Intelligenz steckt, die aus den gesammelten WLAN-Daten lernt und sich selbst korrigiert. In dem Fall könnte man wohl nicht von idempotent sprechen.

[hotti]

Hakuna matata!

Ob die Anfrage an die Google-API idempotent ist, kann man ohne Einblick in die Software nicht sagen. Ich kann mir gut vorstellen, dass hinter der API eine künstliche Intelligenz steckt, die aus den gesammelten WLAN-Daten lernt und sich selbst korrigiert. In dem Fall könnte man wohl nicht von idempotent sprechen.

So wird eine Diskussion über idempotente Request-Methoden witzlos. Dasselbe kannste auch mit GET machen.

Btw., bei meinem Remote-DB- und Content-Management per Webservice läuft alles einheitlich über PUT. Einheitliche Datenstrukturen, einheitlicher Request, machen kann ich damit alles. Wäre auch viel zu aufwändig und umständlich, für einen serverseitigen Löschvorgang extra auf Request-Method DELETE umzusteigen. Da ist bei mir nur das control-Object anders definiert und serverseitig wird eine andere Perl-Package eingehängt.

Kommandozeile:

c.pl CMS --url /foo.html --delete

c.pl CMS --url /foo.html --update

Editiert wird lokal. --update als Shortcut im Editor.

c.pl BOT

Teste die Konfiguration meiner WebSite --domain, -d: rolfrost.de oder rolfrost

Liefert zu jedem serverseitig konfigurierten URL den HTTP-Status, das sind zwar alles nur HEAD-Requests, aber die serverseitige Konfiguration wird über PUT angefordert, da geht also auch ersteinmal ein control-Object hoch.

MfG

[1UnitedPower]

Hakuna matata!

Ob die Anfrage an die Google-API idempotent ist, kann man ohne Einblick in die Software nicht sagen. Ich kann mir gut vorstellen, dass hinter der API eine künstliche Intelligenz steckt, die aus den gesammelten WLAN-Daten lernt und sich selbst korrigiert. In dem Fall könnte man wohl nicht von idempotent sprechen.

So wird eine Diskussion über idempotente Request-Methoden witzlos. Dasselbe kannste auch mit GET machen.

Es ist auch witzlos, wir diskutieren hier auch nicht, du verbreitest falsches Halbwissen und ich korrigiere dieses. Du sagtest PUT wäre nicht idempotent, das ist falsch. Du sagtest idempotente Anfragen (1) dürften nicht über POST erfolgen, das ist ebenso falsch.

1. Eine Anfrage kann im Übrigen gar nicht idempotent sein, denn das ist eine Eigenschaft von HTTP-Methoden. Eine Anfrage kann aber ohne observierbare Nebenwirkungen erfolgen.

Du sagtest sinngemäß die Anfrage an die Google-API sei idempotent (im Sinne von 1), das kannst du aber gar nicht wissen. Du kannst nicht aus einer Perspektive argumentieren, die du gar nicht einnehmen kannst, weil du nicht bei Google arbeitest.

Btw., bei meinem Remote-DB- und Content-Management per Webservice läuft alles einheitlich über PUT.

Das ist schlecht, denn PUT-Antworten können vom Browser nicht gecacht werden. Für Anfragen ohne spezielle Semantik benutzt man daher POST. SOAP über HTTP ist ein gutes Beispiel dafür.

[Mattes]

So wird eine Diskussion über idempotente Request-Methoden witzlos. Dasselbe kannste auch mit GET machen.

Es ist auch witzlos, wir diskutieren hier auch nicht, du verbreitest falsches Halbwissen und ich korrigiere dieses. Du sagtest PUT wäre nicht idempotent, das ist falsch.

Um hier folgen zu können, habe ich idempotent mal im Duden nachgeschlagen – war klar, was dabei rauskommt.

[hotti]

So wird eine Diskussion über idempotente Request-Methoden witzlos. Dasselbe kannste auch mit GET machen.

Es ist auch witzlos, wir diskutieren hier auch nicht, du verbreitest falsches Halbwissen und ich korrigiere dieses. Du sagtest PUT wäre nicht idempotent, das ist falsch.

Um hier folgen zu können, habe ich idempotent mal im Duden nachgeschlagen – war klar, was dabei rauskommt.

Die ganze Diskussion kommt mir sowieso wie ein Stammtischgespräch vor. Wenn Du aus diesem sinnlosen Gezänke noch was Gutes fürs Forum tun möchtest: Schreib eine kleine und für kleine Jungs verständliche Zusammenfassung wie navigator.geolocation in Mozilla FF mit der google-API zusammenarbeitet.

MfG

[Mattes]

Wenn Du aus diesem sinnlosen Gezänke noch was Gutes fürs Forum tun möchtest: Schreib eine kleine und für kleine Jungs verständliche Zusammenfassung wie navigator.geolocation in Mozilla FF mit der google-API zusammenarbeitet.

Oha.

"Frag Firefox, Firefox fragt Google für dich"?

Ich glaube, kleine Jungs brauchen das gar nicht wissen, die können sich einfach daran erfreuen, dass navigator.geolocation den ganzen Kram für sie übernimmt – und das nicht nur bei Firefox, sondern bei praktisch allen aktuellen Browsern.

[hotti]

Wenn Du aus diesem sinnlosen Gezänke noch was Gutes fürs Forum tun möchtest: Schreib eine kleine und für kleine Jungs verständliche Zusammenfassung wie navigator.geolocation in Mozilla FF mit der google-API zusammenarbeitet.

Oha.

"Frag Firefox, Firefox fragt Google für dich"?

Ich glaube, kleine Jungs brauchen das gar nicht wissen, die können sich einfach daran erfreuen, dass navigator.geolocation den ganzen Kram für sie übernimmt – und das nicht nur bei Firefox, sondern bei praktisch allen aktuellen Browsern.

Ja, danke, das wars auch schon. Ich habe mich nur für ein paar Details interessiert und habe, weil das evntl. auch Andere interessieren könnte, meine diesbezügliche Analyse öffentlich gemacht. Schritt für Schritt zum Detail, mit einer Annahme, die sich im Verlauf als nicht richtig erwiesen hat. Die Verständigung ist hier erschwert, dadurch dass sich ein paar anonyme Knaller nur profilieren wollen indem sich mich für blöd erklären. Die Sternchen beeindrucken mich nicht, die verdeutlichen nur eine Verhaltensweise, die für jedes öffentliche Forum typisch ist. Schade nur für ein Forum, was für sich den Anspruch erhebt, ein Fachforum zu sein.

Schöne Grüße.

[Mattes]

Schreib eine kleine und für kleine Jungs verständliche Zusammenfassung wie navigator.geolocation in Mozilla FF mit der google-API zusammenarbeitet.

Oha.

"Frag Firefox, Firefox fragt Google für dich"?

Ich glaube, kleine Jungs brauchen das gar nicht wissen, die können sich einfach daran erfreuen, dass navigator.geolocation den ganzen Kram für sie übernimmt – und das nicht nur bei Firefox, sondern bei praktisch allen aktuellen Browsern.

Ja, danke, das wars auch schon. Ich habe mich nur für ein paar Details interessiert

Nun, die Details sind ja in schon zitierter Google-Doku beschrieben; Mozilla unterstützt mit dem eigenen Dienst einen gleichartigen Zugang. Dem ist an sich nichts hinzuzufügen, kompliziert ist das Prozedere ja nicht.

Für die Nutzung im Browser ist das aber, wie oben schon angedeutet, wurscht, eigentlich sollte man das sogar tunlichst vermeiden: Bei Mobilgeräten wird navigator.geolocation sicher auch auf den GPS-Empfänger zurückgreifen bzw. auf einen Geolocation-Dienst des Betriebssystems.

So. Jetzt habe ich sie alle erschlagen: Kleine Jungs und große Jungs und was dazwischen noch kreucht und fleucht.

Die Sternchen beeindrucken mich nicht, die verdeutlichen nur eine Verhaltensweise, die für jedes öffentliche Forum typisch ist.

Da bin ich jetzt aber froh, mal kein Fleißsternchen bekommen zu haben.

[hotti]

Hakuna matata!

Btw., bei meinem Remote-DB- und Content-Management per Webservice läuft alles einheitlich über PUT.

Das ist schlecht, denn PUT-Antworten können vom Browser nicht gecacht werden.

Mit dem Browser hat das alles gar nichts zu tun. Mein UserAgent läuft in einem lokalen mit Perl programmierten Framework für's Remote-MySQL- und Content-Management auf der Kommandozeile. Da gibt es nichts zu cachen.

MfG

[1UnitedPower]

Hakuna matata!

Das ist schlecht, denn PUT-Antworten können vom Browser nicht gecacht werden.

Mit dem Browser hat das alles gar nichts zu tun. Mein UserAgent läuft in einem lokalen mit Perl programmierten Framework für's Remote-MySQL- und Content-Management auf der Kommandozeile. Da gibt es nichts zu cachen.

<°))>>><

[dedlfix]

Tach!

Bei einem Request https://www.googleapis.com/geolocation/v1/geolocate?key=AIzaSyD-s-mXL4mBzF7KMRkhTCIbG2RKnRGXzJc den ich mit diesem Key und jedem beliebigen Useragent ausführen kann, wird google die REMOTE_ADDR des UserAgent heranziehen um den Standort zu bestimmen.

Der UserAgent hat keine REMOTE_ADDR. Der empfangene Server generiert diese Angabe aus der Sender-IP-Adresse der ankommenden Pakete. Dass man einen im Klartext übertragenen Schlüssel kopieren und anderswo verwenden kann, bei einer Technik, in der es nicht auf direktem Wege möglich ist, die Clients eindeutig zu identifizieren, ist auch keine Sache, die einen sehr verwundern sollte.

dedlfix.

[hotti]

Tach!

Bei einem Request https://www.googleapis.com/geolocation/v1/geolocate?key=AIzaSyD-s-mXL4mBzF7KMRkhTCIbG2RKnRGXzJc den ich mit diesem Key und jedem beliebigen Useragent ausführen kann, wird google die REMOTE_ADDR des UserAgent heranziehen um den Standort zu bestimmen.

Der UserAgent hat keine REMOTE_ADDR.

Also mit Dir so ein Thema erörtern, das ist eher eine Zänkerei. Wenn ich Dein Chef wäre, ich würde solche Diskussionen nicht dulden und Konsequenzen ziehen. Zum Glück muss ich mit Dir nicht zusammenarbeiten.

MfG

[dedlfix]

Tach!

Also mit Dir so ein Thema erörtern, das ist eher eine Zänkerei. Wenn ich Dein Chef wäre, ich würde solche Diskussionen nicht dulden und Konsequenzen ziehen. Zum Glück muss ich mit Dir nicht zusammenarbeiten.

Keiner meiner bisherigen Chefs hat das getan. Liegt wohl auch daran, dass sie deutlich weniger oft Aussagen mit Verbesserungspotential gemacht haben.

dedlfix.

[Mattes]

Jetzt guck doch endlich mal in Deinen Browser, welcher Key da hinterlegt ist und ob das derselbe ist wie in meinem FF. Diese Frage habe ich gestern schonmal gestellt.

Oder guck mal in places.sqlite.

places.sqlite ist eine Datenbank mit elf Tabellen und, je nach Nutzung, mehreren Tausend Einträgen. Da "mal reinzugucken" ist eine etwas ungenaue Aufforderung. Eigentlich dürfte der Schlüssel in dieser Datenbank auch nicht auftauchen, weil sie nur besuchte Adressen enthält, aber kein Netzwerkprotokoll ist. Anfragen, die Firefox selbst erzeugt, werden dort nicht gespeichert.

Es wäre hilfreich, wenn du verraten würdest, wo du denn den Schlüssel herbekommst (und zwar bitte genau und nicht wieder "im Firefox").

Die URL, die Firefox anspricht, um den Standort festzustellen, ist in den Einstellungen (about:config) unter geo.wifi.url abgelegt. Bei mir steht da nur "https://www.googleapis.com/geolocation/v1/geolocate?key=%GOOGLE_API_KEY%".

Lies' dir mal diese Ankündigung von Doug Turner, seines Zeichens ein Obermotz bei Mozilla, durch. Er erklärt recht deutlich, dass der Schlüssel fest in den ausführbaren Code eingebaut wird und nicht einmal im öffentlich verfügbarem Quellcode steht. Nicht nur Debian, Fedora & Co, die Firefox selbst übersetzen, müssen demnach einen eigenen Schlüssel bei Google beantragen, sondern jeder einzelne Entwickler.

Ich wäre fast geneigt gewesen, eine Schlüsseländerung anzunehmen, weil es denkbar ist, dass Google von Mozilla verlangt, einzelne Benutzer identifizierbar zu machen. Der Schlüssel wird nicht nur für die Standortbestimmung verwendet, sondern auch für die Safebrowsing-Funktion (und noch einen Dienst, IIRC). Es wäre ein Leichtes, jeden Schlüssel aus einer Basis, die Mozilla identifiziert, und einem variablen Teil pro Installation zusammenzusetzen.

Aber: Dass dein Schlüssel nicht einzigartig und es somit sehr unwahrscheinlich ist, dass er von deinem Browser ausgehandelt worden ist, zeigt eine kurze Suche im Web.

[hotti]

Lies' dir mal diese Ankündigung von Doug Turner, seines Zeichens ein Obermotz bei Mozilla, durch. Er erklärt recht deutlich, dass der Schlüssel fest in den ausführbaren Code eingebaut wird und nicht einmal im öffentlich verfügbarem Quellcode steht. Nicht nur Debian, Fedora & Co, die Firefox selbst übersetzen, müssen demnach einen eigenen Schlüssel bei Google beantragen, sondern jeder einzelne Entwickler.

LiveHTTPHeaders macht alle Requests sichtbar, wenn Du auf meine Seite gehst, wo navigator.geolocation eingebaut ist. Genauso würde auch ein Netzwerktool wie Wireshark mitschneiden, was an HTTP-Requests alles rausgeht und auch damit wird dieser API-Key sichtbar. Der Request selbst erfolgt dann mit SSL.

Auf places.sqlite kannst Du ein grep machen, da steht der API-Key im Klartext drin. So verrate ich hiermit keine Geheimnisse sondern nur das, was ich und jeder Andere auch sehen kann.

Schöne Grüße.

[1UnitedPower]

Hakuna matata!

LiveHTTPHeaders macht alle Requests sichtbar, wenn Du auf meine Seite gehst, wo navigator.geolocation eingebaut ist.

Ist es möglich, dass du die Geolocation API des W3Cs und die Google Maps Geolocation API durcheinander wirfst? Ersteres ist eine rein cleintseitige API, die keine zusätzlichen HTTP-Anfragen benötigt. Googles Produkt ist ein Webservice, der notwendigerweise über HTTP kontaktiert wird. Den API-Key braucht man nur für Googles Produkt und das benutzt du ja überhaupt nicht. navigator.geolocation gehört nämlich zum W3C-Standard.

[dedlfix]

Tach!

Ist es möglich, dass du die Geolocation API des W3Cs und die Google Maps Geolocation API durcheinander wirfst? Ersteres ist eine rein cleintseitige API, die keine zusätzlichen HTTP-Anfragen benötigt. Googles Produkt ist ein Webservice, der notwendigerweise über HTTP kontaktiert wird. Den API-Key braucht man nur für Googles Produkt und das benutzt du ja überhaupt nicht. navigator.geolocation gehört nämlich zum W3C-Standard.

Für mich sieht es so aus, als ob der Chrome die Anfrage an die Geolocation-API des W3C direkt beantworten kann und der Firefox sich zum Beantworten der Anfrage an den Google-Service wendet. Ob Chrome irgendwann vorher "heimlich" nach Hause telefoniert hat, hab ich nicht untersucht. Andererseits wüsste ich auch nicht, wie er meinen Standort herausgefunden haben will. Ich habe weder dem Chrome noch dem Betriebssystem dazu irgendwelche Angaben gemacht, noch kann er sich eines nicht vorhandenen GPS/wasauchimmer-Empfängers bedienen.

dedlfix.

[1UnitedPower]

Hakuna matata!

Für mich sieht es so aus, als ob der Chrome die Anfrage an die Geolocation-API des W3C direkt beantworten kann und der Firefox sich zum Beantworten der Anfrage an den Google-Service wendet.

Das könnte so implementiert sein, dann gehört der ominöse API-Key über den hier die ganze Zeit gesprochen wird, wohl zu Firefox. Das leuchtet mir ein.

[Mattes]

LiveHTTPHeaders macht alle Requests sichtbar

Ok, da haben wir dann einen Fall, wo LiveHTTPHeaders mehr anzeigt als Firebug und die Firefox-eigene Netzwerkanalyse. In letzteren Beiden bleibt die Anfrage verborgen.

Auf places.sqlite kannst Du ein grep machen, da steht der API-Key im Klartext drin.

Nope, nichts. Eventuell hast du die URL mal direkt aufgerufen, denn, wie schon geschrieben, in places.sqlite stehen die besuchten Seiten und Lesezeichen drin, nicht sämtliche abgerufenen URLs.

Mein Firefox-Schlüssel ist unterscheidet sich im Übrigen von deinem. Der Grund findet sich in about:buildconfig, ganz am Ende:

Configure arguments

--host=x86_64-linux-gnu --prefix=/usr --blafasel --with-google-api-keyfile=/build/buildd/firefox-35.0+build1/debian/g

[1UnitedPower]

Hakuna matata!

s. Thema. Der Browser, welcher das unterstützt, sendet einen Request

Nein tut er nicht. navigator.geolocation.getCurrentPosition() gehört zur W3C API. Der exemplarische HTTP-Request, den du gezeigt hast, gehört zur Google Geolocation API. Das sind zwei verschiedene paar Schuhe.

[Alexander (HH)]

Moin Moin!

1.) Wie kann man denn anhand der IP-Adresse den geografischen Standort eines Rechners ermitteln? Ich möcht jetzt nicht irgendein Tool, wo ich die IP eingebe und hinten kommt ein Standort raus. Ich möchte das technisch im Detail verstehen.

Datenbanken, mutmaßlich mit IP-Adressen und Netzmasken, obwohl 2^32 Datensätze eine aktuelle Datenbank wohl kaum überfordern würden.

Für Rechenzentren ist das ziemlich einfach, da läuft großenteils alles mit fest zugeteilten IP-Adressen und ganze Pools von Adressen können auf einen Standort festgelegt werden. Für Endkunden-Anschlüsse werden meistens regionale Adresspools benutzt, das erleichtert den Anbietern das interne Routing. Sprich wenn 1.2.3.2, 1.2.3.4. 1.2.3.5 und 1.2.3.6 in Köln vergeben sind, kann man mit hoher Wahrscheinlichkeit davon ausgehen, dass 1.2.3.3 und 1.2.3.7 auch in Köln liegen.

2.) Wie funktioniert dies beim Smartphone, hier ändert sich der Standort doch u.U. ständig wenn ich z.B. mit dem Auto fahre.

Nur anhand der IP-Adresse gar nicht. Mutmaßlich steht da in gängigen Datenbanken schlicht "irgendwo in Deutschland". Aber GSM, UMTS und LTE erlauben die lokalisierung des Handys anhand der Entfernung zu den Basisstationen (Signallaufzeit, Signalstärke). Außerdem können Smartphones GPS und Glosnast empfangen und auswerten. Und schließlich erlauben Sensoren auch, die Bewegungen des Gerätes zu verfolgen. Dazu kommt, dass anhand der Namen und der MAC-Adressen der sichtbaren WiFi-Netze und der Signalstärke recht gut abgeschätzt werden kann, wo man sich befindet. All diese Informationen kann das Betriebssystem (bzw. irgendwelche Libraries) interessierten Anwendungen zur Verfügung stellen.

Datengrundlage für die WiFi-Raterei sind übrigens z.B. die Erkundungsfahrten von Google in allen größeren Städten UND die von den Millionnen Smartphones selbst übermittelten Daten à la "hier sind 20 WLANs mit folgenden Namen und MAC-Adressen, sag mir mal, wo ich bin". Außerdem werden diese Daten wahrscheinlich auch dann gesammelt und übertragen, wenn die Position dank GPS/Glosnast schon bekannt ist. Damit können die Datenbanken recht gut auf dem aktuellen Stand gehalten werden.

Die IP-Adresse wird zwangsläufig mit übertragen. Ist man in ein WLAN eingebucht, werden die Standort-Angaben mit der öffentlichen IP-Adresse des WLANs übertragen.

Wie detailiert allein die WLAN-Informationen sind, läßt sich bei mir zuhause wunderbar feststellen. Ich habe zwei nagelneue Smartphones ausgepackt, WLAN eingeschaltet und spaßeshalber meine Position feststellen lassen. Ohne GPS je aktiviert zu haben und ohne eine SIM-Karte wurde die Position auf unter 10 m genau auf einer Wiese neben dem Haus angezeigt.

Ganz offensichtlich rennen hier genügend Leute rum, die die gesamte Siedlung mit ihren Smartphones flächendeckend abgescannt und mehr oder weniger freiwillig an die große Datenkrake gepetzt haben. Schon allein, weil kaum jemand auf die Idee kommt, WLAN und GPS abzuschalten, wenn man es nicht braucht.

Die IP-Raterei hat auch ihre Grenzen: Große Firmen mit zentralistischer Organisation haben oft nur einen (oder wenige) zentralen Übergang ins Internet, so dass die Lokalisierung nur anhand der IP-Adresse genau diesen zentralen Standort angibt. Mein erster Arbeitgeber ist so organisiert. Sitzt man in Hamburg und bestellt per Web eine Pizza, läuft das erst einmal intern nach München, geht dort durch Proxy und Firewall und mit einer in München vergebenen IP-Adresse ins Internet. Glücklicherweise hat nie ein Pizza-Dienst überprüft, wo die IP-Adresse herkommt, sondern auch Bestellungen von der Münchener IP-Adresse brav abgearbeitet und in Hamburg ausgeliefert.

Genau das gleiche Szenario bringen auch VPNs, z.B. wenn mein Laptop per VPN in mein Netz zuhause eingewählt ist, läuft sämtlicher Internet-Traffic durch meine Firewall zuhause, egal wo auf der Welt ich mich befinde. IP-Rate-Tools zeigen dann einen Standort an, der mit meinem wirklichen Standort kaum etwas zu tun hat.

Diesen Effekt kann man auch ausnutzen, um Geo-Blocking zu umgehen, z.B. um amerikanische Serien vor dem Deutschlandstart in der Originalfassung von amerikanischen Servern zu laden bzw. zu streamen. Man braucht "nur" einen VPN-Einwahlpunkt in Amerika.

Alexander

[Robert R.]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Hinzu kommen nun auch noch diverse Hotspots von T und KD, die (von KD) oft ohne das Wissen ihrer Gastgeber (Anschlussinhaber) (er|ge)öffnet werden.

Soll heißen: KD erstellt mittels ihres Hitron-Routers einen 100MBit-Internetzugang nebst Telefon und WLAN für den Kunden. Parallel dazu versorgt das Gerät auch einen vermeintlich offenen KD-HOTSPOT, an dem sich dein IGitt-Phone also im Vorbeifahren mal eben schnell anmeldet. Und weil Du KD-Kunde bist (mit eigenem Standort hunderte von Kilometern entfernt), kennt das Teil auch deine Zugangsdaten und Du bist "drin" - und der Standort deines IGitt-Phones registriert.

Der KD-Hotspot arbeitet übrigens gerne mit IP-V6-Adresse. Was lässt uns das vermuten? Jaaaa, die Lease-Time ist lebenslang.

Spirituelle Grüße Euer Robert