Summary

  • In RFC 742, a line containing only CRLF asked one named host for a list of the people using that system at that moment.
  • The protocol made the question portable, while the host still chose what its human-readable answer disclosed; RFC 1288 later made refusal and field selection explicit.

The question was smaller than the answer

The most revealing Finger request contained almost nothing. A client opened a connection to a host, sent a carriage return followed by a line feed, and waited. Under the December 1977 specification, that empty command line meant: list the people using this system now. The request was directed to one machine. It was not a search of the whole ARPANET, and it did not ask a central directory to decide who counted as present.

Ken Harrenstien's RFC 742 described a network interface to NAME and FINGER programs already running at SAIL, SRI and several MIT ITS sites. It treated a blank query as the remote counterpart of a local system-status command such as TOPS-10 or TENEX systat. The suggested list could include full names and terminal locations, with job names and idle time as useful additions. A named-user query did something different: it could describe a current session or, for someone logged out, return a last-logout time and a user-written plan.

That difference in scale is the story's hinge. A named query begins with an account the requester already knows. An empty query asks the host to disclose a set. The protocol made that set easy to request, but did not define it as a universal roster. RFC 742 says replies would vary with the command and the particular system. It required no common output format. The examples include terminals, rooms, jobs and idle intervals, but examples are not evidence that every Finger server returned those fields.

One request, several kinds of evidence

A line in a Finger response could look definitive: a name, a terminal, perhaps a number of idle minutes. Yet the specification describes a remote user-information program returning a report, not an independent authority certifying a person's identity. It does not specify a cryptographic link between the displayed name and the person at a keyboard, nor a network-wide measurement of presence. Reading the answer as a host's account of its own state is an inference from the protocol's scope and format; treating it as proof of identity or complete Internet availability would go beyond the documents.

The distinction mattered because the returned fields were not all equivalent. A login name or full name could identify an account to a colleague. A terminal location or idle interval could suggest where someone was and whether they were working. A plan file could carry information written by the user, while the host's status fields came from its own system. The same query could therefore combine data with different authors, update cycles and sensitivities. RFC 742 left much of that arrangement to each installation.

Clarification followed the installed base

The next chapter was not a clean redesign. RFC 1194, issued in November 1990, said it was trying to clarify expected communication without invalidating the many existing implementations or adding unnecessary restrictions. It reported that the most prevalent implementations then appeared to derive primarily from Berkeley BSD UNIX. RFC 1196, published the next month, made minor corrections and clarifications. RFC 1288 followed in December 1991 and obsoleted all three earlier memos.

By then the specification was more explicit about the blank request. The {C} query asked for a list of all online users. A remote user-information program had to answer or actively refuse. If it answered, it had to supply at least each user's full name; administrators should be able to select additional fields. The security section separately recommended an administrator control for refusing the all-users list and warned that user information could be sensitive. RFC 1288 even offered a concrete example in which one implementation exposed login and mail-attention details. That example illustrates a disclosure path; it is not a claim about every host.

This was a meaningful boundary, not a promise that disclosure would be safe. RFC 1288 put the decision at the queried site: run the service, refuse a class of query, or limit the information atoms returned. It also discussed implementation attacks, including the Morris worm, but those are a different risk. A bug that lets a query execute or compromise a server is not the same problem as a correctly functioning service revealing information its operators chose to publish.

What became interoperable

The protocol standardized enough for a client to ask a recognizable question and for a remote service to know whether it was answering a named-user or all-users request. It did not standardize the meaning, completeness or freshness of the report. This is an early Internet design pattern worth noticing: shared request syntax can coexist with local control over data production and disclosure. The route is common; the evidence remains situated at the host.

The record has limits. These RFCs do not tell us how many sites operated Finger, how often people sent blank queries, whether administrators used refusal controls, or how current each reply was. They document a service and its evolving specification, not a deployment census. The safer historical claim is narrower and more useful: from 1977 onward, a simple network request could make one machine's online-user report remotely reachable; by 1991, the standard described refusal and local field choices as part of that service's control surface.

Sources