Zusammenfassung

  • RFC 742 machte 1977 aus einer bloßen CRLF-Zeile die Standardanfrage nach allen angemeldeten Personen, mindestens mit Namen und möglichst mit Terminalstandort.
  • RFC 1288 behielt die einzeilige TCP-Abfrage bei, verlangte für Gesamtliste und Weiterleitung aber Antwort oder aktive Ablehnung und empfahl eine feldweise Offenlegungskontrolle.
  • Port 79 koordinierte den Treffpunkt. Er authentifizierte weder die beschriebene Person noch die Antwort, schuf kein Auskunftsrecht und machte menschenlesbaren Fremdtext nicht terminalsicher.

Die leere Zeile enthielt die größte Frage

RFC 742 vom 30. Dezember 1977 beschreibt den Ablauf knapp: Verbindung zu Socket 117 oktal, also 79 dezimal, eine mit CRLF beendete Befehlszeile, ein je nach Host unterschiedlicher Bericht und anschließend der Verbindungsabbau durch den Server.

War die Zeile leer, sollte der Standardbericht alle Menschen aufführen, die das System in diesem Augenblick nutzten. Vollständige Namen und, soweit bestimmbar, physische Terminalstandorte bildeten das Minimum. Jobname und Minuten seit der letzten Eingabe oder Aktivität galten als nützliche Ergänzungen.

Eine benannte Anfrage konzentrierte sich auf eine Person. Sie konnte aktuellen Login, letzten Logout und eine kurze Nachricht aus einer besonderen Datei liefern, den Plan. Nutzer hinterließen Arbeitszeiten, Reisehinweise oder Kontaktwege und machten damit Anwesenheit über das Netz lesbar.

Der soziale Rahmen war überschaubar. RFC 742 nennt SAIL, SRI und ITS-Systeme, führt das von Les Earnest geschriebene FINGER als Anregung für NAME an und nennt Earl Killian und Brian Harvey für die Protokollumsetzung. In einer kleinen Forschungsgemeinschaft war die Anwesenheitsliste ein Koordinationswerkzeug.

Die leere Anfrage enthielt jedoch weder Zweck noch Beziehung. Sie fragte nicht nach einem Kollegen, sondern nach allen. Als das Netz wuchs, blieb der bequeme Default gleich, während sein Publikum für die Aufgelisteten unsichtbar wurde.

Menschenlesbar bedeutete nicht begrenzt

Finger schrieb kein Antwortschema vor. Verschiedene Systeme verfügten über verschiedene Daten; der Text sollte vor allem informativ sein. So konnten Login, Klarname, Terminal, Raum, Telefon, Shell, Verzeichnis, Mailzustand und persönliche Notiz zusammenkommen.

/W bat um mehr Ausführlichkeit. Das frühe Dokument nannte es Whois switch. RFC 1288 setzte es an den Anfang der Anfrage; der letzte RUIP konnte ausführlicher antworten oder es ignorieren. Eine zusätzliche Authentisierung war damit nicht verbunden.

Auch die Namenssuche durfte großzügig sein. Neben dem Login konnten Nachname oder vollständiger Name verstanden werden. Bei Mehrdeutigkeit waren mehrere Kandidaten möglich. Was Menschen ohne exakte Kontokennung half, erlaubte zugleich schrittweise Enumeration trotz gesperrter Gesamtliste.

Lesbarkeit schuf keine gemeinsame Messung. Idle konnte Tastatureingabe oder Jobaktivität meinen. Fehlende Information konnte niemand online, Unkenntnis oder Geheimhaltung bedeuten. Der Text war die lokale Sicht des antwortenden Systems.

Die aktive Ablehnung trennte Politik von Null

RFC 1196 erschien im Dezember 1990 und orientierte sich am verbreiteten BSD-Verhalten. Es wollte vorhandene Implementierungen erhalten und stellte zugleich fest, dass ein Dienst zur Rückgabe von Nutzerinformationen zwangsläufig sensible Fragen aufwirft.

RFC 1288 korrigierte ein Jahr später /W, Leerraum und die Close-Folge. TCP 79, ASCII, eine CRLF-Zeile, Antwort und Ende blieben. Neu geordnet wurde, wer über das Ergebnis entscheiden durfte.

Auf die leere {C}-Anfrage musste der Server antworten oder aktiv ablehnen. Bei Antwort waren vollständige Namen erforderlich; der Administrator sollte Terminal oder Büro, Telefon, Job und Leerlaufzeit einzeln ergänzen können. Bei deaktivierter Liste durfte er die Veröffentlichung ausdrücklich verweigern.

Eine leere Liste sieht wie eine Tatsachenbehauptung aus: null Nutzer. Eine Ablehnung beschreibt eine Regel: dieser Host veröffentlicht die Zahl nicht. Die Unterscheidung verhindert, dass Datenschutz als falscher Betriebszustand erscheint.

RFC 1288 verlangte zudem atomare Abgabe. Ein Administrator konnte Privattelefon und Loginzeiten freigeben, ein anderer nur Büroangaben, ein dritter nur den Mindestnamen. Gemeinsame Syntax bedeutete nicht länger ein einheitliches Paket personenbezogener Daten.

Weiterleitung lieh einem Fragenden Reichweite

Q2-Anfragen konnten @hostname verketten. Der erste RUIP öffnete eine weitere Finger-Verbindung, übergab den Rest der Anfrage und leitete die Antwort zurück. Die Grammatik setzte der Hostkette keine willkürliche Grenze.

RFC 1288 verlangte Bereitstellung oder ausdrückliche Ablehnung und empfahl Ablehnung als Default, besonders auf Gateways. Ein von außen erreichbares Gateway konnte sonst im Auftrag eines Fremden interne Hosts befragen.

Der Vermittler authentifizierte den Fragenden nicht und erklärte interne Daten nicht für öffentlich. Er verlieh lediglich eigene Erreichbarkeit. Jeder Hop konnte syntaktisch korrekt sein und trotzdem eine Sicherheitsgrenze ohne legitime Befugnis überschreiten.

Eine Bestandsaufnahme muss daher Q2, Endserver, Ablehnung und verknüpfte Protokolle prüfen, statt nur direkt offene Ports zu zählen.

Der Plan gab Autorenschaft, nicht die gesamte Reichweite

Ein Plan war persönliche Sprache: Dienstzeiten, Reise, Kontakt oder Projekt. Doch der Autor kannte nicht zwingend alle Netze, aus denen sein Host erreichbar war. Schreiben und Veröffentlichen waren getrennte Entscheidungen.

RFC 1288 warnte, eine nutzerveränderbare Datei könne praktisch beliebige Systeminformationen frei verteilen. Gut gemeinter Text konnte Interna offenlegen, bösartiger Text täuschen, und das Lesen der Datei konnte schwache Annahmen berühren.

Manche Implementierungen konnten bei einer Anfrage sogar ein Nutzerprogramm starten. Aus Fernlesen wurde ein Ausführungstrigger. Die Funktion musste abschaltbar sein und durfte die Systemsicherheit nicht gefährden.

Drei Zuständigkeiten bleiben: Nutzer verfassen, Betreiber bestimmen die Hostgrenze, Clients rendern. Zustimmung auf einer Ebene erteilt kein Mandat für die anderen.

Text für Menschen blieb fremde Eingabe

RFC 1288 empfahl, standardmäßig nicht druckbare Zeichen auszufiltern und nur sichtbares 7-Bit-ASCII, Tab und CRLF zu lassen. Escape-Sequenzen konnten X-Window-Namen verändern oder andere verwirrende Terminaleffekte auslösen.

Schon RFC 742 kannte die Gegenrichtung: Ein allgemeiner Telnet-Client konnte IAC-Verhandlungen in die Finger-Zeile einfügen. Dass beide Zeichen übertragen, macht ihre unsichtbaren Steuerbefehle nicht kompatibel.

„Für Menschen“ bezeichnet den Leser, nicht Harmlosigkeit. Der Sender muss die Finger-Grammatik erzeugen; der Empfänger muss Fremddaten von Terminalanweisungen trennen.

Prozesssicherheit und Informationsdisziplin brauchten eigene Nachweise

RFC 1288 verweist auf den Morris-Wurm und ordnet Finger neben Telnet, FTP und SMTP am Sicherheitsperimeter ein. Auch ein kleiner Daemon braucht Schutz vor fehlerhaften Eingaben und Penetrationstests.

Ein technisch korrekter Server konnte dennoch zu viel verraten. Das RFC nennt eine Implementierung mit letztem Login, letzter Maillektüre, ungelesenen Nachrichten und Absender der neuesten. Gespräche und Aufmerksamkeit ließen sich beobachten, ohne Code auszunutzen.

Wenige Felder bewiesen umgekehrt keine sichere Implementierung. Parser, Weiterleitung, Programme und Steuerzeichen blieben eigenständige Prüfbereiche. Datenminimierung und Robustheit ersetzen einander nicht.

Anfragelogs halfen bei wiederholten Namen, /W und Q2. Zugleich erfassten sie Interesse an Personen. Zweck, Zugriffsrechte und Löschfrist mussten daher auch für das Log gelten.

Die IANA-Nummer war eine Adresse, keine Auskunftsbefugnis

Das IANA-Register für Dienstnamen und Transportports führt finger auf Port 79 für TCP und UDP. RFC 1288 definiert den TCP-Dienst. Der Eintrag bewahrt den gemeinsamen Rendezvouspunkt.

Er beweist weder heutigen Betrieb noch Wahrheit oder Sicherheit der Antwort. Die Nummer sagt, wo man fragen kann, falls der Dienst existiert. Betreiber entscheiden Öffnung und Felder; Nutzer schreiben nur im erlaubten Rahmen; Empfänger entscheiden über Folgen.

Finger lieferte eine Momentaufnahme lokaler Sitzungen und gelegentlich Selbstauskunft. Es war weder signierter Identitätsnachweis noch administratives Register mit Änderungskette.

Die Frage überlebte, weil sie ihre automatische Autorität verlor

Die Entwicklung ist mehr als alte Naivität und spätere Sicherheit. Das Dokument von 1977 kannte bereits Formatvielfalt und Telnet-Störungen. Die Revisionen erhielten den menschlichen Nutzen, machten aber die Entscheidungspunkte sichtbar.

Die Gesamtliste blieb, jedoch verweigerbar. Das Profil blieb, jedoch konfigurierbar. Weiterleitung blieb, jedoch mit negativem Default. Der Plan blieb, ohne Autorenschaft mit unbegrenzter Distribution gleichzusetzen. Freier Text blieb, jedoch mit Clientfilter.

Finger erzeugte keinen Datenschutzmechanismus aus sich heraus. Es benannte, wo Datenschutz regiert werden musste. Port 79 sagte, wo gefragt wird; der Betreiber, was er offenlegt; der Client, wie er anzeigt. Die gemeinsame Grammatik übertrug keine dieser Befugnisse.

Quellen und Grenzen

Die Quellen belegen Spezifikationsgeschichte, Grammatik, Sicherheitsrat und Portregistrierung. Sie messen keine aktuelle Nutzung, Angriffshäufigkeit oder Site-Policy. Der IANA-Eintrag wird nicht als Deploymentbeweis verwendet, und Beispielangaben werden nicht jeder historischen Implementierung zugeschrieben.