要約

  • RFC 742では、CRLFだけの問い合わせが、一台のホストにその時点で利用中のユーザー一覧を求める操作として定義された。
  • 問い合わせの形式は共有されても、返答は各ホストが作る。RFC 1288は後に、一覧への拒否と追加項目の選択を管理者の制御として明文化した。

問い合わせは一台のホストに向いていた

Fingerの仕組みを見るには、最も短い問い合わせから始めるとよい。クライアントは一つのホストへ接続し、復帰改行だけを送り、返答を待つ。1977年12月の仕様では、空のコマンド行は「このシステムを今使っている人を一覧にする」という意味だった。宛先は特定のホストである。ARPANET全体を走査したり、中央の名簿に在席者を尋ねたりする操作ではない。

RFC 742でKen Harrenstienは、SAIL、SRI、MITの複数のITSシステムで既に動いていたNAMEとFINGERのプログラムに、ネットワーク越しの窓口を記述した。空の問い合わせは、TOPS-10やTENEXのローカルな状態表示コマンドSYSTATにたとえられている。推奨される一覧には、氏名や端末の場所を含められ、ジョブ名やアイドル時間も有用な追加情報だった。特定のユーザーを尋ねる場合は別の処理となり、ログイン中の状況、またはログアウト後の最終ログアウト時刻や本人が書いたplanを返せた。

ここで問いの規模が変わる。名前を指定する問い合わせは、質問者が知っているアカウントから始まる。空の問い合わせは、ホストに利用者の集合を明かすよう求める。プロトコルはこの問いを送りやすくしたが、答えを全サイト共通の名簿にはしなかった。RFC 742は、返答がシステムによって異なり、必須の書式もないと述べる。付録の例には端末、部屋、ジョブ、アイドル時間があるが、例は例であり、すべてのサーバーがそれらを返した証拠ではない。

読みやすい状態表示は本人確認ではない

名前と端末、アイドル時間が並べば、確かな記録のように見える。しかし仕様が述べているのは、人が読むための報告を返すリモートユーザー情報プログラムであり、入力している本人を認証する独立機関ではない。表示名と現実の人物を暗号学的に結び付ける仕組みも、ネットワーク全域の在席を測る仕組みも定義していない。返答を「ホスト自身の状態報告」と読むのは仕様の対象範囲と書式から導く分析である。それを本人確認の証明やインターネット全体の完全な名簿とみなすのは、文書が支える範囲を越える。

表示項目の性質も一様ではなかった。ログイン名や氏名は、同僚がアカウントを見分ける助けになる。端末の場所やアイドル時間は、誰かの居場所や作業状況を示唆しうる。planファイルは利用者が書く一方、セッション情報はシステムが提供する。同じ返答の中に、出所、更新間隔、機微性の異なる情報が混ざる。RFC 742は、その組み合わせを各サイトに委ねていた。

実装を壊さずに仕様を明確にする

その後の改訂は、白紙からの再設計ではない。1990年11月のRFC 1194は、既存実装を無効にせず、余計な制約を加えずに通信の期待値を明確にしようとした。当時よく使われていた実装は、主にBerkeleyのBSD UNIXから派生しているようだとも記す。この記述は当時の見立てであり、採用数の統計ではない。翌月のRFC 1196は小さな訂正と明確化を加えた。1991年12月のRFC 1288が、先行する三つのRFCを置き換えた。

この時点で空の問い合わせは {C} としてより明確になった。これはオンライン利用者全員の一覧を求める。リモートプログラムは回答するか、明示的に拒否しなければならない。回答するなら、少なくとも氏名を含める。追加情報の選択は管理者に許されるべきだとされた。セキュリティ章はこの一覧要求自体を拒否できる制御を求め、ユーザー情報が機微になりうると警告する。RFC 1288の実装例には、ログインとメール確認の時刻、未読メールの有無、最後に受け取ったメールの送信者まで返すものが登場する。これは開示経路の具体例であり、全ホストに共通する挙動ではない。

管理者が制御できることは、危険が消えることを意味しない。照会されたサイトはサービスを動かし、一覧要求を拒み、あるいは返答項目を絞れる。RFC 1288はMorrisワームを含む実装攻撃も扱ったが、情報開示とは別の問題である。脆弱性によってコード実行や侵入が起きることと、正常に動くサービスが運営者の選んだ情報を返すことは区別する必要がある。

共有されたのは問い方だった

プロトコルが共通化したのは、クライアントの問い方と種別である。ユーザー一人を尋ねるのか、あるホストの利用者一覧を尋ねるのかは認識できるようになった。返答の意味、完全さ、更新時点までは共通化されなかった。共通の問い合わせ構文と、データ生成・開示に対するローカルな制御は両立できる。経路は共有されても、観測は返答するホストに属していた。

これらのRFCは、Fingerを動かしたサイトの数、空問い合わせの頻度、管理者が拒否設定を使ったか、返答データがどれほど新しかったかを示さない。文書が残すのはサービスと仕様の変化であり、普及率の調査ではない。確実に言えるのは、1977年には短いネットワーク要求で一台のホストの利用者報告を遠隔から参照でき、1991年には一覧の拒否と追加項目の選択が管理上の制御として文章化されていたことだ。

参考資料