Zusammenfassung

  • RFC 742 definierte eine Nachricht aus CRLF als Bitte an einen bestimmten Host, die gerade aktiven Nutzer dieses Systems aufzulisten.
  • Die Anfrage ließ sich über das Netz übertragen, die Antwort stellte aber jeder Host selbst zusammen; RFC 1288 machte Ablehnung und Feldauswahl ausdrücklich zu lokalen Kontrollen.

Eine leere Anfrage richtete sich an einen Host

Der kürzeste Finger-Aufruf zeigt die Architektur am klarsten. Ein Client verband sich mit einem Rechner, schickte nur Wagenrücklauf und Zeilenvorschub und wartete. Nach der Spezifikation vom Dezember 1977 bedeutete diese leere Befehlszeile: Liste die Personen auf, die dieses System gerade benutzen. Die Anfrage galt einem einzelnen Host. Sie durchsuchte weder das gesamte ARPANET noch fragte sie ein zentrales Verzeichnis, wer als anwesend gelten sollte.

Ken Harrenstien beschrieb in RFC 742 eine Netzzugriffsschicht für NAME- und FINGER-Programme, die bereits an der SAIL, am SRI und auf mehreren MIT-ITS-Systemen liefen. Die leere Anfrage verglich er mit einem lokalen Statusbefehl wie systat unter TOPS-10 oder TENEX. Die Antwort konnte vollständige Namen und Terminalstandorte nennen; Jobnamen und Leerlaufzeiten galten als nützliche Ergänzungen. Eine Anfrage nach einer bestimmten Person war etwas anderes: Sie konnte eine laufende Sitzung beschreiben oder nach der Abmeldung die letzte Logout-Zeit und einen vom Nutzer geschriebenen Plantext liefern.

An dieser Stelle ändert sich die Größenordnung der Frage. Eine Namensabfrage beginnt bei einem Konto, das der Fragende bereits kennt. Die leere Abfrage bittet den Host, eine Gruppe von Nutzern offenzulegen. Das Protokoll machte diese Bitte leicht übertragbar, definierte aber kein einheitliches Verzeichnis. RFC 742 sagt ausdrücklich, dass die Antwort vom jeweiligen System abhängt und kein gemeinsames Format vorgeschrieben ist. Die Beispiele zeigen Terminals, Räume, Jobs und Leerlaufzeiten; sie belegen Beispiele im Dokument, nicht identische Ausgaben aller Server.

Ein lesbarer Bericht ist kein Identitätsnachweis

Ein Name neben einem Terminal und einer Leerlaufzeit kann wie ein eindeutiger Befund wirken. Die Spezifikation beschreibt jedoch ein entferntes Benutzerinformationsprogramm, das einen lesbaren Bericht liefert, keine unabhängige Stelle, die die Person an der Tastatur bestätigt. Sie definiert weder eine kryptografische Bindung zwischen angezeigtem Namen und realer Person noch eine Präsenzmessung für das gesamte Netz. Die Antwort als Bericht eines Hosts über seinen eigenen Zustand zu lesen, ist eine Schlussfolgerung aus Umfang und Format des Protokolls.

Sie als Identitätsbeweis oder vollständige Internetstatistik zu behandeln, ginge über die Quellen hinaus.

Auch die Felder selbst waren verschiedenartige Hinweise. Ein Login- oder vollständiger Name konnte Kollegen helfen, ein Konto zuzuordnen. Terminalstandort und Leerlaufzeit konnten andeuten, wo jemand war und ob er arbeitete. Eine Plan-Datei konnte Text des Nutzers enthalten, während Sitzungsdaten aus dem System stammten. Eine einzige Antwort konnte daher Informationen mit unterschiedlichen Urhebern, Aktualisierungsrhythmen und Empfindlichkeiten mischen. RFC 742 überließ diese Zusammenstellung weitgehend der jeweiligen Installation.

Die Klarstellung folgte der installierten Software

Die nächste Phase war kein Neustart. RFC 1194 versuchte im November 1990, die erwartete Kommunikation zu präzisieren, ohne die vielen bestehenden Implementierungen ungültig zu machen oder unnötige Einschränkungen einzuführen. Die damals verbreitetsten Implementierungen schienen vor allem auf BSD UNIX aus Berkeley zurückzugehen. Das war eine zeitgebundene Einschätzung, keine Einsatzstatistik. RFC 1196 nahm im darauffolgenden Monat kleinere Korrekturen und Klarstellungen vor. Im Dezember 1991 ersetzte RFC 1288 die drei früheren Memos.

Nun wurde die leere {C}-Anfrage deutlicher als Liste aller angemeldeten Nutzer beschrieben. Das entfernte Programm musste antworten oder die Anfrage ausdrücklich ablehnen. Bei einer Antwort war mindestens der vollständige Name erforderlich; Administratoren sollten zusätzliche Felder auswählen können. Der Sicherheitsteil sah außerdem die Möglichkeit vor, die allgemeine Liste abzulehnen, und warnte, dass Nutzerinformationen sensibel sein können. Als Beispiel nannte RFC 1288 eine Implementierung, die Anmelde- und Mail-Lesezeiten, ungelesene Nachrichten und den letzten Absender offenlegte. Das zeigt einen möglichen Offenlegungspfad, nicht das Verhalten jedes Hosts.

Die Kontrolle des Administrators war greifbar, beseitigte aber nicht jedes Risiko. Der abgefragte Host konnte den Dienst betreiben, die allgemeine Liste verweigern oder die Felder begrenzen. RFC 1288 behandelte auch Angriffe auf die Implementierung, darunter den Morris-Wurm; das ist ein anderer Risikopfad. Eine Schwachstelle, die Codeausführung oder einen Einbruch ermöglicht, ist nicht dasselbe wie ein korrekt laufender Dienst, der von den Betreibern ausgewählte Daten zurückgibt.

Gemeinsam war die Frage, lokal blieb der Bericht

Das Protokoll vereinheitlichte genug, damit ein Client eine erkennbare Frage stellen und der Server zwischen einer Nutzerabfrage und einer Host-Liste unterscheiden konnte. Bedeutung, Vollständigkeit und Aktualität der Antwort blieben uneinheitlich. Hier zeigt sich ein frühes Internetmuster: Eine gemeinsame Abfragesyntax kann neben lokaler Kontrolle über Erzeugung und Offenlegung der Daten bestehen. Der Übertragungsweg ist gemeinsam; die Beobachtung gehört weiterhin dem antwortenden Rechner.

Die RFCs verraten nicht, wie viele Sites Finger betrieben, wie oft leere Anfragen gestellt wurden, ob Administratoren die Ablehnung nutzten oder wie frisch jede Antwort war. Sie dokumentieren einen Dienst und die Entwicklung seiner Spezifikation, nicht seine Verbreitung. Die belastbare historische Aussage bleibt enger: Seit 1977 konnte eine einfache Netzwerkanfrage den Nutzerbericht eines einzelnen Hosts aus der Ferne abrufbar machen; 1991 beschrieb die Spezifikation Ablehnung und lokale Feldauswahl ausdrücklich als Kontrollen dieses Dienstes.

Quellen