[dead]
It took a year to ship WebAssembly in Anubis
201–210 of 225 posts
Re: It took a year to ship WebAssembly in Anubis
#202I 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…
Isn't the WASM attack surface absolute minuscule when compared to JS? Do you also disable web workers?
I disable workers.
I forgot to do so on my phone. I noticed Firefox had slowed to a friggeb crawl when opening pages. Disabling web workers fixed that.
Re: It took a year to ship WebAssembly in Anubis
#203Earlier quoted context omitted.
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…
> Also, while some pages may look like static HTML pages, they may be generated on the fly by an expensive and/or slow backend Yes and that should be fixed before you subject real users to resource-wasting scripts.
Sadly, I do not control resource-wasting scripts running crawlers.
And to answer your intended demand: this is in some cases impossible or unreasonable. And things were working fine before LLM DDoS.
Re: It took a year to ship WebAssembly in Anubis
#204Earlier quoted context omitted.
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…
> 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 That's a trivially solved problem - have the web server refuse (or redirect if you're feeling nice) requests with unexpected query parame…
Sure, there are loads of easy solutions to this problem. Putting everything behind Cloudflare is the most common one, Anubis and its competitors are another. I could also block all data centers, countries with loads of CGNAT + botnets like Brazil, China, and probably India, and refuse any user agent not in the top 5 modern user agents with a little TLS fingerprinting to make sure.
I could probably also analyze all the paths across my servers and write some bespoke Nginx config files to filter out all requests with illegal queries, but that's harder, more fragile, and just leaves the servers open for the next time a scraper finds a new way to screw me over.
The bots I'm fighting have gone for the nuclear option, relying on botnets and spoofing to bypass basic filtering, so I don't see why I shouldn't do the same.
Re: It took a year to ship WebAssembly in Anubis
#205Earlier quoted context omitted.
Gotta agree. Turning tracking cookies off? Sure! Turning session cookies off and then complaining that the server doesn’t remember you? Uhhh… And while I’m sympathetic to the idea of not wanting to run JS, to a first approximation modern browsers are JS engines that have graphical displays. How things should be vs how they are is a classic is/ought problem. The world took a vote on what a browser’s meant for and we l…
There's no mechanistic difference between the two types of cookies, let's not pretend this is an actual config choice that people are making. Whenever I hit Anubis, I simply go "keep your secrets then" and take my leave. The vast majority of the sites posted to HN (that catch my fancy) work fine or fine enough, and are better for it. If I really, really desperately want to check something out, I can always just turn…
The Anubis anime girl is an instant tab close for me, especially while in public. I dont like having to explain to people that I'm not one of those creepy anime guys.
Re: It took a year to ship WebAssembly in Anubis
#206Earlier quoted context omitted.
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…
> Also, while some pages may look like static HTML pages, they may be generated on the fly by an expensive and/or slow backend Yes and that should be fixed before you subject real users to resource-wasting scripts.
Please submit a fix to cgit then.
Re: It took a year to ship WebAssembly in Anubis
#207Earlier quoted context omitted.
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.
Anubis does this. Happy Eyeballs ( https://en.wikipedia.org/wiki/Happy_Eyeballs ), IPv6 privacy extensions ( https://oneuptime.com/blog/post/2026-01-15-ipv6-privacy-exte... ), and devices migrating between home and mobile IP addresses as the person moves have all caused issues with this. Fixing this is hard, but I have been trying.
Happy Eyeballs and switching to/from mobile are definitely hard problems to deal with in a privacy-friendly way, but I don't think IPv6 privacy extensions should really matter here. Just treat a /64 the same way you'd treat a /32 in IPv6-land. It may represent multiple users, but they're all sharing the same internet connection which is as much as the global internet really wants to tell you. Whatever's on the user-controlled side of the address is of course untrustworthy anyways.
Re: It took a year to ship WebAssembly in Anubis
#208Earlier quoted context omitted.
> because I dislike things running in the background without my knowledge Point of order: WASM doesn't let things run in the background. To do that you need WebWorkers (a javascript feature, not WASM-specific).
Two different kinds of "background". GP is talking about what indications they get a page is running arbitrary code as they load it, (some of) web workers is about persisting running that code after it's loaded. It can be in the "background" for both or neither, depending on the context, and both meanings are valid.
> GP is talking about what indications they get a page is running arbitrary code as they load it
I mean, you get the same indicators as when the page runs arbitrary Javascript on load? WASM assembly may be (slightly) harder to read than typescript compiled to JS, but the source is all there, it calls the same APIs, etc.
Re: It took a year to ship WebAssembly in Anubis
#209> It also means that the "hey Claude vibeslop me a CUDA Anubis solver" route is on its way to being fundamentally dead. Would there be any risk in making a dynamically built algorithm (i.e. the risk that we don't find N zero prefix bits)? Chain a set of transforms and build a unique WASM binary (including optimizations to deter pattern matching); possibly one a day or hour or something. That way you'd need to have Cl…
This is exactly what I've been working on. For obvious reasons around it not being done yet, I don't have anything else to say.
That's awesome!
Re: It took a year to ship WebAssembly in Anubis
#210Earlier quoted context omitted.
Two different kinds of "background". GP is talking about what indications they get a page is running arbitrary code as they load it, (some of) web workers is about persisting running that code after it's loaded. It can be in the "background" for both or neither, depending on the context, and both meanings are valid.
> GP is talking about what indications they get a page is running arbitrary code as they load it I mean, you get the same indicators as when the page runs arbitrary Javascript on load? WASM assembly may be (slightly) harder to read than typescript compiled to JS, but the source is all there, it calls the same APIs, etc.
They are not saying:
js on any site -> okay, I enable permanently
wasm on any site -> not okay, will never enable
js disabled -> I often get a fallback warning message letting me know a site needs it to work
wasm disabled -> I'd like a similar kind of message