Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Anubis is fine if you want to block bots that are bothering you, but I never understood why they don't have robots.txt at the root level too. I happily obey that for my private crawler. I suppose you don't want to duplicate implementations. Fair enough. I guess I should add an Anubis detector so I can just blacklist because that person clearly doesn't want bots.
    by arjie
  • One of the standard library rules enables robots.txt passthrough by default. I can't control people not choosing to use it.
    by xena
  • In this day and age, only good bots, the ones you actually want, obey robots.txt. You obtain no benefit by having a restrictive one.
    by mitxela
  • thanks for trying to make the web suck a little less these days xena!
    by tefkah
  • > It also means that the "hey Claude vibeslop me a CUDA Anubis solver" route is on its way to being fundamentally dead.

    I assume that the previous challenges will still be available for circumstances where WASM is not available (unless we are just working on the basis that it is available if JS is?) or perhaps as a fallback. TFA explicitly mentions “smart” TVs, and I'm sure there are plenty of those out there that run browsers old enough to not know what WASM is. TBH these would not be a priority for me, but they obviously are for this project given they (well, TVs generally, not specifically elderly ones) get specific mention in this write-up.

    If so, what is to stop scrapers from just forcing the fallback POW option instead of trying to run the new memory-hard algorithm at all?

    by dspillett
  • the answer to this is in the post: where wasm is not available, he transpiles the wasm binary back to Javascript
    by Lyrex
  • The interesting part is that bots mitigation is actually an economic problem. You don't need to make scraping impossible, you only need to just make it expensive enough so that abusive traffic stops being worth it.
    by miraline
  • It's already expensive, though they still profit. Let's see if this makes it more expensive, since RAM/storage is much harder to come by these days.
    by worldsavior
  • Scrapers scrape all sorts of nonsense, notably every possible git diff from git hosts. They clearly aren't concerned with rationality.
    by mitxela
  • > This means that adding one (1) to the difficulty of a challenge makes it 1024 (one thousand twenty-four) times as hard to solve in the worst case.

    I don't understand the units here, wouldn't a bit versus nibble difference make the multiplier 16, instead of 1024?

    by omoikane
  • Oops, there's your proof I didn't write this with AI! Fixing, sorry.
    by xena
  • It would be cool if the POW could be done ahead of time. That way I don't get stuck waiting while I'm working. Some type of credit/tokens that my browser could then spend.
    by 0x696C6961
  • Then we could implement an exchange, so that if you generate too much Anubis POW, you could exchange it with others.

    We could link it to a site, you generate for HN, I for Reddit, but it so happens that you visited Reddit more and I HN, so we depleted our Anubis POW, so we could exchange some Reddit Anubis with some HN Anubis.

    by dist-epoch
  • I wonder if you could convince the Anubis author to implement x402 payments to bypass the PoW
    by packetlost
  • Privacy Pass does something similar to what you describe: https://developers.cloudflare.com/waf/tools/privacy-pass/
    by tomodachi94
  • Or something that shadier websites could calculate ahead of time in your browser, then spend on your behalf.

    I feel like Anubis is ironically speedrunning a lot of discoveries the crypto folks have already made several years ago...

    by lxgr
  • I'm working on this with a private prototype. I'm probably going to lean towards using a Service Worker (https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...) to renew challenges at a reduced difficulty. Stay tuned!
    by xena
  • > something I was doing with my "strict MVP" build of Anubis' WASM wasn't in fact sticking to just the MVP features of WebAssembly

    Fun fact, this _used_ to be the case - wasm32-unknown-unknown had extra non-mvp features added later, which in my eyes has been a breaking change on stable. You're not the first person to have been bitten by this, there's [1] and a similar story in Ruffle [2].

    Weirdly, the response from the rustc side (IIRC we also talked with one of the devs of wasm component on discord a bit around 2024) has contained a lot of (paraphrasing) "in retrospect we think wasm32-unknown-unknown target was designed badly*, so we'd prefer if you either dealt with it or switched to another wasm target <with its different set of downsides> than us fixing it". (*I acknowledge that the way std was implemented on that target was unusual and "not clean", but it works _really well_ for a lot of people.)

    > I looked into the process involved for rebuilding the standard library twice: once with only MVP wasm features enabled and once with an "all yes config" like usual. Based on some research I did this seemed like a massive pain.

    That's what Ruffle does [3], it's a bit unfortunate but wouldn't call it a massive pain.

    [1] https://internals.rust-lang.org/t/can-we-have-either-a-new-t...

    [2] https://github.com/ruffle-rs/ruffle/pull/18397

    [3] See lines 55 and 117-127 in https://github.com/ruffle-rs/ruffle/blob/6890c618daab3153343...

    by adrian17
  • > Weirdly, the response from the rustc side (IIRC we also talked with one of the devs of wasm component on discord a bit) has contained a lot of (paraphrasing) "in retrospect we think wasm32-unknown-unknown target was designed badly, so we'd prefer if you either dealt with it or switched to another wasm target <with its different set of downsides> than us fixing it". (I acknowledge that the way std was implemented on that target was unusual and "not clean", but it works _really well_ for a lot of people.)

    That's about right. Specifically, wasm32-unknown-unknown is serving multiple targets, which aren't very compatible, and it implements std by panicking in all the bits that can't work.

    One target is "you truly have absolutely nothing, and don't really have much of `std` at all". Another target is "you're in a browser, and can do anything a typical browser can provide" (ideally targeting the future where wasm has full browser APIs without going through javascript). Another target is "hosted environment that isn't a browser, and which capabilities you have depends on the environment". Those are three very different things.

    I would argue that we need at least two new targets, possibly three:

    - `wasm32-none` or similar (by analogy with `x86_64-unknown-none`), a target where you don't have anything except for what you bring with you. The equivalent of writing kernel code.

    - `wasm32-wasi-hosted` (or pick another name), where you the hoster of the wasm can supply whatever capabilities you have available.

    - `wasm32-wasi-browser`.

    It's possible that `none` could be a special case of `hosted`, where the services you provide are "none".

    by JoshTriplett
  • You can use Rust's `wasm32v1-none` target to get baseline WASM with no extra target features. (This restricts you to `#[no_std]`, however.) https://doc.rust-lang.org/rustc/platform-support/wasm32v1-no...
    by Georgelemental
  • Is there a place where I can try out if my browser is compatible? Easier to find out now than when I'm trying to get work done and a million websites now have it deployed

    On https://wasm-feature-detect.surma.technology it shows that I don't have 3 of all these features but I'm not sure if Anubis needs any of them to not kick me back to the pure JS solution

    Which would apparently be bad because

    > The WebAssembly that's shipped with this flow is ridiculously performant. This may mean you need to adjust the difficulty [upward, to avoid that bots solve it trivially when they support wasm, I assume this means]

    combined with

    > The wasm2js flow doesn't currently have a way to update the progress bar [so you have no clue about remaining time]

    (wouldn't be the first time that I gave up on a page because it was stuck on 0 hashes per second)

    by Aachen
  • If you don't disable browser features for fun and/or sport, Chrome as of version 120 or later (or another browser of that vintage) will use the optimized flow.
    by xena
  • Hats off to Xe for spending so much time on backwards compatibility, especially the tidbit about targeting Chrome 66.

    I have a Mac from 2014 running Yosemite that I occasionally use to test for backwards compatibility in my own frontend code (for fun!). But IMO the best way to ensure compatibility is to use period-correct toolchains or toolchains where the pace of change is slower, like ClojureScript.

    by kccqzy
  • Just use Momiji, unless you care about Chrome so much. In that case, Chromium Legacy might work.
    by yunaflox
  • In the non-webdev realm, it's gobsmacking that you can put "FROM debian/eol:buzz" in a Dockerfile, and it will do what it says...
    by nxobject
  • I have every copy of Firefox here configured with webassembly disabled...because I don't tend to do what Webassembly was designed for, i.e. online games, video/audio editing, emulation, etc. [1] and because I dislike things running in the background without my knowledge.

    So this is going to be interesting.

    My plea (in a small voice) to the OP: just as many sites still do for JavaScript, please add a "This captcha required Webassembly to continue" message to your code when Webassembly is disabled. And, incidentally, for smaller platforms/browsers that don't offer a Webassembly engine at all.

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

    by doctor_radium
  • "I disable things and expect others to do things for me, in their own time, without being paid, to bring solutions to my paranoia"

    You do see how selfish it is, right? While the author did introduce such a solution, it's such a massive waste of time.

    by well_ackshually
  • I really don't see why you'd disable WebAssembly and allow JavaScript instead. Expecting developers to make a fallback for a baseline-supported feature for any reason but backwards compatibility with runtimes that do not so support WASM is extremely silly.
    by jonkoops
  • Isn't the WASM attack surface absolute minuscule when compared to JS? Do you also disable web workers?
    by tiagod
  • I don't mean to be rude, but please search "wasm2js" in the article.
    by xena