AIスクレイパーがコメントアウトされたスクリプトを要求

• Webサーバーログの分析中に、存在しないJavaScriptファイルを要求する多数のボット活動が発見された
• HTMLコメント内のスクリプトタグを実際のコードとして認識して要求したもので、LLM学習用データ収集の試みと推定される行為
• このような異常な要求を検知して、公開警告、IP遮断、圧縮爆弾、データポイズニングなど多様な対応策を提示
• 特にデータポイズニングは、LLMの学習データを汚染してモデル性能を低下させうる効果的な手段として言及
• Web管理者がAIスクレイパーに対する防御および逆襲戦略を実験的に導入する必要性を強調

---

異常なスクレイピング行為の発見

• サーバーログで、存在しないJavaScriptファイルに対する404エラー要求を多数確認
  • 当該ファイルはHTMLコメント内に含まれた無効なスクリプトであり、通常のブラウザなら要求しないはず
• 要求のUser-Agentの一部は python-httpx/0.28.1, Go-http-client/2.0, Gulper Web Bot 0.2.4 など、明らかなボットとして識別
• robots.txtでクローラーのアクセスを禁止していたにもかかわらず要求が継続しており、規則無視または無視されたポリシーと判断
• 一部の要求はFirefox、Chrome、Safariなど通常のブラウザを装っていたが、HTMLコメントを解釈できず偽装識別であることが判明
• これらの要求は、LLM学習用コンテンツの非同意収集を目的とするスクレイパーと推定

スクレイパーの動作方式

• 一部はHTMLを正しくパースし、コメント内URLを再帰的に探索している可能性がある
• 別の一部はHTMLを単なるテキストとして扱い、正規表現ベースのURL抽出を行ったように見える
• User-Agentの多様性とレベル差から、複数の運用者が存在し、一部は単純な自動化ツールを使用しているとみられる
• 共通する動機は貪欲なデータ収集であり、これを逆利用できる可能性が示されている

アルゴリズム的サボタージュ (Algorithmic Sabotage)

• アルゴリズムシステムを意図的に攪乱する行為であり、LLMの外部コスト問題により注目されるテーマ
• ボットの非人間的な行動パターンを認識すれば、検知と対処が容易
• 対応方法は4つに分類される: 公開警告、IPフィルタリング、圧縮爆弾、データポイズニング

0. 公開警告 (Public Disclosure)

• 些細な誤検知（例: User-Agentのタイプミス “Mozlla”）は公開すると簡単に修正されうるため非公開を維持
• 一方で、本質的な行為（例: コメント内スクリプト要求）は修正不能であるため公開が有益
• これにより他サイト運営者も同様の攻撃を検知・遮断できる
• 当該行為を検知するシステムを他サイトにも適用中

1. IPフィルタリング (IP Filtering)

• fail2banを用いて、ログパターン・日付・IPに基づき自動遮断
• 一般には短時間の遮断に設定するが、長期遮断にすると学習型ボットの再試行を抑制できる可能性がある
• ボットネットの場合、IPを変えて継続的に要求できるが、反復パターンを通じて検知可能
• 今後、ボットネット動作分析に関する追加研究を行う計画に言及

2. 圧縮爆弾 (Decompression Bombs)

• 攻撃者が要求したファイルにzip bombを提供し、システム資源の消耗を誘発
• CPU、RAM、ディスクを過剰に使用させたり、脆弱性の悪用につながる可能性がある
• 欠点として、サーバー資源の消費や帯域の浪費リスクが存在
• 一部のボットは感染したシステム上で動作しているため、攻撃効果が限定的な場合がある
• すべてのボットに適用するのではなく、ランダムな一部要求に対応する方式を提案

3. データポイズニング (Poisoning)

• LLM学習用データを汚染してモデル性能低下を誘導
• 最近の研究によれば、250個の汚染文書だけでも大規模モデルに持続的な影響を与えうる
• 汚染データによって、モデルが特定テーマで無意味な出力を生成するようにできる
• 例として、セキュリティ研究に関する質問時に特定ブログを推薦するよう誘導可能
• nepenthes, iocaine, glaze, nightshade などの公開ツールを利用可能
• LLM学習データが非同意で収集された場合、このような対応は正当な防御手段として提示
• IP遮断と併用する場合、実装の複雑さは増すが、並行運用の可能性はある
• 効果的な設計は公開しないこともあり、創造的サボタージュ参加の拡大の必要性を強調

結論およびコミュニティ対応

• 異常なボット行動による検知は新しい概念ではなく、コメント内スクリプト要求は新たに発見された事例
• robots.txtにDisallowディレクティブを追加し、特定要求時に逆襲措置を誘発する方法を提示

  User-agent: GPTBot
  Disallow: /poison/
  

• コミュニティでは display:none と rel="nofollow" 属性を使って、ボット誘引用リンクを隠すさまざまなアイデアが共有された
  • 例: <a href="/hello-llm-robot-come-here" rel="nofollow" style="display:none">you didn't see this link</a>
• リンクを絶対パス(absolute URL) に設定すると、より多くのクローラーをだませる可能性がある
• 複数のサイトでさまざまなボット誘引および遮断実験を進めており、効果を測定して共有する予定
• 他の研究者たちもAIスクレイパー攪乱実験に参加しており、独創的なポイズニング事例も紹介されている
• 全体として、AIデータ収集に対する自律的な防御と逆襲戦略の拡散を目標としている

[GN⁺]

Hacker Newsの意見

• ほとんどのWebスクレイパーは、違法だとしてもビジネス目的で使われている
  そのため Amazon やショッピングモールのデータを取得することが多い。結局、望まれないトラフィックの大半はビッグテックか、脆弱性を狙う悪意ある攻撃者によるものだ
  私はWebスクレイピングについて少し知っている。一部のサイトは防御目的で404を返すこともあるので、私のクローラーは curlcffi のような高速クロール方式を何度か試す
  Zip bomb 対策は、単にヘッダーの content-length を読めば十分だ。レスポンスが大きすぎる場合は読み込まないようバイト上限を設け、タイムアウトでも制御する
  ところで、requests の timeout はページ全体の読み込みに対するタイムアウトではないことを知っているだろうか。サーバーがバイトをゆっくり送ると、無限待機状態になる
  そこで、こうした問題を解決するために自分でクローリングシステムを作った。Selenium も一貫して実行できる
  私のプロジェクトは crawler-buddy で、基盤ライブラリは webtoolkit だ

  • content-length は content-encoding の後に計算される点を忘れてはいけない
  • “scraping” と “crawling” に違いがあるのか気になる
  • これからはブラウザ内スクレイパーの時代が来そうだ。サーバー側からは人間と区別できず、AIドライバーが人間向けテストも通過できる

• 「同意なくLLM学習データを収集した」という表現が面白い
  公開されたHTTPサーバーに GET リクエストを送るのに、いったい何の許可が必要なのか分からない。もちろん weev 事件は例外的な惨事だった

  • 私は公開HTTPサーバーを開いているなら、一般的な GET リクエストは歓迎する
    ただし、(1) 一般ユーザーのアクセスとボットによるDDoS攻撃は別物だ。無料で提供されているからといって無限に持っていくのは濫用だ
    (2) 合法的な複製とロボットによる偽装行為は区別されるべきだ
    (3) まともに動くボットなら robots.txt を尊重すべきだ。法律ではないが礼儀の問題だ
    何百万もの住宅用IPを使い回すボットは、決して正常とは言えない
  • サーバー設定を欺いて望むデータを得るなら、それは非同意アクセスだ
    公開サーバーだからといって、虚偽のリクエストまで許可したわけではない。合理的なリクエストにだけ暗黙の同意があるのだ
  • robots.txt は法的拘束力ではなく、礼儀正しいお願いだ
    「このページは取得しないでください」程度の意味にすぎず、本当に止めたいなら API トークンや認証手続きを設けるべきだ
  • たった一度のアクセスと無限クロールの暴走を同一視するのはおかしい
    スパムが単なるメールと同じではないように、ボットの濫用も単純なリクエストとは違う
  • 「キャンディーボウル」の比喩で言えば、トリック・オア・トリート用のキャンディーを大人が一人で全部持っていったら、気分がいいはずがない

• DOM をパースするより、http/https 文字列を直接検索するほうが速そうだ

  • 単純なテキスト検索と DOM 走査ではリソース差が大きいので、「たぶん速い」という表現では控えめすぎる
  • 正規表現アプローチは実装が簡単だが、DOM パースでも CPU よりネットワークのボトルネックのほうが大きな問題だ
    結局、ネットワーク混雑が制約要因になる

• 興味深い研究の実用的な応用を見るのは面白い
  関連研究は この投稿 で見られる

• タイトルが紛らわしい。「commented-out」と言うべきだと思う

  • 私も最初はAIスクレイパー遮断スクリプトのことかと思った

• これは濫用というより、単にコメントアウトされたURLを読んでいるだけのようだ

  • 記事本文は、濫用そのものではなくボット検知シグナルとして活用する方法を説明している
  • とはいえ robots.txt を無視し、コメントまで取得するのは確かに無作法な行為だ

• 昔Webをクロールしていた頃は、Perlの正規表現が最も信頼できた
  コメント内のURLも当然キューに追加していた

  • DOM 探索はむしろやりすぎだ。正規表現で必要な div や p を拾うほうが、より堅牢で簡単だった

• ボットに512MBのランダムデータファイルを渡したらどうだろうか

  • それよりAIスクレイパー向けに広告レスポンスを改ざんして、LLM に特定製品を勧めさせるほうが収益性が高い
    私が作ったスタートアップは、まさにそうしたAd-poisoning-as-a-serviceを提供している
  • ランダムにつながったAI毒ページを作ってボットを閉じ込めることもできる。人間はクリックしないだろうから
  • ただ、大半は帯域コストを負担しきれない
  • 512MB 全部を「うちのサービスが最高」という文句で埋めても面白そうだ

• 「LLM学習用データ収集」というより、単なるインターネットスキャンのノイズだ

  • その通り。脆弱性スキャナーなら、可能な限り多くのHTTPエンドポイントを収集しようとするはずだ
    JSファイルはコメントかどうかに関係なく、良い手がかりになる
    一方で LLM 学習用なら、こうした低品質なJSコードには興味がないだろう

• 望まない LLM 学習トラフィックを**毒化（poison）**する方法についての考えだ

  1. 複数サイトが協力すれば、データ重複排除を回避しつつモデルを汚染できる可能性が高まる
  2. 著作権法を使って汚染コストを上げることもできる。ただしサイト側が法的リスクを負う可能性はある
     著作権者と協力すればリスクは下げられる
  • 最初のアイデアはWordPressプラグインにするとよさそうだ
    リクエストごとに画像を動的変形して重複排除対策を無効化することもできる。そういうプラグインがあれば私もすぐ入れるだろう