Zusammenfassung

  • RFC 1945 vom Mai 1996 beschrieb Referer als ein Feld, mit dem ein Client dem Zielserver die URI der verlinkenden Seite mitteilen konnte. Rücklinklisten, Protokolle und die Reparatur fehlerhafter Verweise waren ausdrücklich genannte Zwecke. Im selben Abschnitt stand die Warnung vor einer privaten Quelladresse.
  • RFC 2068 vom Januar 1997 behielt den Mechanismus bei und nannte Referer ausdrücklich eine falsche Schreibweise von „referrer“. Eine eingetippte Adresse hatte keine verlinkende Seite; ein URI-Fragment durfte nicht mitgeschickt werden. Der Sicherheitsteil behandelte die Offenlegung der URI eines privaten Dokuments.
  • Eine W3C Candidate Recommendation vom 26. Januar 2017 definierte Regeln für die ganze URL, nur die Herkunft eines Webauftritts oder keine Referrer-Information. Das Dokument belegt den Entwurf zu diesem Datum, keine flächendeckende Einführung in Browsern.

Der Zielserver wollte einen Absender

Die HTTP/1.0-Spezifikation RFC 1945 vom Mai 1996 gab einem Server eine nützliche Spur. Folgte ein Browser einem Link, konnte er die URI der verlinkenden Seite im Anfragefeld Referer mitsenden. Der Zielserver konnte daraus Listen seiner eingehenden Links erstellen, Besuche protokollieren, bestimmte Cache-Abläufe optimieren und veraltete oder falsch geschriebene Links finden. Diese Zwecke standen direkt im Standard.

Eine digitale Bibliothek verlegt ein Dokument. Auf fremden Seiten stehen weiter Links zur alten Adresse. Wenn eine Anfrage die Herkunftsseite nennt, kann die Bibliothek feststellen, wo die Korrektur fällig ist. Sie besitzt die andere Seite nicht, erhält aber über den Besuch einen Ausschnitt aus der Rückseite des Linknetzes. In einem Netz unabhängiger Betreiber war das ein praktisches Stück Wartungswissen.

Der Standard setzte Grenzen. Wer die Zieladresse selbst in die Tastatur tippte, kam nicht von einem Dokument mit eigener URI; in diesem Fall durfte Referer nicht gesendet werden. Auch das Fragment der Quell-URI sollte fehlen. Ein Klick aus einer Seite und ein direkter Aufruf sind unterschiedliche Ankünfte. Der Server sollte keine vorherige Seite aus einem leeren Ursprung erfinden.

Unmittelbar bei den Wartungsvorteilen stand der Preis. Der Ursprung eines Links konnte selbst privat sein oder die Adresse einer sonst privaten Informationsquelle verraten. Die Autoren empfahlen nachdrücklich eine Wahlmöglichkeit für Nutzer, ob das Feld gesendet wird, und nannten einen Browser-Schalter zwischen offenem und anonymem Surfen als Beispiel. Die Datenschutzfrage war 1996 Teil der ursprünglichen Beschreibung, kein nachträglich angehängtes Misstrauen gegenüber einer harmlosen Funktion.

Das fehlende „r“ war nicht das größte Problem

Der HTTP/1.1-Text RFC 2068 vom Januar 1997 gab die sprachliche Panne zu: Referer war falsch geschrieben, gemeint war „referrer“. Der Name im tatsächlich ausgetauschten Header blieb. Sein Zweck blieb ebenfalls: Rückverweise für Listen und Logs sowie die Suche nach schlechten Links. Auch die Regeln für eingegebene Adressen und Fragmente wurden weitergeführt.

Über den Fehler lässt sich leicht schmunzeln. Wichtiger ist die Richtung der Information. Eine Anfrage an den neuen Server trägt die Adresse einer Seite, die zu einem anderen Betreiber gehören kann. Das Ziel hat ein echtes Interesse daran zu erfahren, wer es verlinkt. Es benötigt für jeden Zweck aber nicht automatisch den vollständigen Pfad eines persönlichen Profils oder einer internen Arbeitsseite. Der Name der Herkunftsinstitution und die genaue zuletzt besuchte Seite sind verschiedene Angaben.

RFC 2068 machte das im Sicherheitsteil deutlicher. Das Feld erlaubte die Untersuchung von Lesemustern und das Zeichnen von Rücklinks. Selbst nach Entfernung ausdrücklich persönlicher Daten konnte die URI eines privaten Dokuments sichtbar bleiben. Ein Profilpfad, ein Aktenname oder ein Sitzungsparameter kann für sich allein viel verraten. Der sichtbare Linktext muss dafür kein Geheimnis enthalten; der Header transportiert den Kontext neben der eigentlichen Anfrage.

Die beiden RFCs sind Spezifikationen und keine Statistik darüber, welche Browser damals welche vollständigen URLs wie oft sendeten. Der dokumentierte Interessenkonflikt braucht diese Statistik nicht. Der Zielserver will eine genaue Reparaturspur; die Quellseite kann einen guten Grund haben, den Weg aus einem privaten Bereich nicht bis zur Haustür des Zielservers zu schildern.

Ein Domainname ist noch keine Seitenadresse

Eine vollständige URL enthält mehr als den Domainnamen. Der Pfad kann auf ein Profil, eine Arbeitsgruppe oder ein vertrauliches Dokument hinweisen. Die Abfrage kann einen Sitzungsbezeichner enthalten. Wenn der Browser alles als Referer übermittelt, erfährt das Ziel nicht nur „von welchem Webauftritt?“, sondern „von welcher konkreten Seite?“. Der Leser klickt wegen des Zielinhalts; die Metadaten berichten zusätzlich über den verlassenen Ort.

Der Empfänger kann die Angabe in Logs speichern. Die Quellseite kennt die Bedeutung ihrer eigenen Adressen am besten. Ihr Betreiber weiß, welche Pfade eine Person erkennen lassen und welche Parameter nicht über eine Standortgrenze wandern sollten. Der 1996 vorgeschlagene Schalter beim Nutzer bot eine grobe Antwort. Eine Regel für die konkrete Seite konnte den Umfang je nach Kontext enger festlegen.

Die Möglichkeiten haben unterschiedliche Folgen. Die ganze URL hilft, einen kaputten Link punktgenau zu finden. Nur die Herkunft — Schema, Host und Port — nennt den Webauftritt, verbirgt aber Pfad und Abfrage. Ohne Referrer-Angabe verschwindet auch der Name des Webauftritts. Ein präziseres Wartungsbuch beim Ziel ist zugleich ein ausführlicherer Bericht über die Seite, die der Besucher verlassen hat.

Die Quelle schreibt die Regel

Die W3C Candidate Recommendation „Referrer Policy“ vom 26. Januar 2017 begann mit einem einprägsamen Fall. Eine Profilseite in einem sozialen Netz verlinkt zur Website einer Band. Die Band darf erfahren, dass das soziale Netz Besucher schickt, ohne die vollständige Profil-URL und damit möglicherweise die Identität des Profilinhabers zu sehen. Daneben nennt der Entwurf Anwendungen mit Sitzungskennungen oder Zugriffsrechten direkt in der URL. Die Adresse kann hier selbst Zugangswert besitzen.

Der Text definiert Abstufungen. no-referrer lässt den Header weg. same-origin sendet die volle URL innerhalb derselben Herkunft und nichts zu einem anderen Ursprung. origin nennt nur Schema, Host und Port, ohne Pfad und Abfrage; strict-origin begrenzt zusätzlich den Übergang aus einem geschützten Kontext zu einem weniger vertrauenswürdigen Ziel. Weitere Optionen kombinieren Verhalten für interne und externe Anfragen. Aus dem alten Ja-oder-Nein wurde die Frage, welcher Teil der Adresse an welchen Server gelangt.

Eine Seite konnte die Entscheidung über den Antwort-Header Referrer-Policy, ein Meta-Element, Attribute einzelner Elemente oder die Linkrelation noreferrer ausdrücken. Die neue Anweisung trägt die richtige englische Schreibweise. Das alte Anfragefeld, das sie steuert, heißt weiter Referer. Man verbesserte die Sprache der neueren Regel, ohne den bereits ausgehandelten Namen im Datenverkehr auszutauschen.

Das Dokument war 2017 eine Candidate Recommendation. Es beschreibt, wie die definierten Optionen wirken sollen. Wann einzelne Browser sie tatsächlich einführten, würde ein datierter Implementierungsnachweis klären. Der Entwurf zeigt bereits die Verschiebung der Entscheidung: Die Seite, deren Adresse etwas preisgeben könnte, darf bestimmen, wie viel davon der Browser nach außen trägt.

Der Rücklink hat einen Preis

Die Herkunft einer Anfrage zu kennen bleibt für den Zielserver nützlich. Er kann fehlerhafte Zitate berichtigen und sehen, wie Leser sein Dokument finden. Der RFC von 1996 hatte gute Gründe, diese Arbeit zu unterstützen. Er hatte ebenso gute Gründe, direkt daneben die private Adresse zu erwähnen. Wenn die Herkunft auf eine nicht öffentliche Seite zeigt, verwandelt sich ein Wartungsbeleg in eine Kopie ihres Wegweisers auf einem fremden Server.

Mit einer späteren Herkunftsregel kann die Quelle ihren Webauftritt nennen und den Profilpfad zurückhalten, oder ganz schweigen. Das Ziel verliert Einträge im detaillierten Rücklinkbuch. Dieser Verlust ist der konkrete Preis geringerer Offenlegung. Die Wartung der eigenen Seiten verleiht einem Betreiber keinen pauschalen Anspruch auf den genauen Raum, aus dem jeder Besucher kam.

Der Schreibfehler Referer bleibt ein nettes Fossil. Die größere Entwicklung trennte zwei Fragen: Welcher Webauftritt schickte die Anfrage? Welche genaue, vielleicht private Seite verließ der Leser? Der nützliche Rückverweis musste beides nicht mehr gemeinsam liefern.

Quellen