- Susam Pal は Chris Morgan のクエリ文字列を禁止したを読んだあと、Wander Console に追加していた
via= クエリパラメータを削除した
- Wander Console は、個人サイトの訪問者がコミュニティ推薦のページをランダムに巡回できるようにする分散型のセルフホスト Web コンソールで、現在 50 を超える Web サイトでホストされ、1500 を超える Web ページが推薦されている
via= 機能は、推薦された Web サイトの運営者がアクセスログで流入元を確認できるようにしていたが、https://midnight.pub/?via=https://susam.net/wander/ のように宛先 URL を直接書き換える方式だった- クエリ文字列を付けると 新しい URL になり、別のリソースを指したり 404 を返したりする可能性があり、
int10h.org のフォントページのようにクエリ文字列を独自の識別子として使うサイトを実際に壊してしまった
- ブラウザにはすでに Referer と Referrer-Policy があり、流入元情報の送信を制御できるため、Wander Console 0.6.0 以降は他人の URL に推薦元を示すクエリ文字列を追加しない
Chris Morgan のクエリ文字列批判がきっかけ
- Susam Pal は Chris Morgan の記事クエリ文字列を禁止したを読み、自分のプロジェクト Wander Console に追加していた
via= クエリパラメータを削除した
- Chris Morgan は、
https://chrismorgan.info/no-query-strings?ref=example.com のように他人が自分の URL に追跡用情報を付加することを望んでいない
- 流入元情報が必要なら HTTP
Referer ヘッダを見ればよく、そのヘッダがないなら、それには相応の理由がある可能性が高い
- Susam Pal は過去に Hacker News で Chris Morgan が自分の CSS ボイラープレート規則に残した詳細なフィードバックを通じて、リンクの下線を残すことや訪問済みリンクの紫色を維持することなどの教訓を得た
- その後も Chris Morgan の Web 関連の記事やフィードバックを読み続けており、Lobsters のRSS に著者コンテキストを追加するに付いた最近のコメントも有用な例として挙げている
Wander Console の構造と目的
- Wander Console は、個人サイトの訪問者が独立系個人サイト運営者コミュニティの推薦する興味深い Web サイトやページを探索できるようにする、小さく分散型でセルフホスト可能な Web コンソールである
- Susam Pal のコンソールは susam.net/wander/ にあり、
Wander ボタンを押すと Wander コミュニティが推薦したランダムな個人 Web ページを読み込む
- このツールは、コンソールを実装した HTML ファイル 1 つと、サイト運営者が近隣コンソール一覧および推薦 Web ページ一覧を定義する JavaScript ファイル 1 つで構成される
- 2 つのファイルを Web サーバーにコピーするだけで通常の Web サーバー上で動作し、サーバーサイドロジックやサーバーサイドソフトウェアは不要である
- Codeberg Pages や GitHub Pages のような制約のある環境でもホスティングできる
Wander ボタンを押すと、コンソールは他のリモートコンソールに接続し、Web ページの推薦を取得したうえで、その中から 1 つをランダムに選んでブラウザに読み込む- 消滅した StumbleUpon に少し似ているが、完全に分散型である点が異なる
- Webring にも少し似ているが、コミュニティネットワークは循環構造に制限されず、どのような形のグラフにもなりうる
- 現在 50 を超える Web サイトがこのツールをホストしており、合計で 1500 を超える Web ページを推薦している
- 既知のコンソールと推薦ページの最近のスナップショットは susam.codeberg.page/wcn/ で見られる
- ツールについて詳しく知る、または自分の Web サイトに設定するには codeberg.org/susam/wander を参照すればよい
via= クエリパラメータという誤った機能
https://midnight.pub/?via=https://susam.net/wander/
- この方式により、推薦された Web サイトの運営者はアクセスログを通じて訪問が Wander Console から来たことを確認できた
- この機能は Codeberg の機能リクエストを見て追加されたが、当初はためらいがあった
- 当時は代数的グラフ理論の研究締切が迫っており、Wander Console の大部分も研究中の短い休憩時間に作られた
- コンソールの最初のバージョンはある早朝のおよそ 1 時間 30 分で作られ、
via= 機能も同様の短い休憩時間に実装された
- Susam Pal は、小さな趣味プロジェクトに機能を追加し続けるよりも、スコープを限定し、必須要件を満たしたら機能完成状態のままにしておく保守方針を好んでいる
- それでも、疲労と強度の高い研究作業のため、その機能リクエストを無視できなかったのだろうと振り返っている
via= 機能には無効化できる設定があったが、あとから見ればこれも誤りだったと判断している- 疑わしい機能は、実装するとしてもデフォルト有効で後から無効化するのではなく、明示的に有効化する方式であるべきだ
- Jurassic Park の「できるかどうかに夢中になるあまり、やるべきかどうかを考えなかった」という引用がこの状況に当てはまるように見える
クエリ文字列が実際の URL を壊す
via= 機能を実装したあと、お気に入りの Web サイトのあるページがコンソールで読み込まれないことがあった- 問題になったページの、よく似ているが少し異なる URL は次のとおり
- 1 つ目と 2 つ目の URL は正常に読み込まれるが、3 つ目の URL は HTTP 404 エラーページを返す
- その Web サイトは、どのフォントコレクションを表示するかを決めるためにクエリ文字列を使っている
- 任意のクエリ文字列を付けると、サイトはそれをフォントコレクション識別子として解釈しようとするため、ページの読み込みに失敗する
- Wander Console が 1 つ目の URL に
via= クエリパラメータを付けたときも、同じ理由でページが壊れた
- URL を変更すると、クエリ文字列の追加のような小さな変更に見えても 新しい URL になる
- 新しい URL は完全に別のリソースを指すこともあれば、どのリソースも指さないこともある
- Susam Pal は、
via= クエリ文字列を付けることで自分が気に入っている Web サイトの正しい URL を壊してしまったと判断した
Referer と Referrer-Policy を迂回する問題
- Web ブラウザにはすでに流入元情報のための HTTP Referer ヘッダがある
- このヘッダは Referrer-Policy によって制御される
- Referrer-Policy はサーバーレベル、文書レベル、個々のリンクレベルで設定できる
- Web 標準は、どの範囲の流入元情報を送るかを決められる意図的な制御手段をすでに提供している
- URL に推薦元を示すクエリ文字列を付け足す方式は、こうした制御を迂回する
- つまり、プライバシーや参照元表示の問題をリファラの仕組みの外へ持ち出し、宛先 URL の中に直接埋め込むことになる
- HTML ツールがこのようなやり方で URL を書き換えるべきではないと判断した
- ユーザーの代わりに URL を変更して推薦元クエリ文字列を挿入する行為そのものも正しくないと考えている
機能削除とその後の原則
- Wander Console から推薦元クエリ文字列機能は削除された
- 機能を明示的有効化オプションとして残すこともできたが、誤った機能だと判断した以上、どのような形でもソフトウェアに残したくなかった
- プロジェクトはまだ新しく 0.x リリース段階なので、機能を削除するには良いタイミングだったと見ている
- Chris Morgan のクエリ文字列を禁止したがフィードリーダーに現れたのをきっかけに、研究時間を少し割いてこの機能を削除した
- 削除内容はコミット b26d77c で確認できる
- 最新リリース 0.6.0 にはこの機能はもう含まれていない
- 今後、新しい趣味プロジェクトで URL を読み込むことがあれば、Web サイト作者が意図したとおりに読み込むという原則を立てた
- 他人の URL にクエリ文字列を追加しないという結論に至った
1件のコメント
Lobste.rs の意見
自分の文章がどう役に立ったかを伝えてくれてありがとう。詳しいレビューを書く理由はいくつかあって、自分の満足のためでもあるし、元のプロジェクトを助けるためでもあるし、開発者が関心を示すこともあればそうでないこともあるし、インターネットで誰かが 間違っている からでもある
でも一番大きな理由は、教えるのが好きで、他の人たちがこのレビューを読んでいると分かっているからだ。実際、私のレビューは継続的に最も多くの推薦を集めるコメントの一つになっている
ときどき見知らぬ人が残してくれる感謝のコメントを本当に大切に思っていて、こういう丁寧なお礼はさらに温かい気持ちにさせてくれる
面白いことに、1月にあなたのサイトを見つけて、とくに「more purple links, please」がとても気に入っていたのだが、今日になって見ると、知らないうちに私があなたの立場に影響を与えていたようだ
昨日新しいウェブサイトを公開して、これからはいろいろな媒体でもっとたくさんレビューを載せるつもりだ。先月この計画について少し書いておいた: https://lobste.rs/s/vpdpkq/llm_reviews_cargo_crev#c_8uk441
それと、追加のクエリ文字列にアレルギー反応を示すページの例がもう一つあったというのは少し驚きだった。そのサイトではそのページだけが
?1,?2,?3,?4のようにクエリ文字列を下位ページのルーティングに使っていて、他のページはクエリ文字列を受け入れる。連番のページネーションは明らかに階層的なので URL の精神には反するが、?page=1のような方式もよくあるどのステータスコードを返すか決めるとき、404 だと誤った前提のせいで副作用が出るのではと心配していたが、もしかするとその心配は大げさだったかもしれない。ウェブのかなりの部分がパスを意味のある形で使っていないことを忘れていた
"418 I'm not a teapot"を返すことは検討しなかったのか?いいね。Wander console は見事に成長していて、Susam がここで見せている細やかさが、それがうまく機能している大きな理由に見える
私の URL にも望まないクエリ文字列が付く変種をいくつか見た。Programmer Weekly ニュースレターはクエリを付けるが、参照元ヘッダーもあるので重複している
もう一つのケースでは購読者ごとに固有 ID が付いているようで、まったく望ましくない。厄介なことに参照元がないので、どのサイトがそうしているのかも分からない
/blog/modeling-on-demand-pricing/?ck_subscriber_id=<unique-id>「知りたければ Referer ヘッダーを見ればいいし、ないならたぶんそれなりの理由があるのだろう」という話には同意したいが、Referer はここ数年、ある程度壊れているか、役に立たない状態だった。こうしたものが生まれた唯一の理由はそれだ
「なぜ追加したのかって? 大衆の要求に屈したからだ」とは、本当にそうだったのか? 関係のない issue に付いた推薦 5 件の 軽いコメント 1 つ だった。屈する前の戦いはそれほど激しくなかったようだ ;-)
このプロジェクトのユーザーが 10 人ほどしかいなかった時点で、新機能の提案が推薦 5 件を集めたのなら、私には大衆的な要求のように感じられた
私のプロジェクトはたいてい趣味で作る小さなツールだ。いくつかの例外を除けば、ユーザー数は多くない。だから機能要望やバグ報告を受け取ると、それが関連 issue であれ無関係な issue であれ、私にとっては重要だ。いつもすぐに対応できるわけではないが、どの要望により多くの需要があったかは心の中に記録している