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

私は、binfmt_misc経由でbpfを介してインタプリタ（PT_INTERP）の$ORIGINをサポートするためのLinuxカーネルへのパッチに取り組んでいます[スレッド]。もちろん、これを支援するためにLLMを活用しています！LLMのコンテキストを事前設定するために、私はhttps://lore.kernel.org/のスレッドを読むように指示しました。まずい。彼らがAnubisを採用したようです。これは、リソースへのアクセスを許可する前にプルーフ・オブ・ワークを必要とするHTTPプロキシです。これは本当に何かをしましたか？残念ながら、いいえ。私のAIは熱心にanubis-fetchを考案しました。これはhttps://github.com/fzakaria/anubis-fetchで見つけることができます。このツールは、ネイティブにプルーフ・オブ・ワークを解決しようとします。最後の手段として、Chromiumを起動してURLにアクセスします。このツールは、reqを介してネイティブに実際のChrome TLS/JA3フィンガープリントを偽装するため、パッシブなCloudflareブロッキングもクリアします。 ☝️ HTMLを標準出力に $ anubis-fetch https://lore.kernel.org/linux-mm/some-thread/T/ 読みやすいプレーンテキストとして $ anubis-fetch --text https://lore.kernel.org/linux-mm/some-thread/T/ では、誰を止めたのでしょうか？Anubisがターゲットとする正確な敵対者は、それを簡単に打ち負かします。Anubisの使用全体は退行的であり、「優れた」AIへのアクセスを持たない人々を疎外します。スクレイパーにとって、Anubisチャレンジを解決することは、クッキーをキャッシュして再利用できるため、一度きりの、ゼロに償却されるコストです。人間にとっては、すべての新しい訪問ごとに数秒のスピナー、バッテリー消費です。彼らは互いの間で何も償却できません。この「退行的税」は、特に弱いデバイスを持っている人々や、携帯電話でコンテンツにアクセスする人々によってさらに支払われます。JavaScriptを利用しないクライアント（例: テキストブラウザ（w3m/lynx）、スクリーンリーダー、RSSリーダー）は完全に除外されます。 Anubisの展開は、前述のボットファームのいずれかを停止しましたか、それとも新しいプルーフ・オブ・ワークソリューションを一時的にサポートするようにボットを拡張する必要があったときに、わずかに不便になっただけですか？皮肉なことに、Anubisの目標はAIを止めることですが、AIがそれを回避するのは非常に簡単でした。それにもかかわらず、人間とオープンウェブへのコストは残ります。 Anubisが退行的税であると仮定すると、それは私たちにいくらかかりますか？ここでのすべての数字は概算です。これは環境的な議論ではまったくありません。なぜなら、ボットファーマーやAIツール自体が桁違いに多くのエネルギーを使用しているからです。それにもかかわらず、人々を疎外するプルーフ・オブ・ワークチャレンジに費やされる時間の量を見るのは興味深いです。 難易度 d は、ハッシュが持つ必要がある先頭のゼロの16進文字の数です。したがって、解決あたりの期待される作業量は W = 16^d ハッシュです。 難易度 解決あたりのハッシュ数 ネイティブ（Go） ブラウザJS 体感壁時計時間 4 65,536 ~1.3 ms ~130 ms ~1–5 s 5 1,048,576 ~20 ms ~2 s ~5–15 s 難易度4は一般的なデフォルトです。レートの想定: ネイティブ（Go）で約50 MH/s、ブラウザJSで約0.5 MH/s。「体感」壁時計時間には、ページロード、ワーカー、リロードが含まれます。 1日あたりのAnubisチャレンジ解決数 C を世界中で仮定します。解決あたり t = 2 s の体感時間と、デバイスエネルギー E = 20 J（画面+CPU）を仮定します。 C（解決/日） 年間人間時間 年間エネルギー（kWh） 1 M ~23 人年 ~2 MWh 10 M ~230 人年 ~20 MWh 100 M ~2,300 人年 ~200 MWh 集合的に、私たちはウェブサイトへのアクセスを待つためにかなりの量の時間を無駄にしています。AI時代以前には費やさなかった時間です。人間にとって、時間は私にとって貴重で有限ですが、ロボットにとってはそうではありません。