ついに実現！WebAssemblyをAnubisに実装するまでの1年間の奮闘記

AnubisにWebAssemblyを組み込むために費やした、丸1年におよぶ開発の舞台裏を振り返ります。

POWをあらかじめ完了しておける仕組みがあれば最高だね。そうすれば作業中に待ちぼうけを食らわなくて済む。ブラウザが後で消費できるようなクレジットかトークンみたいなものがあればいいんだけど。

Anubisが長期、あるいは中期的にどう機能していくのか、いまいちよく分からない。スクレイパー、つまりAI企業というか、メモリを食い尽くす連中がメモリ不足に悩んでいるという前提なのかな……？

経験上、まさにこういった状況を抱え込んでいる連中に限って、自分の邪魔をするオープンソースプログラムの作者に対して、驚くほど態度が冷淡だったりするんだよね。

これ最高。HNでもOSSのメンテナがどう扱われているか以前議論になったけど、この皮肉の効いた一文はすごくいいね。この問題に対する姿勢やトーンがすごく気に入ったよ。

ブラウザが対応しているか確認できる場所ってある？ いざ作業中にWebサイトで実装されてて動かないより、今のうちに確認しておきたい。

https://wasm-feature-detect.surma.technology を見ると、自分の環境だと3つほど機能が足りてないみたいなんだけど、Anubisが純粋なJS版にフォールバックしないためには、それらの機能が必要なのかどうかが分からない。

それだと以下のような理由で困るんだけどさ。

このフローで使われるWebAssemblyは劇的に高性能だ。つまり、ボットがwasmをサポートしている場合に備えて、難易度を上げる必要があるかもしれない（[ボットが簡単に解いてしまわないように]という意図だよね）

これと、

wasm2jsのフローでは、現時点ではプログレスバーを更新する方法がない（だから残り時間が全く分からない）

っていうのが合わさると……（0ハッシュ/秒のままフリーズしてブラウザを閉じるのはもうコリゴリだよ）

Xena、Webを少しでもマシな場所にしようと努力してくれてありがとう！

Xeに脱帽だよ。特にChrome 66をターゲットにするような後方互換性へのこだわりはすごいね。

自分も趣味でフロントエンドコードの後方互換性をテストするために、たまに2014年製のYosemiteを積んだMacを使ってるんだけど、互換性を確保する最良の方法は、ClojureScriptみたいに進化のペースが緩やかなものや、その時代に合わせたツールチェーンを使うことだと思うな。

つまり、チャレンジの難易度に1を足すと、最悪の場合、解くのが1024倍難しくなる。

この単位がよく分からないんだけど、ビットとニブルの差なら倍率は16倍にならないの？ 1024になる理由が分からない。

面白いのは、ボット対策は実は経済的な問題だってことだね。スクレイピングを不可能にする必要なんてない。悪質なトラフィックをやる価値がないと思わせるほどコストをかければいいだけだ。

結局のところ、スクレイピングにかかる限界費用を引き上げて、採算が合わないようにするっていうのが狙いなんだろうね。

素晴らしい記事だね。WebAssemblyは用途がハマれば最高のテクノロジーだよ。

自分もプラグイン用にWASM 1.0の実装（x86とx86_64向けのシンプルなJIT）を作ったところで、C言語以外の言語（バイナリを小さくするために「micro-libc」を使ってる）をどうサポートしようか考えていたんだ。特にC++やRustの情報は記事にあって助かる。C++はEmscripten丸ごと使う必要がありそうで少し面倒そうだけど……スタンドアローンのC++ stdlibのコンパイルも試してみたけど、まだうまくいっていないんだよね。

ところで、スクリーンショットでFirefoxもテストしているのを見たけど、Linuxディストリビューションでよく使われている最新のESR版2つもテスト対象にするといいかもしれないね。