攻撃的なAIスクレイパーがWiki運営をかなり厳しくしている

 (weirdgloop.org)
5 ポイント 投稿者 GN⁺ 2 시간 전 | 2件のコメント | WhatsAppで共有
  • AIスクレイパー のトラフィックは公開Wikiのコストと安定性を揺るがしており、緩和しなければ人間の活動全体より約10倍多い計算資源を使いかねない
  • ボットは GPTBot のような識別しやすい User Agent を超えて、最新の Chrome のようにヘッダーを偽装し、1日に100万件のIPを回す住宅用プロキシで回避する
  • Wikiは記事よりもはるかに多い 過去版・編集画面・特別ページ のURLを公開しており、単純なクローリングがキャッシュを回避して通常リクエストの50〜100倍高コストになることがある
  • Cloudflare Challenge、Anubis、手作業のファイアウォール、人間行動リクエスト ベースの検知は有効だが、誤検知や保守負担、読者との摩擦も生む
  • ログイン強制や全面的なチャレンジのような極端な遮断は新規貢献を減らしかねず、運営者同士の 公開討論 と、ボット収集の誘因を変えるAPIアクセスが必要になる

AIスクレイパーがWiki運営に与える負担

  • LLM学習データのためのボットスクレイピングが前例のない規模で増え、公開Webサイトのコストと安定性を揺るがしている: 関連する問題は FOSS infrastructure is under attack by AI companies、Are AI bots knocking cultural heritage offline?、Smart TV web crawler AI でも扱われている
  • Weird Gloop は Minecraft Wiki、OSRS Wiki、League Wiki のような大規模ゲームWikiをホスティングしており、ここ3年で ボットトラフィック対応 にますます多くの時間を費やしている
  • 継続的に緩和しなければ、ボットは数千万件の人間のページビューと1日数万件の編集を含むその他すべてを合わせたものより、約 10倍多い計算資源 を使う可能性がある
  • Wikimedia Foundation もクローラーが運用に与える影響を扱った記事を出しており、主要なWikiファームはさまざまなレベルの障害を経験し、一部の小規模な独立Wikiは完全にオフラインになった
  • 今年のWikiエコシステムにおけるサーバー問題の約 95% は、悪質なスクレイパーが原因だと推定される

人間のように見せようとするスクレイパー

  • GPTBot、ClaudeBot、PerplexityBot のような主要AI企業の「公式」ボットは robots.txt を守れなかったこともあるが、通常は User Agent 文字列で識別できるため、CloudflareのAIボット遮断や nginx で止めやすい
  • Web管理者が User Agent ベースでAIスクレイパーをブロックし始めたことで、ボットには 人間トラフィックのように偽装する 強い動機が生まれた
  • 最近Wikiに到達するAIスクレイパートラフィックの大半は、最新の Google Chrome のように見えるようヘッダーを送り、リクエストを巧妙に構成している
  • 以前使えていた明確な「ボットか実際の人か」というシグナルが消え、ブロックが難しくなった

数千万IPとプロキシ回避

  • 2023年以前は、問題のあるスクレイピングの95%が単一のIPアドレスまたは小さなデータセンターのサブネットから発生しており、IPまたはISP特性に基づくブロックがおおむね有効だった
  • 住宅用プロキシ を使えば、クレジットカードだけで数百万IPアドレスのネットワーク経由にスクレイピングリクエストをロンダリングできる
  • Wikiは1日に 100万件のIP を循環させるスクレイパー実行に直面することもあり、Comcast、AT&T、Charter などの住宅向けISPから来た正当なリクエストのように見える
  • 当該顧客は、自分のIPが住宅用プロキシの出口ノードとして使われていることに気づいていない可能性が高い
  • 一部の悪意ある行為者は facebookexternalhit のリンクプレビュー や Google Translate を利用して、リクエストが Google/Facebook のサーバーから来たように見せ、実際の出所を隠す
  • Google Translate のURLツール経由で来るリクエストの 99.99% が悪用的だったケースもあり、かつては全Wikiでそのツールを壊さざるを得なかった

Wikiで特に高コストな「間抜けなURL」クローリング

  • 多くのAIスクレイパーはWikiのホームページを訪れたあと、そのページ内のすべてのリンクを訪れ、さらにそのページ群のすべてのリンクを訪れる方法でURLを選ぶ
  • robots.txt やサイトマップがスクレイピングする価値のあるURLを示しているのに、それを認識していないように見える
  • OSRS Wiki には約 4万件の記事 があり、これらのURLがサイト上の有用な情報の大半を構成している
  • しかし 過去版、編集画面、特別ページ まで含めると、探索可能なURLは少なくとも 10億件 に達する
  • このような単純なクローリングは終わりがなく、LLM学習データとして有用でないURLに多くの資源を費やしているように見える
  • 奇妙なリクエストは、実ユーザーのリクエストが通る MediaWiki parser cache のようなキャッシュ層を回避し、サービスコストを押し上げる
  • キャッシュヒットしたリクエストの処理時間は通常 20ミリ秒未満 だが、古い diff のようなリクエストはしばしば 1〜2秒 かかる
  • 「1日800万件のボットリクエスト」「ボットが帯域幅の65%を使用」といった上位指標は問題を過小評価している
  • 実際のボトルネックはたいていCPU容量であり、奇妙なクエリパラメータ付きのボットリクエストは通常リクエストより 50〜100倍 高コストなことが多い

平均指標では見えないトラフィックスパイク

  • 月間ボットリクエストは約 2億5,000万件、平均では毎秒約 100件 程度だが、これは長期平均にすぎない
  • スクレイパーは短時間に毎秒 1,000件以上 のリクエストを送ることが多く、従来型のDDoS攻撃とほとんど見分けがつかない
  • 長期的にボットが全CPU使用量の約 50% しか占めていなくても、悪質なトラフィックスパイクがWikiの遅延や障害の約 95% を引き起こしている

誰がやっているのか分かりにくい構造

  • トラフィックを「AIスクレイパー」と呼んでいるが、どれも Google Chrome のように偽装しているため、実際の責任主体やWikiデータを何に使っているのかは分かりにくい
  • 想定される主体としては、データブローカー、frontier lab による重複収集、住宅用プロキシにアクセスできる独立プロジェクトなどが考えられる
  • 参入障壁が実際にどれだけ下がったのかも不明だ
  • もっと良い方法があるなら、実際の収集主体と直接連絡を取り、より非効率でない方法を探したいとしている

これまで効果があった対応

  • Cloudflare Challenge と Anubis

    • Webサイトを Cloudflare challenge や Anubis のようなツールの背後に置く方法が、この1年でインターネット上に広く普及した
    • ある程度の効果はあるが、一部のボットが継続的にチャレンジを通過する時期がある
    • Cloudflare とボット開発者のあいだには見えない軍拡競争があるようで、Cloudflare が約 90% は勝つものの、残る10%が運用上つらい領域を生む
    • 実際の読者は、Wikiに到達する前にチャレンジを見ることを嫌う
    • 大半の人に影響を出さないためには、どのトラフィックにだけチャレンジを課すか判断する良いヒューリスティックが必要だが、自動化トラフィックを安定して検知すること自体が難しい

  • 手作業のファイアウォールルール

    • ほとんどの運営者は、自分のインフラや過去の攻撃に合わせた 手作業のファイアウォールルール を持っている
    • こうしたフィルターは通常、特定の User Agent 文字列、IPグループ、ASN に基づく
    • Weird Gloop は大半を Cloudflare/CDN レベルで処理しているが、他のWikiは nginx やWebサーバー側で処理することもある
    • 現在は User Agent/IP だけでは不十分なことが多く、HTTPバージョン、ヘッダー、TLS cipher、ja4 関連ハッシュのような、より複雑なリクエスト属性を見る必要がある

  • 「人間はするがボットはしないこと」を探す

    • 有用な観点は、人間が集合的に行う行動 のうち、ボットがしないものを見つける方法だ
    • MediaWiki ベースのWikiには、実際のブラウザ利用者がWikiを使うとき頻繁に発生させる複数種類のHTTPリクエストがあり、ボットは通常これを発生させない
    • ヘッダー、ja4 ハッシュなどで分離できるトラフィック群が多数の記事を訪れているにもかかわらず、典型的な「人間」リクエストを発生させていなければ、そのトラフィックにチャレンジを適用する強いシグナルになる
    • ボットトラフィックに 存在しない人間行動リクエスト を見る方法は強力だ
    • 「欠けている」トラフィックを分析し、どのトラフィックにチャレンジを課すべきかを決める決定木ベースのヒューリスティックを自動提案するシステムを作り始めている
    • テストではほぼすべてのスクレイパーをうまく見つけられるように見えたが、NoScript 利用者、スクリーンリーダー利用者、想定外のデバイス利用者のような、特異な閲覧習慣を持つ人への誤検知がどうなるかは明確でない
    • 独自のML/データ分析インフラを構築し、恒久的に維持することも負担として残る

  • さらに特殊な検知手法

読者にとって悪い極端な選択肢

  • AIスクレイパーを止める「核オプション」は、実際の利用者にとってはるかに破壊的だ
  • よくある方法の1つは、生成コストが大きくなりうるページを見るにはログインを要求することだ
  • Fandom は数カ月前、すべてのWikiにこうした措置 を適用した
  • 別の方法は、すべてのトラフィックに Cloudflare challenge を出すことだ
  • Web管理者の立場からは理解できるが、Wikiとコミュニティの長期的な健全性には悪い
  • 16年間Wikiコミュニティを作ってきて得た重要な教訓は、新しい貢献者を引き込む最良の方法が 摩擦の除去 だという点だ
  • 編集をより簡単にし、Wiki内部の構造をより簡単にたどれるようにし、読者と編集者を隔てる参入障壁を下げる必要がある
  • 極端なアンチボット手法は新たな摩擦を生み、予測可能な結果をもたらす
  • Fandom がアカウントを持たない読者 95%以上 に「内部ページ」を隠したあと、Fandom全体の新規ユーザー貢献が約 40%減少 したことが示された
  • このようなトレードオフを価値があるとは見なしにくい

今後の方向性

  • Weird Gloop は今後もWikiホスティングを続け、Fandom から離れようとするWikiを支援する取り組み も継続している
  • 長期的には「AI Overviews」がWiki読者をWiki貢献者へ転換するパイプラインを壊す可能性があるが、これは別の問題として残している
  • 一部の知人はボットの波が Weird Gloop に有利に働くかもしれないと見るが、人々が容易にWikiをホストできなくなれば、インターネットはさらに悪くなる
  • Wikiを安定してホストするために、オンコールローテーション、MLエンジニア、エンタープライズ製品が必要になるシナリオは、独立Wikiコミュニティにとって非常に悪い知らせだ
  • ボット所有者とWeb管理者の軍拡競争は、スクレイピングの構造的な誘因を変える巧妙な方法が出てくるまで続く可能性が高い
  • Cloudflare の新しい crawling API は、ボットにとって robots.txt を無視して問題を起こす独自システムを作るよりAPIを使うほうが簡単になれば、構図を変えるかもしれない
  • スクレイピングがそもそも起きないのが理想だが、すでに起きてしまったことを元に戻すのは難しい

公開討論と協力の必要性

  • 何千人もの運営者がそれぞれのWebサイトを運営しながら、ボットに対処するより賢い手法を探している
  • 他のシステム管理者との非公開の会話では具体的で優れたアイデアがあり、Slack、Discord、小規模グループ内でも多くの議論が行われている可能性が高い
  • 実際の運用上の具体事項について、より多くの 公開討論 が必要だ
  • 多くのシステム管理者は、自分が抱える問題が他の運営者とほぼ同じだという事実を十分に認識していない
  • 誰もが自分の防御方法を公開したいわけではなく、公開すれば優位を失うのではないかという懸念もある
  • それでも、人々が知恵を持ち寄れるようにするなら、戦術の一部の効果が薄れるリスクは受け入れる価値がある
  • AIスクレイパーに対処しているシステム管理者は、自分に合った場で効果があった方法を共有したほうがよい
  • ボット問題の解決製品を販売する企業は、不自然でない状況での precision and recall の比率に関する実質的なデータを含むケーススタディを、もっと公開すべきだ
  • 購入判断を行う人々は、チェックボックスを埋めることではなく実際の結果を重視する
  • Wikiや独立Webサイトを運営し、ボット検知について議論したいなら、メールまたはDiscordメッセージ で連絡できる

関連記事

2件のコメント

 
xguru 43 분 전

基本的にGeekNewsにも非常に多くのクローラーが来ているので、さまざまな方法を導入して遮断したり、コストを最適化したりしています。中国系のAIボットは、本当にかなり深刻なレベルでクローリングしてくるんですよね。

でも、いざCDN側で遮断しようとするとコストが発生するのも問題ではあります。
 
GN⁺ 2 시간 전
Lobste.rsの意見

  • Anubisの欠点を補うために待機証明（proof-of-wait）チャレンジを試したところ、かなり効果があった
    基本的には、グローバルなリクエスト率が閾値を下回っている間はフィルタを無効にし、閾値を超えたらユーザーは先に進む前にN秒待たされる
    その後、そのIPに紐づいたトークンを発行し、有効期限内で少量のリクエストだけを許可し、トークン自体にもレート制限を設ける
    成功リクエストが続くと、待機時間は徐々に長くなる
    かなりうまくいっており、モバイル端末が過度に不利にならないよう    緩やかに性能低下    し、JavaScriptなしでも動作する

    • marginalia.nuでこの方式が動いているのを見たが、携帯電話のバッテリーを作業証明に浪費しないのが気に入っている
    • 公開コードの一部なら、これを実装したソースコードへのリンクをもらえると気になる
    • いいね。こういう方式をTLSの一部にしようとする取り組みがあるのか気になる。作業証明チャレンジについてはdraft-venhoek-tls-client-puzzles-00がやろうとしていることに近い感じがする
      こういうものはTLSや、ひいてはOSのIPスタックのような、もっと下位レイヤーにあるべきだと思う
      待機証明について深く考えたことはないが、正当なユーザーにとっては自動スクレイパーより待機のほうがずっと悪く作用しないだろうか？ 人間は待たされると苛立つが、スクレイパーはトークンを保存してN秒後に戻ってくればいい
      作業証明にも複雑な思いはあるが、少なくともスクレイパーには規模に応じた実質的なコストを課せる
    • 設定が簡単なのか気になる。自分のWikiでも興味がある
    • 有用なアプローチに見える。詳しい内容をまとめる予定があるのか気になる
      待機証明は作業証明に懸念を持つ人たちを安心させることもできそうだ

  • 特定の特別ページは、一度ログインしてそのクッキーが設定されたクライアントだけアクセス可能にし、それ以外は拒否する方式もかなりうまく機能する
    たいていのクローラーはWikiをなめるために特別ページを狙うので、ログインユーザーに限定できる
    この設定ではWikiはユーザー作成を許可していない
    <If "%{REQUEST_URI} =~ m#^/wiki/index.php(?:/.)?$# && %{HTTP_COOKIE} !~ /[-a-zA-Z_]+UserID=/ && ( %{REQUEST_URI} =~ m#^/wiki/index.php/Special(?::|%3A)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)(?:/.)?$#i || %{QUERY_STRING} =~ /(Special(%3A|:)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)|action=(edit|history|info|pagevalues|purge|formedit)|oldid=)/i )">
    ErrorDocument 403 "アクセス拒否、ログインしてください。"
    Require all denied
    </If>
    これで我々のシステム負荷は大きく下がった。以前は特別ページを激しくクロールされ、Wikiが使い物にならないほどになるピークが頻繁にあった
    そのほか、既知のAIクローラーのユーザーエージェントは即座に403で遮断し、AlibabaやAmazon Cloudのような特定のIP帯域もブロックしている
    面白いことに、向こうもこれに気づいた。Diff表示でページをなめていたのを制限したら、MobileDiff表示で同じことを試してきた
    何度かいたちごっこはあったが、数か月前からはこの方式で順調に回っている

    • ユーザーエージェントベースの遮断は、実際のところできることの中でもほぼ最悪に近い
      ユーザーエージェントで防ぐと、クローラーは人間らしく見えるユーザーエージェントでもう一度試しながらサイトを探索する
      遮断トリガーがユーザーエージェントだと判断すると、地獄モードに入り、識別がはるかに難しくなり、サイトが死ぬまで叩き続ける
      IP帯域の遮断も役には立つが、モバイルマルウェアのプロキシでクロールしてくるので十分ではなく、全てを捕まえることはできない
      そもそも遮断しなければ、たいていは比較的大人しくしている
      だから遮断の代わりに、安価に生成したゴミデータを食わせて地獄モードを引き起こさないのがコツで、自分はhttps://iocaine.madhouse-project.org/ を使っている
    • 参考までに、MediaWikiの権限でもできる。デフォルトを全権限拒否にして、匿名ユーザーにはデフォルト名前空間のページ読み取りだけを戻せば、いたちごっこはなくなる
      ただしそうするとMediaWikiが直接レスポンスを配信しなければならないので、Apacheで処理する利点もある
    • すぐに気づいたのかは気になる。スクレイパー作者たちはすでに複数の代替手法を用意していて、403を受け始めたらボットが次の手を順番に試しただけだと思う

  • 脇道だが、Weird Gloopは素晴らしいサービスだ。運営しているWikiの品質は非常に高く、ファン制作コンテンツをFandomのひどいプラットフォームから移してくるのは世の中のためになる

  • Gergely Nagy, a.k.a. algernonことiocaineの開発者は、この問題にしばらく取り組んできており、Weird Gloopに役立つ洞察を持っている可能性が高い

  • こう言いたくはないが、人間の行動に合わせてチューニングしようという提案は、あとで足をすくわれそうだ
    ボットがページの静的アセットまで全部リクエストし始めて、それが人間を識別する行動の一部だと仮定するようになるだろう
    面白いゲームですね、ファルケン教授

  • スクレイパーが普通の<a href=...>リンクを再帰的にたどってこうしたページに到達しているなら、履歴差分のような高コストでキャッシュされないページを<form method="POST" action=...>送信でしかアクセスできないようにして、穏やかに別の場所へ誘導できないだろうかと思う
    何も遮断せず、実質的にはスクレイパー側にとってもほぼ無限の重複情報を再帰的に摂取しなくて済むので得になる
    一般ユーザーもほとんど違いに気づかず、手間に対する効果は悪くなさそうだ。匿名ユーザーにはAnubisより良いかもしれない
    これはスクレイパーがmethod="POST"のHTTPフォームを送信しないという前提に依存している
    それが概ね事実でないなら、AIスクレイパーが匿名編集を大量送信してWikipediaの内容をランダムなゴミに変えた、という見出しをもう見ていたはずだ

    • そうするとレスポンスもキャッシュ不可になってしまうので、CDNに依存しているなら問題になるかもしれない
      ボットが<form method="GET">も押すのか気になる。これならキャッシュと相性がよく、クローラーには追加ロジックを要求できる

  • 自分の小さなブログのトラフィックの95%はSingaporeとChinaのLLMスクレイパーから来ている

  • 何年も経っているのに、誰もIPを追って連絡し、直接訪ねて行けるような小さなISPのIPを一つも見つけられなかったのか？ そのユーザーのところへ行って、コンピュータを調べてもいいか丁重に尋ねることすらしなかったのか？ 実際にどんなソフトウェアがクロールしているのか、誰も突き止められなかったのか？
    サイト運営者がこの程度もできないなら、もう気にしたくない。実際に汚れ仕事の人間同士の接触を避けようと必死になるから、ボットを抱えることになる
    そして住宅用ボットネットで動くボットは、ときにCAPTCHAやAnubisを通過できるだけの計算資源を当然持っている
    サーバー側が恒久的に勝つことは不可能だ。そのコンピュータの利用者も正当なトラフィックを生み出すからだ
    だからリモート証明を求めないなら、そのIPのところまで行くしかない

    • 住宅用ボットネットの規模を過小評価していると思う
    • 問題は、トラフィックが何万もの異なるIPから来ていることだ
      世界中を車で回る燃料代のような現実問題を抜きにしても、とてつもない巡回セールスマン問題になる
    • 本当に驚くほどひどい意見だ
      いくつかのボットのせいで、システム管理者が少し大人しくしてもらうために週末じゅうどこへでも車で行けばいい、という発想は、特にその大半が大手か海外系ISP由来であることを考えると笑うしかない
      何を吸ったのかと聞きたくなるほどだ
      今どんなソフトウェアがクロールしているのかって？ 誰かがチャットボットに「これをスクレイピングするものを作って」と頼み、各スクレイパーが個別に作られている、という話だ
    • 「誰も」という問いが合理的なのは、その仕事をする能力と動機、あるいは責任を持つのが誰なのか言える場合だけだ
      そうでなければ、ただ抽象的に全宇宙を責めているだけになる
    • 小さなISPに連絡して訪ねていくというのは現実的ではない
      ほとんどのサービスプロバイダは、自分たちのIPがどのWebサイトのスクレイピングに使われているかなど全く気にしないと断言できる
      しかも、そのプロバイダがIPに紐づく住所を教えることもないと断言する
      もっと効くのは、AlibabaやAWSのような複数プロバイダに関係するASNトラフィックを丸ごと捨てることだ
      いつでも可能な選択肢ではない。たとえばAtomフィードのあるブログなら、フィードリーダーまで一緒に塞いでしまうかもしれない
      だが多くの場合、ゴミトラフィックの80%を消せる

  • こういう挙動がなぜ起きるのか知っている人はいる？ 特にスパイクがなぜ発生するのか気になる

    • 聞いた仮説では、ボットネットの信頼性が低く、住宅用プロキシでボットネットアクセスを売っている人たちが、その不安定さを重複リクエストで補っているという
      本当かどうかは分からないが、少なくとももっともらしい
      インフラをもっとよく理解していないと断言しにくい。コマンド・アンド・コントロールの限界かもしれない
      ボットネットがDDoS向けに作られているなら、構造上、きめ細かな制御が足りない可能性もある