Anubis は実際には誰を止めているのか？

 (fzakaria.com)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • HTTP アクセスの前に**Proof-of-Work（作業証明）**を要求する Anubis は、AI スクレイパーよりも一般ユーザー、低スペック端末、JavaScript 非対応クライアントに、より大きな継続的コストを課している
  • LLM が作った anubis-fetch は Proof-of-Work を直接解き、必要なら Chromium を起動し、Chrome の TLS/JA3 フィンガープリントを模倣して Cloudflare の手動ブロックまで通過する
  • スクレイパーは発行された Cookie をキャッシュ・再利用して、コストを複数リクエストに分散して償却できるが、人間は訪問のたびに数秒の待ち時間とバッテリー消費を受け入れなければならない
  • デフォルト難易度 4 は平均 65,536 回のハッシュを要求し、ネイティブ Go 実装では約 1.3ms、ブラウザ JavaScript では約 130ms かかるが、実際の体感待ち時間は約 1〜5 秒
  • 1 回あたりの体感時間を 2 秒、エネルギーを 20J と仮定すると、1 日 100 万回のチャレンジは年間で約 23 人年・2MWh、1 日 1 億回では約 2,300 人年・200MWh を消費する

AI が迂回した Anubis

  • Linux カーネルで binfmt_misc の bpf を通じてインタープリタ PT_INTERP に $ORIGIN をサポートするパッチを作業している際、LLM に Linux カーネルメーリングリストのスレッドを読むよう依頼した
  • lore.kernel.org は、リソースアクセスの前に Proof-of-Work を要求する HTTP プロキシ Anubisを導入していた
  • LLM はこの制限に対応する anubis-fetch を作成した
    • まず Proof-of-Work をネイティブで解き、失敗すると Chromium で URL を訪問する
    • req で実際の Chrome の TLS/JA3 フィンガープリントを模倣し、Cloudflare の手動ブロックも通過する
    • anubis-fetch <URL> は HTML を標準出力に出力し、--text オプションは読みやすいプレーンテキストを出力する
  • Anubis が狙っている AI やボットは、Proof-of-Work 対応を一度追加すれば容易に迂回できる
    • スクレイパーはチャレンジを解いた後に受け取った Cookie をキャッシュ・再利用し、コストを複数リクエストに分散して償却する
    • 一方で人間は訪問のたびにスピナーを待ち、バッテリーを消費し、このコストを他のユーザーと分担することはできない
    • 低スペック端末やスマートフォンほど負担が大きくなり、JavaScript を使わない w3m・lynx・スクリーンリーダー・RSS リーダーはアクセスできない
  • AI を止めようとする仕組みが AI には容易に迂回される一方、人間とオープンな Web にはコストを課し続ける逆進的な負担として機能している

Proof-of-Work が生む時間・エネルギーコスト

  • 難易度 d は、ハッシュが持つべき先頭 0 の 16 進文字数であり、解答 1 回あたりの期待作業量は W = 16^d 回のハッシュである
    • 一般的なデフォルト値である難易度 4 は 65,536 回のハッシュを要求する
      • 約 50 MH/s のネイティブ Go 実装：約 1.3ms
      • 約 0.5 MH/s のブラウザ JavaScript：約 130ms
      • ページ読み込み、ワーカー実行、再読み込みを含む体感時間：約 1〜5 秒
    • 難易度 5 は 1,048,576 回のハッシュを要求する
      • ネイティブ Go 実装：約 20ms
      • ブラウザ JavaScript：約 2 秒
      • 体感時間：約 5〜15 秒
  • 世界全体での 1 日あたりの Anubis チャレンジ解答回数を C、1 回あたりの体感時間を t = 2秒、画面と CPU を含む端末エネルギーを E = 20J と仮定する
    • 年間の人間時間は C × t × 365 / 3.15×10⁷ で計算する
    • 年間エネルギーは C × E × 365 / 3.6×10⁶kWh で計算する
  • この仮定に基づく年間コストは次のとおり
    • 1 日 100 万回：約 23 人年、約 2MWh
    • 1 日 1,000 万回：約 230 人年、約 20MWh
    • 1 日 1 億回：約 2,300 人年、約 200MWh
  • すべての数値は大まかな推定値であり、ボットファームや AI ツールは数桁多いエネルギーを使うため、環境問題を主張するための計算ではない
  • ロボットにとって時間は制約ではないが、人間の時間は有限であるため、利用者は AI 時代以前には存在しなかった Web サイトアクセス待ちに、集団として相当な時間を費やすことになる

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Lobste.rs のコメント

  • Anubis が狙っている相手が簡単に無力化できる、という話には同意しにくい。Anubis の主な目的は LLM エージェントやバイブコーディングで作ったプログラムではなく、LLM 企業が使う無差別なウェブスクレイパーを止めること
    回避方法はあり、エージェントや LLM を活用することもできるが、大多数のスクレイパーは単純で、運用者も Anubis を導入した少数のサイトまでわざわざ回避しようとはしない。回避コストを少し上げて、収集する価値をなくすことが目的に近い

    • Anubis は、住宅用プロキシを使うスクレイパーがサーバーを麻痺させる状況を防ぐにはよく機能するはず。個別エージェントのリクエストは、ユーザーが直接サイトを見て回るのと大きく変わらない
      ただし、この目的には Anubis は過剰設計だ。ボタンを一度押させたうえでアクセス Cookie を発行しても同じ保護効果は得られるし、Apache に実装してみたところ、複雑なプルーフ・オブ・ワークなしでも十分うまく機能した
    • LLM 企業のスクレイパーというより、粗雑で濫用的なウェブスクレイパー全般が対象。その一部を LLM 企業が運用しているという推測があるだけ
    • ウェブサイトで増えたトラフィックは OpenAI、Anthropic、Meta のようなところではなく別の主体から来ており、何を LLM 企業と定義するのか不明確
      私のデータマイニング作業でも使っている現代的なスクレイピングツールは、障害物をほぼすべて回避できるほど優秀で、Anubis も簡単に回避できる
    • 個人サイトやソフトウェアへの RAG アクセスも防ぎたいので、基本的なユーザーエージェントのブロックを適用している。ChatGPT で直接サイトへのアクセスを頼んで試したところ、うまくブロックできた
      非常に特殊な構成なら抜けられるかもしれないが、悪意ある相手ではなく怠惰な相手を止めるのが目的
    • Anubis が主に止めているのは、Chrome のふりを雑にした初歩的な Python requests スクレイパーであり、それ以外のブロック効果はおまけに近い

  • Anubis はボットをふるい分けるのではなく、クライアントのリクエスト速度を制限するもの

  • Anubis は AI エージェントのアクセスを防ぐというより、サービス拒否攻撃への防御手段に近く、現実的に AI エージェントを判別してブロックするのも難しい
    ただし、モバイル端末で見慣れないサイトを訪れ、JavaScript をオフにしている私のようなユーザーも一緒にブロックする

  • 実際の運用結果を見ると、記事の結論には同意しにくい。ホームラボのウェブサイトを fly.io の公開プロキシと Tailscale のフォワーディングで提供していたところ、Facebook をはじめとするスクレイパーのせいで毎月約20ドルの帯域料金が発生していた
    プロキシに Anubis を導入した後、無料枠に戻った。必要なら回避できても構わないし、robots.txt を無視する少数の悪質な主体による大量収集トラフィックの大半をブロックできれば十分

  • スマートテレビのような低性能デバイスのボットネットを利用するスクレイピング作業には、Anubis のプルーフ・オブ・ワークが実際の障害になり得るように見える。 https://lobste.rs/s/kpaxih/update_on_scraper_situation でもこの問題が少し扱われている

    • 私が誤解していなければ、スマートテレビはプロキシとしてのみ使用され、プルーフ・オブ・ワーク自体は実行しない

  • Anubis で最も気になる部分は、オープンウェブとの衝突だ。私のウェブサイトは主に RSS フィードで消費されているが、RSS を Anubis で保護するとフィードが動かず、保護しないとすべてのコンテンツが機械に読みやすい形でスクレイパーにさらされる
    このようなプルーフ・オブ・ワークの障壁は、私たちが目指していたオープンウェブやインディーウェブとは根本的に両立しにくい

    • この1年、こうした不可能な妥協案の間に閉じ込められており、私自身も良い答えを見つけられていない

  • 他人が下した選択を尊重しない態度が露骨に表れている

  • 最も不快なのは、これが CFAA のような法律に明白に違反する行為に見えるにもかかわらず、ほかの犯罪的な DDoS サービスのように身元を隠していること
    他人の成果物を盗み、オープンソースコードをロンダリングすることに事業モデル全体を依存している企業が、法律を守ると期待すること自体が滑稽

  • Anubis は通常 Dillo をブロックしないが、サイト設定によってはブロックされることもあり、これは JavaScript がなければ存在する資格もないという空気を助長するので非常に厄介: https://paste.rs/jNgwd.png
    住宅用プロキシに含まれるすべての IP リストを収集・管理し、一定期間ブロックできるか検討中で、ipset ならこの規模に耐えられるかもしれない。ログを見ると、ボットは CSS や画像のような他のリソースは読み込まない一方で、Dillo リポジトリのすべてのコミットにあるすべてのファイルを巡回するため、比較的簡単に識別できる
    各サイトでは IP あたり1件のリクエストしか見えなくても、同じ IP が複数のサイトを取得している可能性が高いので、複数回報告された IP をブロックできる。単に接続を切るのではなく、別ポートの案内ページにリダイレクトして、ブロック理由と解決方法を知らせるべき
    そうすれば、ブラウザー拡張や携帯電話アプリにリバースプロキシのバックドアを仕込む誘因も減る。ユーザーが実際にブロックされ始めるからだ
    IP レピュテーションシステムに依存せざるを得ないのは残念だが、他に効果的な対策はあまり見当たらない。脆弱なデバイスはボットネットのコマンド＆コントロールサーバーが取り除かれても、次の攻撃者に再び乗っ取られ、新しいボットネットに組み込まれ得る

  • 記事で「もちろん LLM の助けを借りてこの作業をしている」と述べていたが、それならなぜバイブコーディングタグが付いていないのか気になる

    • 著者がコンパイラやエディターを使っていてもそのタグを付けないのと同じで、この記事の主題はバイブコーディングではないから。vibecoding タグは pushcx が削除した
    • 投稿時には、ブロックを回避する何かをバイブコーディングしたと記事に明記されていたので、そのタグを付けた。これより AI コーディングへの言及が少ない記事にもタグが付くことがあるので、削除されたのは意外だが、このタグの適用基準はまったく一貫していないと受け止めるようになった