„Making search more secure: Accessing search query data in Google Analytics“ lautet die Überschrift in einem aktuellen Blogbeitrag im offiziellen Google Analytics (GA) Blog. More secure? I don’t think so! Wie Google Anforderungen an sichere Verbindungen im Internet missinterpretiert, und alle anderen Größen im Internet übrigens auch.

Im Google Analytics Blog wurde am 18. Oktober 2011 eine Ankündigung gemacht, die vielen Experten und GA-Nutzern den Tag etwas versauern durfte. Alle Informationen über den Suchbegriff werden beim Anklicken eines Suchergebnisses in Googles HTTPS-Modus nicht mehr mitgeschickt. Das „referrer“-Tag im HTTP Request wird mit einem „not provided“ an der Stelle ausgestattet, wo sich früher das Keyword befand, das man so schön in Web Analytics Software auswerten konnte. Eine Informationsquelle versiegt und man meint sich darüber empören zu müssen im ersten Moment.

Wäre da nicht das RFC 2616 Protokoll der Internet Engineering Task Force, die maßgebliche Standards wie das HyperTextTransferProtocoll (HTTP), TransmissionControlProtocol (TCP) und InternetProtocol (IP) bestimmt. Das RFC 2616 besagt: „Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol“. Ein Satz, den manche große Webseiten noch nicht so ganz verinnerlicht haben.

In unserem Fall ist der Client der Besucher bzw. dessen Browser, der Google unter der SSL Verbindung https://www.google.com/ ansurft. Klickt er auf ein Suchergebnis, dessen Ziel-URL nicht ebenfalls eine SSL verschlüsselte Seite ist, so sollte laut oben zitiertem Protokoll keinerlei Information über den Referer (in diesem Fall www.google.com) mitgeschickt werden. Diese Einstellung treffen z. B. Firefox Benutzer vollautomatisch, da Firefox in der aktuellen Version 8.0.1 in der Konfigurationsdatei die Variablen entsprechend voreinstellt.

 

Firefox Config

Doch diese Einstellung wird elegant von manchen großen Websites umgangen, dazu gehört Google, Facebook und auch Twitter. In allen Fällen wird ein Klick auf einen Link erst vorgetäuscht, dank JavaScript über verschiedene URLs mehrere Weiterleitungen erzeugt und auf das eigentliche Ziel verwiesen. Diese Schleifen dreht man sehr gerne bei Verlinkungen, insbesondere z.B. bei affiliate Links, um Informationen zu sammeln und evtl. Cookies zu setzen.

Im Detail betrachten wir dazu exemplarisch Google.de und deren Suchergebnisseite. Wir rufen https://www.google.de/search?q=test auf und klicken auf das erste Suchergebnis http://www.test.de. Zu erwarten ist, dass wir als nächstes einen HTTP GET Request an den entsprechenden DNS senden für test.de – doch die Rechnung wurde ohne Google gemacht. Elegant wird nämlich über JavaScript vorher noch eine unsichere Verbindung über HTTP GET „/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDgQFjAA&url=http%3A%2F%2Fwww.test.de%2F&ei=DWvwTtS0CYuLswaNhZXZDw&usg=AFQjCNExSl_aJh-irODpoIla40aIiDVM-w&sig2=m74yiQYMt6l1N7JllreP6A HTTP/1.1“ abgerufen, ohne den HTTPS-Referrer.

Im Anschluss dazu wird nun http://www.test.de/ aufgerufen, mit dem Referer: „http://www.google.de/[…]“. Obwohl dem Benutzer angezeigt wird, sich auf einer verschlüsselten HTTPS-Website zu befinden und auf einen HTTP-Link zu klicken, wird vorher noch die unsichere HTTP-Website von Google aufgerufen und von da aus weitergeleitet, mit allen Referer-Informationen, zu www.test.de.

Der Live HTTP Headers Mitschnitt sieht dabei wie folgt aus:

Führt man dieses Experiment mit einer deaktivierten Einstellung für JavaScript im Browser aus, so wird bei Google korrekt die Ziel-URL aufgerufen, ohne das Mitsenden von Referer-Informationen. Etwas dreister ist hier Facebook, deaktiviert man JS so werden URLs nicht mehr maskiert und über JS weitergeleitet sondern zeigen eine gezielte Umleitung auch schon im Browser. Referer Informationen werden auch dann mitgeschickt, über Umwege und Umleitungen über verschiedene URLs.

Etwas kurios, dass die ganz Großen hier mit Umleitungen nicht geizen um Informationen über Klickverhalten zu sammeln. Jedoch sich nach Außen als Vorreiter des sicheren Surfens titulieren. Greenwash gibt es für große Brands in der Industrie, wobei Marken durch Marketing mit Umweltbewustsein in Verbindung gebracht werden sollen. Dann ist „Savewash“ das Pendant dazu für Internet Marken, die gerne mehr Datenschutz nach außen tragen würden, hinter dem Rücken der Nutzer es jedoch nicht sind. Denn die wenigsten Internetnutzer werden das RFC 2616 gelesen haben.

Wie denkt Ihr zu diesem Thema? Bin ich hier über etwas gestoßen, was schon lange bekannt ist? Oder ist es ein unwesentliches Detail, was hier betrieben wird? Ein Faux-pas, bei dem man ein Auge zudrücken sollte? Steckt doch mehr dahinter?

Ich freue mich über Eure Kommentare!