Live data from Hacker News

It took a year to ship WebAssembly in Anubis

anubis.techaro.lol

121–130 of 221 posts

Re: It took a year to ship WebAssembly in Anubis

#121
post #115

Tangential but all the pages I see protected by Anubis are just static HTML. But bot traffic is only harmful on dynamic pages right?

The anubis docs website is used as an example of how anubis works.

Also, if you are not using a big CDN (e.g. Cloudflare), you still need to pay for the traffic (even if you don't pay as much for the CPU). This is doubly true for smaller CDNs like Bunny.

Re: It took a year to ship WebAssembly in Anubis

#122
post #115

Tangential but all the pages I see protected by Anubis are just static HTML. But bot traffic is only harmful on dynamic pages right?

The anubis docs website is used as an example of how anubis works. Also, if you are not using a big CDN (e.g. Cloudflare), you still need to pay for the traffic (even if you don't pay as much for the CPU). This is doubly true for smaller CDNs like Bunny.

Not only is it an example, it specifically is one of the first things I use to test experimental features so I get data back instantly.

Re: It took a year to ship WebAssembly in Anubis

#123
post #115

Tangential but all the pages I see protected by Anubis are just static HTML. But bot traffic is only harmful on dynamic pages right?

I'm not a fan of Anubis for various reasons but the idea that bot traffic in only harmful with dynamic pages must die. CPU (yes, even to serve static pages) is not free, bandwidth is definitely not free. There's an idea that serving a static page to a bot has a marginal cost tending to zero, but it's never really zero and serving them by millions definitely has a cost.

Also, while some pages may look like static HTML pages, they may be generated on the fly by an expensive and/or slow backend, which adds to the cost. I happen to maintain servers for academics and some content management systems are slow and have an expensive CPU cost. While it's OK for the low number of humans interested in the subjects they deal with, it's definitely not fit for massive bot scrapping. And before you ask, no, it's not always practical to have cache upfront or to pre-generate all pages.

Re: It took a year to ship WebAssembly in Anubis

#124

Earlier quoted context omitted.

Ah I must have skipped by that bit. And presumably the memory-hard algorithm is CPU-easy enough that this won't be a problem. That leaves me wondering "why not just use a JS memory-hard routine in the first place, but maybe I've shouted over that too. I'll give TFA a reread later.

I think it is still compute-heavy if not compute-hard, and stuff like WASM SIMD makes it less compute heavy (not really available in JS). And also, for memory bound problems, you probably don't want the JS GC needing to clean up afterwards when WASM gives you that control.

I assume that SIMD acceleration is usable with WebCrypto, but I have no evidence either way. It's also not part of WebAssembly so there's that to consider too lol

Re: It took a year to ship WebAssembly in Anubis

#126
post #125

How much data does it download off the server to run the challenge? I've made some tiny webassembly binaries before, but I've never seen Rust generate something tiny.

It's in the range of 32-40Ki before compression. After compression it gets to be completely negligible.

Re: It took a year to ship WebAssembly in Anubis

#127
post #115

Tangential but all the pages I see protected by Anubis are just static HTML. But bot traffic is only harmful on dynamic pages right?

Shitty scrapers hitting images over and over again is also a problem. Not just /pic/1.webp - /pic/2.webp, but in practice I've seen three AI scrapers that would request things like /pic/1.webp?version=webp&foo=bar and other random query parameters that none of my domains even use. It's just stuck brute-forcing files or something, sucking up loads of bandwidth downloading the same image for no reason.

It also depends on if you want your content to be scraped. Any bot ignoring robots.txt should be considered potentially malicious and worth considering such mechanisms for.

Re: It took a year to ship WebAssembly in Anubis

#128
post #84

Earlier quoted context omitted.

The assumption is that there will always be some population distribution in terms of effort expended as well as in terms of problems caused. At present it's the lowest effort actors that are causing the highest number of problems. So an 80% (or even just a 20%) solution largely solves the practical problem faced by site operators. If against all odds it turns out that skiddies (or agents or AI billionaires or what ha…

Okay but it's like no RAM at all. Thats the problem: you've got stupid bots causing a bunch of issues - these can be stopped. And then regular users: who now can't really browse your site. And then smart bots - anyone with even a moderate amount of funding in the AI space, who aren't even slightly slowed down. The solution basically makes the favored customer well funded AI scrapers, not users.

Regular users store the cookie and do the challenge once. Bots do it over and over again throwing out the cookies so they're not rate-limited.

Extreme configurations with high difficulty do make for a frustrating experience on very old devices, but in practice it rarely gets in the way.

Only the tail end of what one could consider normal users (those running custom browsers or having JS disabled or nonfunctional) run into issues here, but they'll have these issues with any other bot-blocking mechanism that still offers some protection these days.

Apple's "ask your vendor for tokens to exchange for access" web standard gets around this, assuming those bespoke and Javascript-less browsers implement PATs, but that standard seems to be completely dead in the water outside of Safari.

Re: It took a year to ship WebAssembly in Anubis

#129
post #111

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 req…

The second half of this post chronicles the author's Herculean efforts to make everything work well in the cases you describe. > One of the big things that blocked this shipping for so long was not having an escape hatch of some kind to allow clients that disable WebAssembly by policy to get through the gate. [...] This combination of factors means that there would need to be another implementation of the proof of wo…

Thanks. You're right; it was a very thorough article and I trailed off about halfway through. I still say there are many improper uses of Webassembly out there, but I credit the developer for a highly thoughtful approach to the project. I really wonder if Cloudflare et al. does as much due diligence?

Re: It took a year to ship WebAssembly in Anubis

#130
post #28

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.

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...

What if the work output was bound to a particular source IP? That'd stop most "theft" at the expense of discards when your device switches networks.
Post reply on HN