Summary

  • RFC 742's 1977 NAME/FINGER service treated a blank CRLF line as a request for everyone online, with names, terminal locations, idle time and other human-oriented details considered useful.
  • RFC 1288 preserved the one-line TCP exchange but made policy visible: a server could actively refuse the all-user list or forwarding, and administrators should choose which individual information fields to release.
  • Finger standardized the question and its rendezvous at TCP port 79. It did not authenticate the subject, guarantee the answer, grant a right to the data or make untrusted human-readable output safe to display.

A blank line was a meaningful command

The most revealing Finger request contained almost nothing. A client connected to socket 117 in octal—79 in decimal—sent CRLF and waited. RFC 742, dated 30 December 1977, called the result a default report: a list of all people using the remote system at that moment.

The recommended minimum was personal. The list should contain full names and, where the system could determine them, the physical locations of terminals. Job names and idle time were also described as reasonable and useful. A query containing a username shifted from the crowd to one person. It could report whether that person was logged in, when the person last logged out and a short “plan” message left in a specially named file.

This was not a machine-record protocol wearing a friendly interface. The reply was expressly meant for a human. There was no required output format. The client sent one command line, received whatever informative text that host produced, and the server closed the connection when it was finished.

The simplicity reflected the communities in which the protocol began. RFC 742 named SAIL, SRI and several ITS systems as current servers. It traced the SAIL FINGER program written by Les Earnest to the NAME program on ITS, and credited Earl Killian and Brian Harvey with the network protocol. A remote status board made sense among people who already treated network presence as part of collaboration.

But the empty line carried a structural choice. The person requesting the list did not have to identify a target, show a purpose or prove a relationship to the site. The default question was collective: who is here? Once the network grew beyond a small circle, the convenience did not shrink. The audience did.

Human-oriented output made the protocol broad

Finger did not prescribe a fixed field layout, so an answer could grow with local imagination. RFC 742's examples include login names, personal names, jobs, terminals, rooms, console locations, remote sites, last-login information and user plans. Later practice could add office and home phone numbers, directory paths, shells and mail state.

That looseness was useful because different systems held different information. It also meant that interoperability answered only part of the problem. Two programs could agree on port 79, CRLF and connection close while disagreeing entirely about what a person should learn from the text.

The /W token made the tension explicit. In the early document it was called the Whois switch and requested a fuller description. RFC 1288 later placed /W at the beginning of the query grammar and allowed the last server either to interpret it as greater verbosity or ignore it. More detail was not a separate authenticated operation. It was a request inside the same minimal channel.

Even the name could expand. Servers were expected to understand login names, but might also accept surnames or full names. An ambiguous name could return several candidates. A feature designed to help a human find a colleague could therefore become an enumeration path even after the obvious all-user query was disabled.

From friendly default to explicit refusal

The protocol was rewritten after its social setting had changed. RFC 1196, published in December 1990, described prevalent BSD-derived behavior and warned that returning information about a system's users was sensitive “at best.” It tried to clarify the exchange without invalidating the many implementations already in use.

RFC 1288 followed in December 1991, correcting the placement of /W, making whitespace grammar exact and specifying connection closure more carefully. The wire interaction remained small: open TCP port 79, send one ASCII line ending in CRLF, receive an answer, then close. The major change was not message size. It was who was allowed to decide.

For an empty {C} query, a server had to answer or actively refuse. If it answered, the response included at least full names, while the administrator should be able to choose whether to add terminal or office location, office phone, job name and idle time. If the online-user list was disabled, the server was not required to pretend that nobody was online. It could return an explicit refusal.

That distinction matters. An empty result can be read as a fact about the world. A refusal is a fact about policy. By standardizing an active negative answer, the later specification let a receiving human distinguish “the service reports no one” from “this host will not expose its online population.”

RFC 1288 called the next control “atomic discharge.” Implementations should let administrators tailor which atoms of information were returned. One site might disclose office and home phone numbers plus login times; another might return only an office location and phone; a third might stop at the required full name. The network grammar no longer implied one universal disclosure bundle.

Forwarding could pierce the perimeter

Finger queries also supported a chain of @hostname components. A Q2 request asked one remote user information program to open another Finger connection and forward the remaining query. The grammar imposed no arbitrary bound on the number of host tokens.

Here again, RFC 1288 required a visible policy outcome. A server had to provide forwarding or actively refuse it. The recommendation was to refuse by default, especially on gateways. If a gateway accepted a query from outside and then sent it to an interior host, the friendly directory service had become a path through the security perimeter.

Forwarding did not authenticate the original question or convert an internal answer into public data. It merely changed which machine was able to reach the next service. A site that considered only the first TCP connection could therefore misunderstand the actual disclosure path.

The control lesson is wider than Finger. A relay can be syntactically faithful and still alter who can ask whom. Authority is not preserved merely because every hop speaks the same protocol.

The plan file moved authorship without containing its reach

The plan feature gave users a voice. A person could leave a short message for future Finger queries: working hours, travel, contact instructions or a project note. It was a small predecessor of a network-visible status field.

Yet the server, not the author, decided where that text travelled. RFC 1288 warned that returning a user-modifiable file should be treated as allowing arbitrary information about the system to be freely distributed. A user might intentionally disclose sensitive details, embed misleading material or exploit assumptions in the program that collected the file.

Some implementations could run a user program in response to a query. The RFC treated that as a still more dangerous option: input from the network could now trigger executable behavior under local operating-system constraints. The administrator was supposed to be able to turn the feature off, and the implementation had to prevent the program from compromising system security.

These features separate three authorities that are easy to collapse. A user can author text. An operator can expose or withhold it. A remote client can decide how to render it. Consent at one layer does not silently settle the other two.

A readable answer was still untrusted input

Finger's response format was loose because people, not parsers, were expected to read it. That did not make the bytes harmless. RFC 1288 recommended that clients filter unprintable data by default, retaining printable seven-bit characters, tabs and CRLF. The stated concern included terminal escape sequences that could change another person's X window name or perform other confusing actions.

The danger ran in both directions. RFC 742 had already warned that using a generic Telnet client could inject Telnet option-negotiation bytes into the Finger command line. A tool that looked compatible because it carried text could change the application message before the server interpreted it.

Thus the protocol's human orientation created two safety duties. The sending client had to emit the one-line Finger grammar rather than interactive-control traffic. The receiving client had to treat the answer as untrusted text rather than terminal instructions. “For a human” described the intended audience, not a security property.

Implementation and information were separate risks

RFC 1288 names the Morris worm when demanding penetration testing for Finger implementations. It places Finger beside Telnet, FTP and SMTP at a host's security perimeter. That evidence supports a narrow conclusion: a small query protocol can still expose code directly to hostile inputs.

The RFC then separates implementation security from disclosure security. A memory-safe, correctly parsed server could still reveal who was online, when someone last read mail, whether unread mail existed and who sent the most recent unread message. The document warns that such details could reveal conversations and attention.

Conversely, a policy-minimal response did not prove the daemon safe. Malformed inputs, recursive forwarding, executable user hooks and output handling remained implementation concerns. Protecting the process and limiting the data were related controls, not substitutes.

Logging completed the policy loop. Implementations should allow administrators to log Finger queries. That record could show which names were requested, whether enumeration was persistent and whether forwarding was used. It could also become a record of human interest and therefore required its own retention and access policy.

The registered port coordinated a door, not an entitlement

The current IANA Service Name and Transport Protocol Port Number Registry records finger on port 79 for TCP and UDP. RFC 1288 defines the service over TCP. The registry preserves a common place where an implementation can seek the service.

It does not say that a host runs Finger, that the service is safe, that an answer is current or that the requester may receive any particular field. A well-known port coordinates a rendezvous. The answering operator still controls exposure, the user still controls only the material the operator permits, and the recipient still controls what consequence to attach to the text.

This is where Finger differs from a formal directory record. It exposed the answering host's momentary view of people and sessions, often supplemented by self-authored status. It did not publish a signed identity assertion or an administrative chain of custody.

The question survived by losing its default authority

Finger's historical arc is easy to caricature as innocence followed by security. The documents show something more precise. The 1977 protocol already knew that output varied and that ordinary Telnet behavior could disrupt the command. The later standards did not discard its human value. They made the choices around that value inspectable.

An empty query remained a request for everyone online, but a server could refuse. A named query could still return a rich profile, but administrators should choose the fields. A forwarded query remained grammatically possible, but refusal was the recommended default. A plan could still be personal, but user authorship did not make its distribution harmless. A human-readable response remained flexible, but clients were expected to filter control characters.

The result was not privacy by protocol. It was a protocol honest enough to expose where privacy policy had to live. Port 79 answered where to ask. The operator answered whether to disclose. The client answered how safely to display. No layer acquired the right to speak for the others.

Sources and evidence limits

The closed sources establish protocol history, grammar, security guidance and port registration. They do not measure current deployment, attack frequency or a particular site's disclosure practice. The article therefore does not treat the IANA row as evidence that Finger is enabled today, and it does not claim that every historical implementation returned every field shown in the RFC examples.