git.kernel.org の CPU の20%がAIクローラーに消費されている
Creepy Crawlies
git.kernel.org の管理者が、AIクローラーによる負荷の実態を数値で報告。全トラフィックの約98%がスクレイパーで、14〜16コアが常時HTMLレンダリングに専念している。クローラーはgit cloneではなく、非効率なHTMLスクレイピングを選択。AnubisによるProof-of-Work認証も一時的な効果しかなく、現在は住宅用IPを使った巧妙な回避が横行。機能制限などの対策を余儀なくされている。
平均すると、これは全容量の20%に相当します。ただし、群れは波状に襲来するため、実際のグラフは20%の平坦な線よりもはるかにギザギザしています。
HNでの議論
304- semiquaver
> どうやら私たちが提供しているものは、Anubisのチャレンジを計算するために大量のサイクルを費やす価値があるらしい。
この発言には、Anubisに対する根本的な誤解がある。それは大量のサイクルではない。ボットにとっては不便だが、モバイル端末の人間にとっては使えるような難易度設定は存在しない。
先日、lists.ffmpeg.orgがAnubisの難易度レベル6に移行したことに気づいた。私のiPhone 17では約100KH/sで解くのに約180秒かかり、サイトが使えなくなった。そこで、ARM SHA256H* 命令を使った最適化Cカーネルへのネイティブブリッジを持つSafari拡張機能を、約10分でvibe codingで作った。同じデバイスで200MH/s以上を達成できる。これならAnubisの難易度レベル6を数ミリ秒で解ける。
関係する数値と能力を考えると（1台の5000ドルのASICマイナーで200TH/s、これは私の最適化カーネルをiPhoneで動かしたものよりも100万倍高いハッシュレート）、プルーフ・オブ・ワークが、人間のユーザー体験を損なわずにボットを排除する持続可能な戦略になり得るとは思えない。これは勝てない軍拡競争だ。
編集：ぜひ自分で試してみてほしい。以下は、そのタスクを一発でこなすはずのサンプルプロンプトだ：
> ネイティブC ARM64 SHA-256カーネルを使用してAnubisのプルーフ・オブ・ワークを高速化するiOS Safari Web Extensionを構築してください。不変の128バイトのチャレンジプレフィックスを事前計算し、ARM SHA-2 intrinsicsと2つのワーカースレッドで固定幅の10進ノンスを検索し、難易度6の解決を1秒未満でターゲットにしてください。Safariコンテンツスクリプトからチャレンジをリレーし、[...]
- robotmay
ここ数日、自分のウェブサイトの1つにトラップを仕掛けているんだ。皮肉なことにLLMを使ってね。かなり楽しんでやってる。
Anubisのプルーフ・オブ・ワーク方式の代わりに、iocaineルートを選んだんだけど、それをアプリケーション自体に実装した。Elixirで書かれているから、スクレイパーに問題を起こすのが本当に面白いし、サーバーリソースをほとんど消費しない。
今は、悪質なスクレイパーを、おいしいデータを約束する偽の無限ブラックホールパスに誘導して、その後、ヘッダーを素早く送った後、15分かけて画像を1バイトずつ配信したり、レスポンスを膨らませてトークンを消費させたり、ランダムにAI生成のセクシーなトースターの画像を返したりしている。どのスクレイパーが一番詰め込まれたかを示す小さなリーダーボード付きの管理ダッシュボードがあって、この湿った秋の夜には心が温まるよ。
- virgoerns
私も公開cgitインスタンスを運営していて、毎日100万以上のヒットがある。私のペットプロジェクトはカーネルほどの規模や影響力は到底ないのに。diff、blame、snapshot、履歴コミットのcgitエンドポイントを（nginx設定で）ブロックせざるを得なかった。他に方法がなかったからだ。今は402（支払いが必要）を返している。これは完全な敗北だと思っていて、心が痛むが、仕方ない。
- tptacek
Tavis Ormandyが、Anubisについて、ほぼ1年前にこれを予言していた：
https://news.ycombinator.com/item?id=44962529
それは決して解決策としてまとまることはなかった。高性能なスクレイパーは、エンドユーザーよりもプルーフ・オブ・ワークのチャレンジを処理するのに適している。プルーフ・オブ・ワークはパスワードハッシュには理にかなっている。パスワードの推測は、どんな推測でも限界効用がゼロだからだ。しかし、スクレイパーからのリクエストはすべてスクレイパーにとって生産的だ。
- jdnier
この記事の文体がとても気に入った。
そして、「ユーザーエージェントを変更する」から「IPアドレスを変更する」、プロバイダーがサブネット全体やASN全体を禁止せざるを得なくなり、「プロキシSDKの収益化」が存在することに気づくというボットの進化は、LLM以前の時代の脅威アクターの進化を反映している。
- Demiurge
私はかつて人気があったゲームサイトを管理している。以前は1秒間に数百の正当なリクエストがあった。人気イベントの時間帯には特に負荷が高かった。だから、ずっと専用サーバーで運用してきた。
また、「オンラインユーザー」カウンターもあって、認証されていないがセッションを維持しているユーザーの実際のセッションを数えようとしていた。それにより、コメントや特定のフィルターや表示オプションの変更ができる。Googleボットは数えていなかった。
ここ数年で、このカウンターはオンライン100〜200人から数千人に増えた。長年ほとんど手を付けずに、軽微なアップグレードとバックアップだけを行ってきた。しかし、サイトもかなり遅くなり、これらのセッションが明らかに影響していた。そこで、ついにこれらのクローラーを調査したところ、確かに、完全に人工的な狂った量のトラフィックで、サイトにはほんの一握りの実際のユーザーしかおらず、何千人ものクローリングセッションが、できる限りのことをしようと、すべてのボタンをクリックしていることがわかった。ソートと検索がGETリンクで実装されていたのも助けにならなかった。
カウンターをクローラーを除外するように修正したが、少しジレンマがある。ボットがすべてのコンテンツに基づいて知識を更新するのを止めたくない。
私が見つけた最良の解決策は、新しいCloudFlareの機能で、クローラーにリクエストごとに課金するか、そうでなければブロックするというものだ。これはインターネット全体にとって素晴らしいアイデアだと思う。ベータアクセスに申し込んだが、まだ連絡がない。
- mzajc
> なぜgit.kernel.orgはクローラーにとって「興味深い」のか
この投稿は、これらのボットにどれだけ考えや労力が注がれていないかを過小評価していると思う。私もはるかに興味深くないプロジェクトのcgitインスタンスを運営しているが、HTTPリクエストの奔流からは逃れられない。
私が思いつく説明は、彼らはそれがどれだけ理にかなっているか、どれだけ負荷を引き起こすかに関係なく、すべてのリンクをクロールしようとするということだ。cgitはcgitなので、パラメータとハッシュのすべての組み合わせに対して何十億ものリンクがあることを意味する。あるいは、意図的なDDoS攻撃かもしれない。
- Waterluvian
> それはすぐに非常に効果的だった——ボットはただ諦めた。数ヶ月間、それは至福だった：ボットは境界でブロックされ、諦めて、より簡単な標的に移っていった；ユーザーは少しイライラしたが許容し、Anubisスタックはどこにでも簡単にデプロイできた。
技術者として、技術者と働く者として、私はこの種のバイアスに非常に敏感になっている。この解決策は本当に優れているのか？CPUコストは、皆を少しイライラさせることよりも実際に悪いのか、それとも「感覚に反する」から解決されている問題なのか？
私はこの事例に対して賛成か反対かのどちらかに傾いているわけではない。しかし、測定せずに結論に飛びつく人をよく見かける。20%のコストはいくらで、そのコストは「皆を少しイライラさせる」価値があるのか？
- easton
余談：なぜシャロークローンは悪いのか？いつもシャロークローンの方が安いと思っていたが、それはディスクスペースのためだけだろう。（サーバーが「すべて」ではなく、どのblobを渡すかを計算しなければならないから？）
- javcasas
この時点で彼らはレジデンシャルプロキシなどを使っていて、難易度を上げても役に立たない。とりわけ、彼らはそれにお金を払っていないからだ。
なぜこのプルーフ・オブ・ワーク全体を公式の「$SHITCOINのマイニング支援」にできないのか？つまり、彼らが本当にデータを欲しがっているなら、少なくともCPU/GPU/ASICサイクルでホスティングの代金を払わせればいい。