Кратко

  • RFC 742 определил пустую строку CRLF как запрос к конкретному узлу: перечислить пользователей, которые в этот момент работают в его системе.
  • Сеть переносила запрос, но ответ формировал сам узел; RFC 1288 позднее закрепил возможность отказать в общем списке и выбирать дополнительные поля на месте.

Пустой запрос был адресован одному узлу

Архитектуру Finger лучше всего показывает самый короткий запрос. Клиент подключался к машине, отправлял только возврат каретки и перевод строки, а затем ждал. В спецификации декабря 1977 года такая пустая командная строка означала: перечислить людей, которые сейчас пользуются этой системой. Запрос направлялся конкретному узлу. Он не обходил весь ARPANET и не обращался к центральному справочнику, который решал бы, кто считается присутствующим.

В RFC 742 Кен Харренстин описал сетевой интерфейс к программам NAME и FINGER, уже работавшим в SAIL, SRI и на нескольких системах ITS в MIT. Пустой запрос сравнивался с локальной командой состояния системы, например systat в TOPS-10 или TENEX. В перечень можно было включать полные имена и расположение терминалов; имя задания и время бездействия тоже считались полезными полями. Запрос конкретного пользователя решал другую задачу: показывал текущую сессию либо, после выхода, время последнего выхода и написанный самим пользователем файл plan.

Именно здесь меняется масштаб вопроса. Поиск по имени начинается с учетной записи, известной спрашивающему. Пустая строка просит узел раскрыть целое множество пользователей. Протокол упростил передачу такого запроса, но не превратил ответ в единый реестр. RFC 742 прямо говорит, что ответ зависит от системы и не требует общего формата. В примерах есть терминалы, комнаты, задания и периоды бездействия; это примеры в документе, а не свидетельство одинакового ответа каждого сервера.

Читаемый статус не удостоверяет личность

Имя, терминал и время бездействия могут выглядеть как точная запись. Но спецификация описывает удаленную программу пользовательской информации, выдающую понятный человеку отчет, а не независимый орган, удостоверяющий личность за клавиатурой. Она не устанавливает криптографическую связь между показанным именем и реальным человеком и не измеряет присутствие по всей сети. Читать ответ как сообщение узла о собственном состоянии — вывод из области действия и формата протокола. Считать его подтверждением личности или полным измерением присутствия в Интернете означало бы выйти за пределы источников.

И сами поля представляли сведения разной природы. Имя входа или полное имя могли помочь коллеге распознать учетную запись. Расположение терминала и длительность бездействия могли подсказать, где находится человек и работает ли он. Файл plan мог содержать текст пользователя, тогда как состояние сеанса поступало от системы. Поэтому один ответ мог объединять данные с разными авторами, периодами обновления и чувствительностью. RFC 742 оставлял состав такого ответа во многом конкретной установке.

Уточнение шло вслед за работающим ПО

Следующий этап не был перепроектированием с нуля. Опубликованная в ноябре 1990 года RFC 1194 стремилась уточнить ожидаемое взаимодействие, не ломая многочисленные существующие реализации и не добавляя ненужных ограничений. В ней отмечалось, что наиболее распространенные тогда реализации, по-видимому, главным образом происходили из BSD UNIX, разработанного в Беркли. Это оценка своего времени, а не статистика развертывания. RFC 1196, выпущенная в декабре того же года, внесла небольшие исправления и уточнения. В декабре 1991 года RFC 1288 заменила все три предыдущих документа.

К этому времени пустой запрос {C} описывался уже как запрос списка всех пользователей онлайн. Удаленная программа должна была ответить либо явно отказать. Если она отвечала, то обязана была указать как минимум полное имя пользователя; администратору следовало дать возможность выбирать дополнительные поля. Раздел безопасности также предусматривал отказ в общей выдаче и предупреждал, что сведения о пользователях могут быть чувствительными. В качестве примера RFC 1288 приводила одну реализацию, которая раскрывала время входа и чтения почты, наличие непрочитанных сообщений и имя последнего отправителя. Это пример пути раскрытия, а не универсальное поведение серверов.

Контроль администратора был практическим, но не устранял все риски. Запрашиваемый узел мог запустить службу, отказать в общем списке или ограничить поля. RFC 1288 отдельно обсуждала атаки на реализацию, включая червя Морриса; это другой путь риска. Уязвимость, позволяющая выполнить код или проникнуть на сервер, отличается от штатной работы службы, которая возвращает выбранные операторами сведения.

Общим стал запрос, а отчет остался локальным

Протокол унифицировал достаточно, чтобы клиент задавал узнаваемый вопрос, а сервер различал запрос об учетной записи и список пользователей одного узла. Значение, полнота и актуальность ответа общими не стали. Это ранний урок истории Интернета: единый синтаксис запроса может сочетаться с местным контролем над производством и раскрытием данных. Путь передачи общий; наблюдение остается за машиной, которая отвечает.

Эти RFC не сообщают, сколько площадок запускали Finger, как часто пользователи посылали пустой запрос, применяли ли администраторы отказ и насколько свежими были ответы. Они описывают службу и эволюцию спецификации, но не распространенность. Осторожный исторический вывод уже и точнее: с 1977 года простая сетевая просьба могла удаленно открыть отчет об активных пользователях одного узла; к 1991 году отказ от общего списка и локальный выбор полей были описаны как часть контроля службы.

Источники