世界を動かす技術を、日本語で。

「Anubis」におけるWebAssemblyの出荷に1年を要した

概要

Anubis はサーバー保護のために導入されたシステム。 Proof-of-Work方式で AIによる大量スクレイピング を抑止。 一般ユーザーには影響が少なく、 大量アクセスのみ負荷増大。 将来的には 指紋認証技術 へ移行予定。 一部プラグイン(例: JShelter)は無効化が必要。

Anubisによるサーバー保護の仕組み

  • Anubis はウェブサーバーをAIスクレイピングから守るためのミドルウェア
  • Proof-of-Work(PoW) 方式を採用し、アクセスごとに計算負荷を課す
  • 個人ユーザーの通常利用では 負荷がほとんど発生しない 設計
  • 大量アクセス(スクレイピング) 時のみ、計算コストが累積し、実質的な抑止効果
  • Hashcash に着想を得たPoW方式の応用

今後の対策方針とユーザーへの影響

  • Anubisは 一時的な措置 として導入
  • 今後は ヘッドレスブラウザの指紋認証 技術の導入を計画
    • 例: フォントレンダリングの挙動 で識別
  • 指紋認証が実装されれば、 正規ユーザーへのPoW課題表示は不要
  • JShelter などの一部プラグインは、Anubisの動作に必要な モダンJavaScript機能を制限
    • 該当プラグインは 無効化が推奨される

サイト管理者・ユーザーへのメッセージ

  • Anubis は全ユーザーの利便性を守るための 妥協的な防御策
  • サイトの ダウンタイムやリソース不可用 を防止
  • AI企業による過剰なデータ収集 への対抗手段
  • ユーザーは 一時的な手間 を理解し、協力が求められる

Hackerたちの意見

POWを事前に終わらせられたらいいな。そうすれば、作業中に待たされることもないし。ブラウザで使えるクレジットやトークンみたいなのがあれば最高だね。

今、プライベートなプロトタイプでこれに取り組んでるよ。多分、サービスワーカーを使って(https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...)難易度を下げてチャレンジを更新する方向に進むと思う。お楽しみに!

Anubisの作者を説得して、PoWをバイパスするためにx402ペイメントを実装してもらえないかな。

そしたら、交換機能を実装できるね。もしAnubisのPOWを生成しすぎたら、他の人と交換できるように。サイトにリンクさせて、あなたがHN用に生成して、私がReddit用に生成するけど、たまたまあなたはRedditを多く訪れて、私はHNを多く訪れたから、AnubisのPOWが尽きちゃった。だから、RedditのAnubisをHNのAnubisと交換できるってわけ。

それか、もっと怪しいサイトがブラウザで事前に計算して、あなたの代わりに使えるようにするみたいな。Anubisは皮肉なことに、クリプトの人たちが数年前にすでに発見したことをスピードランしてる気がする…

プライバシーパスは、君が言ってることに似たことをやってるよ: https://developers.cloudflare.com/waf/tools/privacy-pass/

私の経験上、この正確な状況を持つ人たちは、オープンソースプログラムの作者に対して示す親切さのレベルに幅がある傾向がある。これ、好きだな。HNではOSSのメンテナーがどう扱われているかについて過去に議論があったし、これは本当に皮肉な一文だね。この問題に対するトーンや態度に感謝してる。

自分のブラウザが互換性があるか試せる場所ってある?作業中に確認するより、今のうちに知っておいた方が楽だし、今は何百万ものウェブサイトがこれを導入してるから。https://wasm-feature-detect.surma.technology では、これらの機能のうち3つがないって表示されてるけど、Anubisがそれらの機能を必要とするかどうかは分からない。もし必要なら、純粋なJSソリューションに戻されるのはまずいみたいだから。> このフローで提供されるWebAssemblyは、驚くほどパフォーマンスがいいから、難易度を上げる必要があるかもね(ボットが簡単に解決しないようにするために)。> wasm2jsフローは現在、進捗バーを更新する方法がないから、残り時間が全く分からないし(毎秒0ハッシュのままページを諦めたのは初めてじゃない)。

Xeが後方互換性にこんなに時間をかけてくれてるのには脱帽だね。特にChrome 66をターゲットにしてるっていうのが面白い。2014年のMacでYosemiteを使ってるけど、たまに自分のフロントエンドコードの後方互換性をテストするために使ってるよ(楽しみで!)。でも、個人的には互換性を確保する最良の方法は、時代に合ったツールチェーンや、変化のペースが遅いツールチェーン(ClojureScriptみたいな)を使うことだと思う。

ウェブ開発以外の世界では、「FROM debian/eol:buzz」をDockerfileに書くだけで、ちゃんと動くなんて驚きだよね。

これは、チャレンジの難易度に1を加えると、最悪の場合に1024倍(千二十四倍)難しくなることを意味します。ここでの単位がよくわからないんだけど、ビットとニブルの違いで乗数が16になるんじゃないの?

おっと、これがAIで書いてない証拠だね!修正するよ、ごめん。

Hacker Newsで議論の続きを見る