Anubis tardó un año en integrar WebAssembly

Tengo todas las copias de Firefox aquí configuradas con webassembly deshabilitado... porque no suelo hacer lo que WebAssembly fue diseñado para hacer, es decir, juegos en línea, edición de video/audio, emulación, etc. [1] y porque me disgusta que las cosas se ejecuten en segundo plano sin mi conocimiento.

Así que esto va a ser interesante.

Mi súplica (en voz baja) al autor: al igual que muchos sitios todavía hacen con JavaScript, por favor añade un mensaje "Este captcha requiere Webassembly para continuar" a tu código cuando Webassembly esté deshabilitado. Y, incidentalmente, para plataformas/navegadores más pequeños que no ofrecen un motor Webassembly en absoluto.

[1] https://webassembly.org/docs/use-cases/

> También significa que la ruta "oye Claude, vibeslopme un solucionador de Anubis en CUDA" está en camino de morir fundamentalmente.

Supongo que los desafíos anteriores seguirán estando disponibles para circunstancias donde WASM no esté disponible (a menos que estemos trabajando sobre la base de que está disponible si JS lo está) o quizás como respaldo. El artículo menciona explícitamente las "smart" TVs, y estoy seguro de que hay muchas de esas por ahí que ejecutan navegadores lo suficientemente antiguos como para no saber qué es WASM. Para ser honesto, estos no serían una prioridad para mí, pero obviamente lo son para este proyecto dado que (bueno, las TVs en general, no específicamente las antiguas) reciben mención específica en este escrito.

Si es así, ¿qué impide que los scrapers simplemente fuercen la opción de respaldo de PoW en lugar de intentar ejecutar el nuevo algoritmo de memoria intensiva en absoluto?

Felicitaciones a Xe por dedicar tanto tiempo a la compatibilidad hacia atrás, especialmente el detalle sobre apuntar a Chrome 66.

Tengo un Mac de 2014 ejecutando Yosemite que ocasionalmente uso para probar la compatibilidad hacia atrás en mi propio código frontend (¡por diversión!). Pero en mi opinión, la mejor manera de asegurar la compatibilidad es usar toolchains de la época o toolchains donde el ritmo de cambio sea más lento, como ClojureScript.

¿Hay algún lugar donde pueda probar si mi navegador es compatible? Es más fácil averiguarlo ahora que cuando estoy tratando de hacer un trabajo y un millón de sitios web ya lo tienen desplegado.

En https://wasm-feature-detect.surma.technology muestra que no tengo 3 de todas estas características, pero no estoy seguro de si Anubis necesita alguna de ellas para no devolverme a la solución de JS puro.

Lo cual aparentemente sería malo porque

> El WebAssembly que se envía con este flujo es ridículamente eficiente. Esto puede significar que necesites ajustar la dificultad [hacia arriba, para evitar que los bots lo resuelvan trivialmente cuando soporten wasm, supongo que esto significa]

combinado con

> El flujo wasm2js actualmente no tiene una forma de actualizar la barra de progreso [así que no tienes idea del tiempo restante]

(no sería la primera vez que abandono una página porque estaba atascada en 0 hashes por segundo)

Puedes usar el objetivo `wasm32v1-none` de Rust para obtener WASM de línea base sin características objetivo adicionales. (Sin embargo, esto te restringe a `#[no_std]`.) https://doc.rust-lang.org/rustc/platform-support/wasm32v1-no...

Sería genial si el PoW pudiera hacerse con anticipación. Así no me quedo atascado esperando mientras estoy trabajando. Algún tipo de crédito/tokens que mi navegador pudiera gastar luego.

> Esto significa que añadir uno (1) a la dificultad de un desafío lo hace 1024 (mil veinticuatro) veces más difícil de resolver en el peor de los casos.

No entiendo las unidades aquí, ¿no haría la diferencia entre un bit y un nibble el multiplicador 16, en lugar de 1024?