001 — Mythic、公開へ

今日、ラボ初のプロジェクトがリポジトリから記録へ移る： Mythic —— キャプチャが負ける時代のためのキャプチャ代替として構築された適応型ボット対策。本日よりAGPL-3.0で完全公開。

キャプチャは死んだ、その死は測定可能だ

ソルビングファームは昼食より安い値段で千件の回答を売る。視覚モデルは画像パズルをテキストのように読む。ステルスブラウザは、捕まえるはずだったフィンガープリント検査を平然とすり抜ける。静的なパズルはどれも同じ失敗モードを共有する： ソルバーが一度発見されれば、それは永遠に殺される。 経済学はあらゆる局面で攻撃者に味方する —— だから私たちは、より良いパズルを作るのをやめ、悪用に価格を付け始めた。

テーゼ：クライアントを決して信頼しない

Mythicはブラウザをデフォルトで敵対的と仮定する。クライアントから届くすべてのバイトは敵対的入力 —— だからクライアントSDKは センサーであって、決して裁判官ではない。判断はサーバー側で行われ、名前付きで監査可能な理由を出力する決定論的リスクエンジンが担う。

悪用の価格設定は階層的だ：適応型プルーフオブワークは人間にはWeb Worker 内で約1秒 —— ボットファームには同じコストがリクエストごとに永遠にかかる。リスクの高いトラフィックにはより難しいチャレンジを。重要な操作には暗号学的証明を要求できる。判定は短命のEd25519署名トークンとして届き、オリジンがJWKSエンドポイントの公開鍵でローカル検証する —— コールバック不要。

図1 —— 1秒は人間にとっては無に等しく、100万リクエストを回すファームにとってはすべてだ。

判定はトークン、コールバックではない

サーバーが判断すると、リスクスコア・難易度・有効期限をEd25519で署名する。オリジンはJWKSエンドポイントから取得した公開鍵でローカル検証する。mythicdへのリクエストごとのコールバックも、漏洩する共有シークレットもない：

claims, err := xtoken.VerifyToken(pub, token)
if err != nil {
    // reject: malformed, bad signature, or expired
}
// claims.Decision and claims.Risk are yours to enforce;
// verification only proves mythicd signed these claims.

HTTPサーフェスは2つのエンドポイントだけ。チャレンジを入れて、証明を出す：

$ curl -s mythicd:8080/v1/challenge \
    -d '{"site_key":"sk_live_..."}'
# → {"id":"ch_01J…","difficulty":18,…}

# solve the SHA-256 PoW, then:
$ curl -s mythicd:8080/v1/verify \
    -d '{"challenge_id":"ch_01J…","nonce":"48291033"}'
# → decision token (or a harder challenge)

まず自分たちで壊そうとした

公開前に、私たちは自分たちで攻撃を実行した。トークン形式への1万変異のストームは、実際の受容バグを捉えた：異なる文字列が同じ署名済みバイトにデコードされる。ライブのカオスセッションでは、偽造ヘッダー1つでIPごとのレートリミッターを20回中20回突破できることが分かった。両方修正済み。両方とも回帰テストで固定済み。今やファザーが毎回のプッシュでCI上の検証パスを磨き続ける。バイパス報告こそ最も有用な部分だった —— それが、このプロジェクトに報いてほしい文化だ。

正直、まだできないこと

v0は、ステルスブラウザとネイティブソルバーを持つ資金力のある運用者には負ける。脅威モデルに文章で書いてある。答えはロードマップであって雰囲気ではない：行動バイオメトリクス、暗号学的ステップアップ、学習エンジン。デフォルトで公開とは、穴も公開ということだ。

ライセンス

すべて —— エンジンもSDKも —— AGPL-3.0-or-later。読んで、クローンして、壊してほしい。壊せたら、まず非公開で教えてほしい。コントリビューションはリポジトリ内のCLAのもとで歓迎する。

プロジェクト001は稼働中。プロジェクト002はすでに待機中。