要約

  • RFC 742では、CRLFだけの空行がオンライン利用者全員の一覧を求めた。氏名や端末位置を基本とし、ジョブ名やアイドル時間も有用な情報とされた。
  • RFC 1288は一行のTCP照会を残しながら、全員一覧と転送について「回答するか、明示的に拒否するか」を要求し、管理者に開示項目の選択を委ねた。
  • 79番ポートは問い合わせ先を揃えただけである。Fingerの出力は本人認証でも利用許可でもなく、人が読む文字列であっても受信側が安全に処理すべき外部入力だった。

何も書かないことが、最も広い質問だった

RFC 742が定めた手順は短い。8進数117、10進数79のsocketへ接続し、CRLFで終わる一行を送る。サーバーは人向けの情報を返し、出力が終われば接続を閉じる。固定の応答形式はない。

一行が空なら、意味は明確だった。その時点でシステムを使っている全員のdefault reportを返す。少なくともフルネームと、分かる範囲の端末の物理的位置を含める。ジョブ名や、最後の入力あるいはジョブ活動から何分たったかを示すidle timeも、便利な追加情報だった。

ユーザー名を書けば対象は一人になる。オンラインなら現在の状態、オフラインなら氏名と最終ログアウト時刻を示し、本人が短文を置けるplan機能もあった。planは、遠隔地の同僚に勤務予定や連絡方法を知らせる小さな掲示板として働いた。

この設計は出自と切り離せない。RFCは当時の実装先としてSAIL、SRI、ITSを挙げる。SAILでLes Earnestが作ったFINGERがITSのNAMEを刺激し、Earl KillianとBrian Harveyがネットワーク化に携わった。互いを知る研究コミュニティでは、在席情報は監視より協働に近く見えた。

しかし空行の構造は、利用者が増えても同じだった。問い合わせる側は対象者も目的も示さない。最初から問いは「誰か」ではなく「全員」である。小さな共同体の親切な既定値は、広いネットワークでは無差別な列挙入口になり得た。

人が読むからこそ、応答の境界が曖昧になった

Fingerは機械処理のための表を定義しなかった。各ホストが持つ情報は異なり、表示文化も異なる。氏名、ログイン名、端末、部屋、遠隔接続元、シェル、ディレクトリ、電話、メール状態、planが、一つの読み物として並び得た。

この柔軟性は移植を容易にしたが、同じ問いが同じ意味の答えを返す保証を弱めた。あるシステムのidle timeはキーボード入力を基準にし、別のシステムはジョブ活動を基準にする。利用者が不在という表示も、最終ログアウトを添える場合と、単に情報を省く場合がある。

/Wは詳細度の要求だった。初期文書ではWhois switchと呼ばれたが、最終のRFC 1288は問い合わせの先頭に置く。最後に応答するRUIPは、より詳しい情報を返す印として扱うか、無視してよい。別の認証済み権限を開く仕組みではない。

名前の照合も同様に幅を持った。ログイン名は必須だが、姓や氏名全体を受け付ける実装もある。曖昧なら候補を複数返せる。親切な人名検索は、空の全員照会を止めた後にも、粘り強い問い合わせでユーザー名を集める経路になり得る。

拒否を応答として扱うことが転換点だった

1990年12月のRFC 1196は、広く使われたBSD系の挙動を中心にFingerを標準化した。既存実装を壊さないことを重視しつつ、システム利用者の情報を返す目的そのものが機微な問題だと明記した。

1991年12月のRFC 1288は/Wの位置、空白の文法、closeの順序を修正した。TCP 79へ一行を送り、回答を受けて閉じる骨格は変わらない。変化したのは、沈黙の裏に隠れていた方針をプロトコル上の結果にした点である。

空の{C}問い合わせに対し、サーバーは回答するか、積極的に拒否しなければならない。回答するなら最低限フルネームを返す。一方で、端末やオフィスの場所、電話、ジョブ名、アイドル時間を追加するかは管理者が選べるべきだとされた。

オンライン一覧を無効にしたホストは、空の一覧で「誰もいない」と見せる必要がない。「一覧提供を拒否した」と答えられる。観測値がゼロなのか、観測を公開しないのか。この二つを分けることで、拒否は欠落ではなく方針の証拠になった。

RFC 1288は情報をatom単位で放出できることも求めた。家庭電話やログアウト時刻まで返す構成と、職場の連絡先だけ返す構成、必須の氏名だけに止める構成が、同じプロトコルの中で共存する。標準化された扉は、標準化された個人情報セットを意味しなくなった。

転送は問い合わせ可能な範囲を作り替えた

Q2形式では、ユーザー名の後へ@hostnameを連ねられる。受信したRUIPが次のホストへ新たなFinger接続を開き、残りの問い合わせを送り、得た応答を元の接続へ戻す。文法上、ホスト列に任意の固定上限はない。

RFC 1288はこの機能にも、提供または明示的拒否を要求した。既定は拒否が推奨され、とりわけgatewayで有効にすべきではないと警告する。外部から到達できるgatewayが内部ホストへ代理照会すれば、利用者案内がセキュリティ境界を横断する経路になるからだ。

中継は質問者を認証しない。内部の応答を公開情報へ変換する権限も生まない。中間ホストの到達性を借りるだけである。同じ文法が各hopで正しく動いても、誰が誰へ尋ねてよいかという統治は自動的には保存されない。

planを書けることと、配布先を決めることは違う

planはユーザーに著者性を与えた。旅行、勤務、連絡先、作業予定を自分の言葉で伝えられる。しかし本人が文章を書いた事実は、ネットワーク全体への配布に同意した証拠ではない。

RFC 1288は、ユーザーが変更できるファイルを返すことを、システムに関する任意の情報を自由に配布できる状態として考えるよう警告した。意図しない内部情報、偽装した内容、ファイル処理の脆弱な前提が、一つの便利機能へ集まる。

さらに、問い合わせを受けてユーザープログラムを実行できる実装もあった。読むだけだった表面が実行表面へ変わる。管理者には個別に無効化する選択肢が必要であり、プログラムがシステム保護を破ってはならない。

ここでは権限を三つに分ける必要がある。ユーザーは文章を作る。運用者はホスト外へ出す範囲を決める。クライアントは表示方法を決める。一つの権限を持つ者が、残る二つを暗黙に代理することはできない。

「ただの文字」は端末への命令にもなった

応答は人間向けで形式自由だった。そのためRFC 1288は、クライアントが既定で非印字文字を除き、印字可能な7-bit ASCII、tab、CRLFだけを残すよう勧告した。端末escapeにより他人のX Window名を変えたり、混乱を起こしたりするのを防ぐためである。

逆方向の混線は1977年から指摘されていた。汎用TelnetクライアントでFingerへ接続すると、TelnetのIAC option negotiationが自動送信され、サーバーの一行解釈を壊す場合がある。文字を運ぶ二つのプロトコルが、同じ文字の意味まで共有するわけではない。

「人が読む」は、無害という性質ではない。送信側はFingerの最小文法を守り、受信側は外から来た文字を端末制御から切り離す。この両方があって初めて、人向けの柔軟さを安全に保てる。

実装の堅牢性と開示の妥当性は別に測る

RFC 1288はMorris wormを挙げ、FingerをTelnet、FTP、SMTPと同じくホストのsecurity perimeterに置いた。小さなdaemonでも畸形入力への防御とpenetration testingが必要だという、実装上の証拠である。

同時に、文書は正しく動くサーバーが過剰に語る危険も示す。最終ログイン、最終メール閲覧、未読メールの有無、直近の未読メール送信者まで返す実装があれば、会話の進行と注意の向きを推測できる。コードが仕様通りでも、開示政策は失敗し得る。

逆に、返す項目を減らしてもdaemonの安全は証明されない。畸形入力、再帰転送、実行hook、出力制御文字をそれぞれ検査する必要がある。プロセスを守ることと、情報を絞ることは別の管理面である。

問い合わせログは方針を検証可能にする。誰がどの名前を繰り返し尋ねたか、Q2や/Wを使ったかを追える。ただしログ自体が人への関心を記録するため、保存期間と閲覧権限を別途限定しなければならない。

IANAの79番は住所であり、閲覧許可ではない

現在のIANA Service Name and Transport Protocol Port Number Registryは、TCPとUDPの79番にfingerを記録する。RFC 1288が定義する通信はTCPである。

登録は名前空間を保存し、実装が待ち合わせ場所を共有するためのものだ。特定のホストが現在サービスを運用していること、回答が真実であること、安全であること、問い合わせ者が何らかの項目を受け取る権利を持つことは証明しない。

Fingerの応答は、回答ホストがその瞬間に持つsession状態と、場合によってはユーザーの自己記述である。署名付きの本人証明でも、管理された登録記録の変更履歴でもない。住所が共通でも、回答の権威は共通化されなかった。

最終的に標準化されたのは、答えない自由も含む問い方だった

Fingerを「昔は無邪気だった」で終えると、設計上の変化を見失う。初期文書はすでに出力の多様性とTelnet混入を知っていた。後期標準は人を探す価値を否定せず、その価値を実現するための判断点を表へ出した。

空照会は残ったが拒否できる。詳細照会は残ったが項目を選べる。転送は残ったが既定拒否となる。planは残ったが作者性だけで安全な配布とはしない。自由形式の応答は残ったが制御文字をそのまま実行しない。

プロトコル自身がprivacyを完成させたわけではない。privacyを誰が決めるべきかを誤魔化さなくなった。79番は質問先を決め、運用者は開示を決め、クライアントは表示を決める。共通の一行は、そのいずれの権限も奪わなかった。

情報源と限界

これらは仕様史、文法、security guidance、port登録を示す。現在の普及率、攻撃頻度、個別サイトの開示方針は測定しない。本稿はIANA登録から現行稼働を推定せず、RFCの例にある全項目をすべての歴史的実装へ一般化しない。