トラッキングとの戦い：ある開発者がクエリ文字列を禁止した理由

あらゆるクリックが追跡、測定、収益化される時代において、URLは単なるロケーター以上のもの、つまりテレメトリ（遠隔測定）デバイスとなってしまいました。UTMパラメータからFacebookのfbclidに至るまで、ページへの単純なリンク作成という行為には、遷移先のサイトが求めておらず、ユーザーもおそらく同意していない追跡メタデータの痕跡を付加することが伴うことがよくあります。

Chris Morganは最近、自身の個人サイトにおいて、許可されていないクエリ文字列を全面的に禁止するという、技術的かつ哲学的な論争を巻き起こしました。許可していないクエリ文字列を含むリクエストを拒否するようにサーバーを構成することで、Morganはユーザーの「悪用」とウェブのアドレス指定システムの汚染に対する姿勢を示しています。

URL汚染に対する主張

Morganの決定の核心には、第三者がリンクを操作することへの不満があります。サイトがURLに?utm_source=exampleや?ref=example.comを追加する場合、彼らは実質的に遷移先の住所をハイジャックして、独自の追跡ニーズを満たそうとしているのです。

Morganは、これは不必要な侵害であると主張しています。サイトの所有者がトラフィックの流入元を知りたい場合、HTTP Refererヘッダーがすでにその情報を提供しています。プライバシーを優先するユーザーにとって、Refererヘッダーはブラウザの設定を通じて管理または無効化できますが、クエリ文字列による追跡はリンク自体に組み込まれているため、リクエストが送信される前に一般ユーザーがそれを取り除くことはほぼ不可能です。

技術的な実装

Morganは、Caddyfile（Caddyサーバーの設定ファイル）を使用してこの禁止措置を実装しました。クエリ文字列を含むリクエストを拒否するというロジック自体は単純ですが、HTTPレスポンスコードの選択が議論の的となっています。彼は現在、414 URI Too Longエラーを返していますが、これは技術的な正確さよりも「ユーモア」のためであると認めています。検討された他の選択肢には、418 I'm a teapotコードもありました。

標準規格の観点からは、このアプローチは技術的に許容されます。Hacker Newsの議論においてコミュニティメンバーが指摘したように、W3CのURLに関する標準規格は広範です。クエリ文字列は、単に?に続くパーセントエンコードされた文字列に過ぎません。サーバーはこれらのリクエストをどのように処理するかを定義するため、予期しないクエリ文字列に対して404やその他の4xxエラーを返すことは、サーバーのAPIとしての有効な実装です。

大論争：エチケットと開放性の対立

Morganの動きは、開発者やウェブ愛好家の間で意見を二分しています。議論は概ね、以下の2つの陣営に分かれます。

「ハイパーテキスト・エチケット」陣営

この禁止措置の支持者は、遷移先のサーバーの同意なしにURLを操作することは、ウェブ・エチケットに違反すると主張しています。

"ハイパーテキスト・エチケットにおいて、誰かに対して、遷移先のHTTPサーバーが許可していない方法でURLを操作したリンクを渡すことほど、失礼なことはありません。"

この陣営は、URLを遷移先のサイトの知的財産であると考えています。彼らは、YouTubeやAmazonのようなプラットフォームによって生み出された「怪物」を指摘しています。そこでは、実際のコンテンツ識別子が、大量の追跡パラメータによって埋もれてしまい、リンクの共有が困難になり、見た目も非常に不快なものになっています。

「レッセ・フェール（自由放任）」陣営

反対派は、ウェブの強みは、その緩やかな結合（loose coupling）と許可を必要としない性質にあると主張しています。彼らは、URLをどのように作成するかという能力は、ウェブ本来の自由の一部であると示唆しています。

"ハイパーパーリンクの双方の合意/同意が必須であるという設計は、ウェブ以前のハイパーテキスト・システムの、普及を妨げた要因でした。ウェブのレッセ・フェール的なアプローチは、緩やかな結合がユーザーにとってはるかに優れたものであることを証明しました..."

また、禁止措置の批判者は、エンドユーザーに4xxエラーで罰を与えることは逆効果であると指摘しています。ユーザーが追跡リンクをクリックした際、被害を受けるのはリンクを貼った企業ではなく、ページが表示されないエラーをページが表示できないユーザー自身なのです。

強制的な禁止に代わる選択肢

全面的に禁止することは攻撃的すぎると感じるものの、URL汚染をURL汚染を嫌う人々にとって、いくつかの代替案が提案されました。

1. ソフト・リダイレクト: エラーを返す代わりに、追跡パラメータが検出されたことを説明するページを表示し、ユーザーがクリックするためのクリーンなリンクを提供します。
2. Proof-of-Work (PoW): クエリ文字列を含むリクエストに対して、小さな計算課題（computational challenge）を課すことで、ボットや自動追跡ツールを抑止します。
3. クライアント・サイドでの除去: ブックマークレットやブラウザ拡張機能を使用して、リンクを共有する前にクエリパラメータを削除します。あるユーザーは、この目的のためにシンプルなJavaScriptスニペットを共有しました： (()=>navigator.clipboard.writeText(location.origin+location.pathname))();

結論

クエリ文字列のブロックは、「潔癖すぎる」制限なのか、それともオープンなウェブの防衛策として必要なものなのか。それは、ウェブの本来のビジョンである「文書の分散ネットワーク」としてのウェブと、現代のウェブが「データ収集の集中エンジン」として機能している現状との間に生じている、高まり続ける緊張関係を浮き彫りにしています。URLを柔軟な文字列としてではなく、厳格なAPIとして扱うことで、開発者は、監視が蔓延する時代におけるユーザーのプライバシーバシーとリンクの整合性をどのように扱うべきかという議論を強制的に引き起こすことができます。