Ein Jahr für WebAssembly in Anubis: Die Reise eines Proof-of-Work-Proxys

Ich habe hier jede Kopie von Firefox mit deaktiviertem Webassembly konfiguriert ... weil ich dazu neige, nicht das zu tun, wofür Webassembly entwickelt wurde, d.h. Online-Spiele, Video-/Audiobearbeitung, Emulation usw. [1] und weil ich es nicht mag, wenn Dinge ohne mein Wissen im Hintergrund laufen.

Das wird also interessant.

Meine Bitte (mit leiser Stimme) an den OP: So wie es viele Websites noch für JavaScript tun, füge bitte eine Nachricht wie "Dieses Captcha erfordert Webassembly, um fortzufahren" in deinen Code ein, wenn Webassembly deaktiviert ist. Und nebenbei auch für kleinere Plattformen/Browser, die überhaupt keine Webassembly-Engine anbieten.

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

> Es bedeutet auch, dass die "Hey Claude, schludere mir einen CUDA-Anubis-Löser zusammen"-Route auf dem Weg ist, grundlegend tot zu sein.

Ich nehme an, dass die vorherigen Herausforderungen für Umstände, in denen WASM nicht verfügbar ist, weiterhin verfügbar sein werden (es sei denn, wir gehen einfach davon aus, dass es verfügbar ist, wenn JS es ist?) oder vielleicht als Fallback. Der Artikel erwähnt ausdrücklich "smarte" Fernseher, und ich bin sicher, dass es dort viele gibt, die Browser ausführen, die alt genug sind, um nicht zu wissen, was WASM ist. Ehrlich gesagt wären diese für mich keine Priorität, aber sie sind es offensichtlich für dieses Projekt, da sie (nun, Fernseher im Allgemeinen, nicht speziell ältere) in diesem Artikel ausdrücklich erwähnt werden.

Wenn das so ist, was hindert Scraper daran, einfach die Fallback-POW-Option zu erzwingen, anstatt zu versuchen, den neuen speicherintensiven Algorithmus überhaupt auszuführen?

Hut ab vor Xe für so viel Zeit für Abwärtskompatibilität, besonders die Kleinigkeit über das Zielen auf Chrome 66.

Ich habe einen Mac von 2014 mit Yosemite, den ich gelegentlich benutze, um die Abwärtskompatibilität in meinem eigenen Frontend-Code zu testen (aus Spaß!). Aber IMO ist der beste Weg, Kompatibilität zu gewährleisten, die Verwendung von zeitgemäßen Toolchains oder Toolchains, bei denen das Tempo der Änderungen langsamer ist, wie ClojureScript.

Gibt es einen Ort, an dem ich ausprobieren kann, ob mein Browser kompatibel ist? Einfacher ist es, es jetzt herauszufinden, als wenn ich versuche, Arbeit zu erledigen und eine Million Websites es jetzt bereitgestellt haben.

Auf https://wasm-feature-detect.surma.technology wird angezeigt, dass mir 3 von all diesen Funktionen fehlen, aber ich bin nicht sicher, ob Anubis eine davon benötigt, um mich nicht zurück zur reinen JS-Lösung zu schicken.

Was offenbar schlecht wäre, denn

> Das WebAssembly, das mit diesem Ablauf geliefert wird, ist lächerlich leistungsfähig. Das kann bedeuten, dass du die Schwierigkeit nach oben anpassen musst [um zu vermeiden, dass Bots es trivial lösen, wenn sie wasm unterstützen, nehme ich an]

kombiniert mit

> Der wasm2js-Ablauf hat derzeit keine Möglichkeit, die Fortschrittsanzeige zu aktualisieren [du hast also keine Ahnung über die verbleibende Zeit]

(wäre nicht das erste Mal, dass ich eine Seite aufgebe, weil sie bei 0 Hashes pro Sekunde festhing)

Du kannst das `wasm32v1-none`-Ziel von Rust verwenden, um Basis-WASM ohne zusätzliche Zielfunktionen zu erhalten. (Das beschränkt dich jedoch auf `#[no_std]`.) https://doc.rust-lang.org/rustc/platform-support/wasm32v1-no...

Es wäre cool, wenn der POW im Voraus erledigt werden könnte. So bleibe ich nicht beim Arbeiten hängen und warte. Eine Art Guthaben/Tokens, das mein Browser dann ausgeben könnte.

> Das bedeutet, dass das Hinzufügen von eins (1) zur Schwierigkeit einer Herausforderung es im schlimmsten Fall 1024 (eintausendvierundzwanzig) Mal so schwer zu lösen macht.

Ich verstehe die Einheiten hier nicht, würde nicht ein Bit- gegenüber einem Nibble-Unterschied den Multiplikator 16 statt 1024 ergeben?