要約

  • 1996年5月のRFC 1945は、Referer がリンク元ページのURIを訪問先サーバーへ伝えられると記した。被リンク一覧、ログ、古いリンクの修正が用途だった。同じ節は、そのURIが私的な文書を示し得ると警告した。
  • 1997年1月のRFC 2068は仕組みを維持し、Referer が英語の綴り間違いだと明記した。手入力したURLには参照元ページがなく、URIのフラグメントも送らない。安全性の節は私的文書のURIが漏れる危険を説明した。
  • 2017年1月26日のW3C候補勧告は Referrer-Policy により、URL全体、サイトのオリジンだけ、または参照元なしという選択を定義した。これは日付のある仕様であり、各ブラウザーの普及実績ではない。

宛先のサーバーには役立つ手掛かり

1996年5月に発行されたHTTP/1.0のRFC 1945は、訪問先のサーバーに小さな手掛かりを渡した。ブラウザーがページ上のリンクをたどるとき、リクエストの Referer フィールドにリンク元ページのURIを入れられる。サーバーは自分の資料を指すページの一覧を作り、ログを残し、キャッシュを工夫し、古くなったリンクや書き損じを追える。仕様はこうした用途を並べていた。

資料館が文書を移動した場面を考える。外のサイトには旧アドレスを示すリンクが残る。旧アドレスへのアクセスに元ページの住所が付いていれば、資料館はどこに修正を頼むべきか分かる。相手サイトを所有しなくても、リンク網の端をたどれる。中央の管理者がいないウェブでは、訪問時に届くこの逆向きの手紙は便利だった。

しかし、仕様はすべての訪問に出発地があるとは扱わなかった。利用者がアドレスをキーボードから直接入力した場合、元のURIを持つページはない。そのようなとき Referer を送ってはならない。URIのフラグメントも値から除外する。リンクを押した訪問と手入力の訪問を、サーバーが同じ由来として記録することは許されなかった。

そして利点と同じ節に代償も書かれている。リンク元自体が私的な情報かもしれず、その住所だけで非公開の情報源を示すこともある。著者らは、送信するかどうかを利用者が選べるよう強く勧め、公開的な閲覧と匿名の閲覧を切り替えるブラウザーの例まで挙げた。1996年の時点で、リンク修理と住所漏えいは一つの設計判断の両面だった。

綴り間違いより重い問題

1997年1月のHTTP/1.1仕様、RFC 2068は、Referer が本来の英語「referrer」を誤って綴ったものだと明言した。それでも通信で使うフィールド名は変えなかった。被リンク一覧、ログ、誤ったリンクの追跡という仕事も残した。手入力には参照元を付けず、フラグメントも除くという境界も続いた。

誤字は覚えやすい。だが本当に重要なのは、移動先へのリクエストに、移動前の別サイトの住所が入ることだ。訪問先にはリンク修理の正当な動機がある。それでも、どの組織から人が来たかを知ることと、その組織のどの個人ページから来たかを知ることは違う。前者が必要でも後者まで必要とは限らない。

RFC 2068の安全性に関する節は、Referer から閲覧傾向を調べ、逆向きのリンクを描けると述べる。個人情報を別に取り除いた後でも、フィールドは私的文書のURIを示し得る。プロフィールのパス、内部案件の名前、セッションを識別するパラメーター。URLそのものが文脈を語る。リンクの見える文字に秘密が書かれていなくても、リクエストヘッダーが外へ運ぶ。

二つのRFCが示すのは、仕組みの定義とその注意点である。当時の全ブラウザーがどのURLを何回送ったかという統計ではない。設計上の衝突は十分に分かる。宛先はリンク網の修理に使える記録を欲しがり、出発地は私的な部屋の正確な番地を渡したくない場合がある。

サイト名だけか、部屋番号までか

完全なURLにはドメイン名の先がある。パスは人のプロフィールや研究室の作業領域を示し、クエリーにはセッション識別子が入ることもある。ブラウザーがその全体を Referer として送れば、訪問先は「どのサイトから」だけでなく「どのページから」まで知る。利用者が目にしたリンクは次の資料を開くだけでも、裏のメタデータは前のページの事情を語る。

受け取ったサーバーは値をログに保存できる。一方、自分のパスの意味を最もよく知るのは出発地のサイトだ。どのURLが個人を示し、どのパラメーターが扱いに注意を要するかを判断できる。利用者は次へ進みたいだけで、直前のページの完全な住所を贈る意思を示したわけではない。1996年に提案された利用者の切り替えに加え、ページ単位の方針はより細かい答えになる。

選択肢には差がある。完全なURLは壊れたリンクの場所まで追わせる。オリジン、すなわち方式・ホスト・ポートだけなら、どのサイトから来たかは伝わるが、個別のパスやクエリーは渡さない。何も送らなければ、サイト名も残らない。宛先の便利な帳簿と、出発地の情報量は同じつまみで増減する。

出発地が送信量を決める

W3Cが2017年1月26日に公表した「Referrer Policy」候補勧告は具体的な例から始まる。交流サイトの個人プロフィールが音楽グループのサイトへリンクする。グループは交流サイトから訪問があったと知ってよいかもしれないが、どの利用者のプロフィールか分かる完全なURLまでは要らない。仕様は、URLにセッション識別子やアクセス権のような値が含まれる例も挙げる。その住所は単なる道案内を超えている。

候補仕様は段階を定めた。no-referrer はヘッダーを省く。same-origin は同じオリジン内では完全なURLを送り、別のオリジンには送らない。origin は方式・ホスト・ポートだけを伝え、パスとクエリーを落とす。strict-origin は保護された場所から信頼できない宛先への移動にも制限を設ける。ほかの選択肢はサイト内とサイト外で扱いを組み合わせる。単純な送信の有無から、相手ごとにどの部分を見せるかという判断に変わった。

ページ作者は応答ヘッダー Referrer-Policy、meta要素、個々の要素の属性、リンクの noreferrer で方針を示せる。新しい政策名は正しい綴りだが、旧来のリクエストヘッダーは Referer のままだ。新しい指示の英語を直しても、動いている通信の古い名前までは直さなかった。小さな誤字に、二つの時代が並ぶ。

2017年の文書はその時点の候補勧告だ。各選択肢の動作を示すが、ブラウザーごとの実装日を記録したものではない。正確な普及時期には日付付きの実装記録が要る。それでも設計上の変化は明確だ。自分のページの住所が何を明かすか知る側に、外へ運ぶ情報の幅を指定する手段が与えられた。

逆向きのリンクは情報の取引でもある

訪問先が来訪元を知りたがるのは自然だ。壊れた引用を直し、読者が資料をどう見つけたかを理解できる。1996年のRFCはその利益を正確に書き、その横に私的URIの危険も書いた。元ページが非公開の場所を指すとき、保守のための控えは別のサーバーに渡る私的住所のコピーになる。

後の方針では、出発地がサイト名まで渡すか、個別のページまで渡すか、黙るかを選べる。宛先の被リンク帳簿からは細部が消える。その減少こそが披露を抑える具体的な代価だ。自分のサーバーを維持する必要があるからといって、訪問者が直前にいた私的な部屋番号をいつでも受け取れるわけではない。

Referer の綴りは残った。より大きな変更は二つの問いを切り分けたことにある。「どのサイトから来たか」と「そのサイトのどの私的なページから来たか」は同じ質問ではない。

出典