Anubisは実際に機能している
(xeiaso.net)- Anubis が UNESCO の policytoolbox.iiep.unesco.org に導入され、大規模組織が使うボット対策ツールの事例としてさらに注目を集めるようになった
unesco.orgが UNESCO の公式ドメインであることを確認したうえで、今回の導入は 国連関連組織 における実運用事例として受け止められている- Linux Kernel Mailing List archives、FreeBSD SVN、SourceHut、FFmpeg、Wine、GNOME GitLab など、既知の導入先とあわせて用途が広がっている
- こうした組織が Anubis を導入している状況は、インターネットにおける ボットトラフィック問題 が予想よりも深刻である可能性を示している
- Anubis と周辺スタックにはさらに多くの時間が必要で、十分な支援があれば専業開発や採用まで可能になる
UNESCO への導入確認
- Anubis が、国連傘下の UNESCO の policytoolbox.iiep.unesco.org に導入された
unesco.orgは、Wikipedia において United Nations Educational, Scientific and Cultural Organization の公式ドメインとして掲載されている- UNESCO のシステム管理者チームと連絡を取り、導入時に問題がなかったかを確認しつつ、導入プロセスをより簡単に しようとしている
既知の導入事例と今後の作業
- 確認済みの 大規模導入 事例には次が含まれる
- Linux Kernel Mailing List archives
- FreeBSD の SVN、まもなく git
- SourceHut
- FFmpeg
- Wine
- UNESCO
- The Science Olympiad Student Center
- Enlightenment デスクトップ環境
- GNOME の GitLab
- これほどの規模の組織が Anubis を使っているなら、ボットトラフィックの問題は従来の想定より はるかに深刻な水準 にある可能性がある
- YouTube がかつて人間のトラフィックよりボットトラフィックのほうが多くなる「the inversion」に近かった事例のように、インターネット全体でも同様の現象がどれほど広く広がっているのかが残された疑問である
- Anubis と関連スタックに本格的に時間を投入する必要があり、十分な支援を確保できれば専業で取り組み、採用 まで行える
- Anubis が役立っているなら Patreon での支援を呼びかけている
1件のコメント
Hacker News のコメント
関連記事: Anubis: AI クローラーを防ぐためのプルーフ・オブ・ワーク・プロキシ (100 points, 23 days ago, 58 comments) https://news.ycombinator.com/item?id=43427679
Xe が以前はほとんど冗談／ネタ投稿に近かったものを、実際に役立つ製品にしたのが面白い。いつも タイミングがすべてだとは言っていた
これほど多くのサイトがこれを欲しがったり必要としたりしている点は少し驚き。非常に深く、キャッシュがなく、遅いディスクから配信される一部の Git サーバーで Git ページが遅い問題は理解できる
UNESCO は少し意外だった。そのサブサイトは文書が数千件あってかなり大きいが、静的コンテンツなので配信は簡単なはず。見てみると Apache 上にずさんにデプロイされた WordPressで、キャッシュもなく、コンテンツ圧縮もなく、HTTP/2・HTTP/3 もなかった
ごく小さなマシンでも非常に安く配信できるように直すのは簡単な可能性が高いが、当然ながら専門知識が必要で、専門知識は今も安くない
LLM に聞くこともできるだろうが、何を聞けばいいのかすら分からない状況では、まだあまり助けにならない。そもそもサイトが遅いことさえ知らなければ、なぜ聞くのか。単にトラフィックに押しつぶされていると聞いて、ファーリーな防衛者を探すことになりそう
難しいという意味ではなく、存在自体を知っている人からして少ないという意味
推測するに、WordPress に手を入れない理由は技術的な問題ではなく、壊れやすいインスタンスに触りたくないとか、組織上の権限の問題とか、管理者がすでに WP は適切に設定されていると考えているからかもしれない
これはキャッシュする方法がなく、ボットは robots ファイルも守らないので、URL を延々とリクエストし、記事をさまざまな数字や組み合わせで繰り返し取得していく。本当に厄介
これまで見た解決策は Cloudflare、ログイン要求、Anubis、あるいはばかげた規模のインフラだけだった
あるサイトではトラフィックの 60% がボット由来だと言っていたし、より小さなサイトではおそらくその比率はさらに高いはず
プルーフ・オブ・ワークを有用な計算にしようとしていたプロジェクトも覚えている
これが何なのか混乱しているなら、AI スクレイピングを防ぐためのもの
「Anubis は、クライアントが最新のブラウザを使っており、SHA-256 チェックサムを計算できることを保証するために、プルーフ・オブ・ワークの課題を使用する」
https://anubis.techaro.lol/docs/design/how-anubis-works
かなり格好よく、自分のプロジェクトの一つ二つにも役立つかもしれない
コンテンツを投稿させたり処理を実行させたりすることは、当然ながらさまざまな状況で問題になり得る
しかし単純なコンテンツ配信では、通常、人間かボットかはフィルタリングやブロックをしたい基準ではない。特定のクライアントがシステムを悪用していないなら、そのクライアントが人間かどうかをなぜ気にする必要があるのかと思う
「また、時間も入力値として使う。線形な時間軸の性質上、サーバーとリクエスト元の双方が時間とは何かを知っているからだ」
ドキュメントにある面白い一文
さまざまな理由で時計同期のずれはよくある。ユーザーの下位 10% が日単位でも正確だとは期待できないし、下位 25% でさえ 5 分程度はずれている可能性がある
Anubis のチェックが終わるまで表示される中間ページの画像が本当にかわいい。Xe のブログの絵やキャラクターはいつも美しいと感じていた
余談だが、これが一般的な検索エンジンにどんな影響を与えるのか、AI クローラーを防ぐ Cloudflare の解決策とどう違うのかも気になっていたが、GitHub ページに説明がある [1]
「これをインストールして使うと、一部の検索エンジンにウェブサイトがインデックスされなくなる可能性が高い。これは Anubis のバグではなく機能と見なされる」
「これはやや核攻撃のような対応だが、AI スクレイパーボットがあまりにも攻撃的に収集していくため、やむを得なかった」
「ほとんどの場合、これを使う必要はなく、Cloudflare で特定のオリジンサーバーを保護すれば十分である可能性が高い。ただし Cloudflare を使えない、または使いたくない状況では Anubis がある」
[1]: https://github.com/TecharoHQ/anubis/
ただし Google のようなところは、AI と検索インデックスで同じ IP を使うこともある
それでも Open Graph タグを通すなど改善中なので、少なくともリッチプレビューは動作するようにしたい
Anubisについて読んでみたが、クールなプロジェクトだ。残念ながらコメントで出ているように、サイト訪問者がJavaScript™を有効化する必要がある。
いずれにせよユーザー体験向上のためにJavaScript™が必要なサイトならまったく問題ないが、JSがまったく不要な静的サイトのようなところにはあまり向かない。
私はこうした「悪いボット」をネットワークレベルで効果的にブロックする独自の解決策を作った。MaxMindデータベースと自作のWAF・リバースプロキシを使い、複数の大手「Big Tech / Big LLM」ネットワーク全体をASN（BGP）単位で遮断している。
もちろんASNの小細工やレピュテーション詐欺も同時に行われているが、対応は非常に難しい。ログをざっと調べたところ、こうしたボットは特定の家庭向けIPから1回程度リクエストしており、その範囲は実際の人間ユーザーも使うレンジである可能性が高かった。
簡単に言えば、正常なトラフィックをブロックする危険がある。この解決策にもリスクはあるが、大多数の人間にとっての実際のリスクははるかに低い。
JavaScriptが不要で、無効化しているユーザーもサポートできればよいが、顧客やエンドユーザーからJavaScriptの有効化が必要なことについて不満を言われたことは一度もない。
JavaScript要件に反対するのは声の大きい少数派で、その大半はJavaScriptが必要なサイトに出くわすと普通に有効化する。その時でさえ、敗北のため息をつく人はごく少数だと思う。
アイデアは気に入っているが、課題の性質が整理されれば、おそらくプロトコルレベルまで下げる必要がありそうだ。
Proof of Workの課題が各WebサイトでJavaScriptとして個別に実装されるより、TCPに近い一部になる方が、アクセシビリティ面では最終的に良いはずだ。
[0] https://datatracker.ietf.org/wg/privacypass/about/
「十分に良い」解法は、既存で広く使われているSHA(seed, nonce)だ。巨大テック企業が望んでいたなら、これはスタックのより低い層に簡単に統合できたはずだ。
私のスマホではボット検出の解決に5秒もかかる。
個人的には何もする必要がないので、ユーザー体験がそこまで悪いとは思わない。CAPTCHAよりは間違いなく好む。
今「エニグマWebフォント」と呼んでいるプロトタイプを作っている。提供・キャッシュされるWebフォントに対して、ユーザーセッションごとのカスタムシードと回転値を適用しようとしている。
目的は、OCRの計算コストによってWebスクレイピングを非現実的にすることだ。今はいたちごっこなので、少し形勢を変えたい。
ユーザーセッションがなければHTMLソースは事実上無意味になり、OTPのような動作でアセットキャッシュが消えればWebページも読めなくできる。
こうすれば、ユーザーが特定の単語を読めるようになるまでローカルのシードウィンドウを調整するCAPTCHAを実質的に作れる。例えば「Foxtrottという単語が読めるようになるまでスライダーを動かしてください」といった方式だ。
Xeの意見をぜひ聞きたい。力を合わせられないだろうか？
技術スタックはGoだ。Webフォントファイルを問題なく直接変更しやすかった唯一の言語だったからだ。
テキストを壊しても役には立たないだろう。どうせ叩き続ける。トラフィックパターンを見ると、このボットを作った人たちは単に…… <https://www.youtube.com/watch?v=ulIOrQasR18>
「Xeの意見を聞きたい。力を合わせられないだろうか？」については、私が把握している限り、機能を増やすよりも、このプロジェクトを近い将来と遠い将来の両方でより持続可能にする助けが必要そうだ。Anubisはすでにうまく動作しているように見える。
確かにJavaScriptを無効化しているユーザーをブロックするのにはうまく機能する。