Standortabfragen im Browser mittels W-LAN

Standortabfragen oder sogenannte Geolokalisierungen durch einen Browser übermitteln auch Daten von Dritten, wenn diese lediglich ihren W-LAN-Router eingeschaltet haben. Und zwar übertragen die Browser die MAC-Adressen, vereinzelt auch die Namen (SSID) und stets die Signalstärken aller in Reichweite befindlichen und gefundenen W-LAN-Netze.

In einem kürzlich realisierten Internet-Projekt (responsive Website) waren wir verblüfft über die Exaktheit der vom Kunden gewünschten Standortabfrage. In einem Haus in der Berliner Innenstadt von ca. 50m Länge, 20m Breite und mit 4 Etagen wurde durch Firefox- oder Chrome-Browser (jeweils am Laptop) unser Standort nahezu exakt in den korrekten Büroraum innerhalb der Google-Karte „gesetzt“. Dabei fiel auf, dass vor allem Geräte mit eingeschaltetem W-LAN-Adapter die besten Ergebnisse lieferten, unabhängig davon, ob sie selbst mit W-LAN, per Kabel oder bspw. per UMTS im Netz waren.

Ein Blick in die Spezifikation des W3C, die diese Javascript-Erweiterung im Rahmen der HTML5-Erneuerungen ermöglicht hat, zeigt, dass jeder Browser selbst entscheiden kann, welche Daten er zur Standortbestimmung heranzieht und welchen Server (Dienst) er anfragt, um mit den gesammelten Daten eine Geokoordinatenangabe zu erhalten. Um herauszufinden, was ein Browser an wen sendet, war es insofern am einfachsten die Anfragen des Browsers mitzuprotokollieren.
Mit Hilfe eines Proxy-Servers für Debug-Zwecke (z.B. Fiddler) wurden die Requests von Firefox, Chrome, Opera, Internet Explorer jeweils unter Windows 7 (Desktop) und von Firefox, Chrome und Opera Classic jeweils unter Android (Smartphone) mitgeschnitten.

Beispielsweise sendete ein Opera Classic Browser unter Android folgende Informationen (Daten geändert) an Google:

wifi    mac:00-24-FE-4B-A7-51|ss:-58|ssid:TheWALL|age:0|chan:2
wifi    mac:7C-4F-B5-83-2E-ED|ss:-84|ssid:ALICE-WLAN32|age:0|chan:1
wifi    mac:00-1B-2F-E4-32-42|ss:-94|ssid:GebruederG|age:0|chan:11
wifi    mac:50-7E-5D-90-A4-8F|ss:-95|ssid:o2-WLAN36|age:0|chan:4
wifi    mac:08-91-D7-58-33-CB|ss:-95|ssid:k31Nittaku|age:0|chan:1
wifi    mac:24-15-11-E9-EA-45|ss:-97|ssid:FRITZ!Box 63360 Cable|age:1|chan:1
wifi    mac:00-04-0A-A0-D3-90|ss:-98|ssid:HM RA 1974|age:1|chan:10
wifi    mac:1C-C6-2C-1E-44-20|ss:-101|ssid:Schnuebli|age:1|chan:1
wifi    mac:00-60-10-20-00-03|ss:-102|ssid:K31oeko|age:1|chan:11
location    lat:52.348932|lng:13.210873

Die mit „wifi“ gekennzeichneten Zeilen entsprechen in obigem Beispiel denen vom Smartphone-W-LAN-Adapter gefundenen W-LAN-Netzwerken („Mobile Hotspots“) in meiner Umgebung zum Testzeitpunkt. Die Sortierung entspricht dabei der Signalstärke („ss“-Wert). Je negativer dieser Wert, desto schwächer das Signal. Ob eine Verwendung der „age“-Angabe (Zeit in Millisekunden, wie lange die Messung zurückliegt) und des Kanals („chan)“, auf dem das W-LAN sendet, zur Lokalisierung stattfindet, konnte ich nicht herausfinden. Andere getestete Browser sendeten diese Informationen eher nicht mit.

Firefox (MAC-Adresse und Signalstärke) und Chrome (wie Firefox sowie „age“-Wert) waren am „sparsamsten“ mit den übertragenen Informationen. Beim Internet Explorer 10 wurden neben den W-LAN-Informationen (MAC-Adresse bzw. BSSID und Signalstärke) noch detaillierte Angaben über mein Betriebssystem übertragen:

<DeviceProfile ExtendedDeviceInfo="" LFVersion="10.0.9200.16750" OSVersion="7401.18347.amd64fre.win7sp1_gdr.130528-1532" DeviceType="PC" Platform="Windows7" ClientGuid="11111111-1111-1111-1111-111111111111"/>

Der Internet Explorer sendete die gesammelten Daten an den Server https://inference.location.live.net/, die anderen Browser nutzten Google: https://www.googleapis.com/geolocation/v1/geolocate

Die gesammelten Daten wurden von allen Browsern per HTTPS übertragen, so dass der Proxy-Server zum Mitlesen den verschlüsselten Datenstrom unterbrechen und ein eigenes SSL-Zertifikat einsetzen musste. Unter Android konnte mit Chrome und Firefox deswegen nicht getestet werden, da diese die HTTPS-Anfragen an Google mit dem ungültigen Zertifikat vom Proxy-Server pauschal aus Sicherheitsgründen blockierten. Opera unter Android gestattete stattdessen eine manuelle Freigabe dieses Zertifikates, so dass ein Test möglich war.

Bei aktivem GPS-Signal wurde zudem auch die ermittelte GPS-Information neben den W-LAN-Daten übertragen:

location    lat:52.348932|lng:13.210873

Zwar wurden in der Vergangenheit aktiv W-LAN Daten durch die Diensteanbieter für Standortlokalisierungen gesammelt (per Fahrzeug), heute ist es jedoch allgemeiner Tenor von Google und Apple, dass die Benutzer dieser Dienste selbst die GPS-Information zusammen mit den W-LAN-Informationen sammeln, an die Dienstebetreiber durch ihre Geräte senden lassen und damit künftige Standort-Abfragen für sich und vor allem andere Nutzer weiter verfeinern.

Das Fazit dieses kleinen Tests lautete: Wer glaubt, nichts von sich preiszugeben, wenn er Standortabfragen von Websiten verneint, irrt. Wer ein eigenes W-LAN einsetzt kann sich in urbanen Gegenden sicher sein, dass diese Daten entweder durch einen Nachbar oder anderweitig schon längst in (amerikanische) Datenbanken übertragen wurden sind. Gerade das Übertragen der SSID (siehe oben, Opera) wird dabei äußerst kritisch von Datenschützern gesehen.
Die Präzision solcher Abfragen verwundert nicht, wenn man sieht, welche Daten gesammelt und gesendet werden.

 

Weitere Informationen:

W3C-Standard: http://www.w3.org/TR/geolocation-API/

W-LAN-Erfassung durch Apple: http://www.spiegel.de/netzwelt/web/w-lan-erfassung-apple-nutzt-iphone-besitzer-als-umgebungsscanner-a-707417.html

Mozilla-Dienst: https://location.services.mozilla.com/

Googles „versehentliche“ Speicherung: http://www.datenschutzbeauftragter-info.de/google-speichert-versehentlich-daten-aus-wlans/