[flagged]
It took a year to ship WebAssembly in Anubis
211–220 of 226 posts
Re: It took a year to ship WebAssembly in Anubis
#212Earlier quoted context omitted.
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.
It isn't even anime style, it gives me more western cartoonish vibes.
Re: It took a year to ship WebAssembly in Anubis
#213Earlier quoted context omitted.
Anubis is not free either, it is a matter of how much it costs to run Anubis vs to let bots in. When I see LKML using Anubis when the pages it serves are tens of kB, all presumably static, I wonder if they do it out of spite rather than to protect their servers.
It’s done out of necessity, you can read about why here: https://people.kernel.org/monsieuricon/creepy-crawlies As a user/reader/viewer I absolutely hate Anubis and usually turn around when I see it pop up (at least on my phone where it takes ages to compute), but with stats like that, I get why a site operator would resort to using it.
I think the kernel.org post proves the parent point rather than contradicts it.
> At any one time, across 5 geo-distributed nodes, there are 14 CPU cores doing nothing but rendering git commits as html.
14 CPU cores total for running a website like kernel.org is laughable. This is not worth burning cycles in Anubis on client's devices, this is not worth the time of the engineer who worked on it. Provisioning more hardware would have been literally better for everyone.
Re: It took a year to ship WebAssembly in Anubis
#214I 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 haven't disabled web workers, but am playing with the concept. T-Mobile's payment portal screams and then bans my IP (something like that) if try. I have disabled service workers globally, and so far no fallout.
Re: It took a year to ship WebAssembly in Anubis
#215I 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…
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.
I also have JS disabled in Firefox on my phone. It's on by default on my laptop, as I apparently visit different sites when my butt is planted in a chair.
My wish is actually for the days of NPAPI where Webassembly would be just another plugin (like Flash) and browsers clung to mainly HTML, JS, and CSS. Then developers wouldn't be quite so keen to rely on it and the web would be much less bloated. Yes, those days are long gone... As a tradeoff, I'd settle for a simple toolbar icon that lit up when Webassembly is running, and/or a high level UI (just like Location, Camera, and Microphone) so I can enable it for just those sites that need it. I tried selling Mozilla on the idea once but they apparently weren't interested.
Baselines aren't entirely universal. I remember the days when the Mozilla (or early Firefox) browser was the only viable web client for Linux, but some sites still opted to run behind ActiveX. Today I don't think you'll find a Haiku or Amiga browser with Webassembly support, nor Firefox for Linux on IBM Power motherboards. It's easy to forget that just because most any 'nix or BSD OS has a plethora of choices, that others aren't still dealing with the "ActiveX" situation and feeling like everybody's out to get them.
Re: It took a year to ship WebAssembly in Anubis
#216Earlier quoted context omitted.
Sure, then just replace it with something that is useful to society but not immediately profitable to a scraper, like science research
I want to do this eventually, but it's hard to split things into the micro-tasks that would be required to make this work on Anubis. One of the ideas I'm throwing around is a world where Anubis helps fuzz old games to find timesaves in tool-assisted speedruns. It's harder than you think.
Yeah, I'm using PoW-based "DDOS defense mechanism" for a current project and had this thought too. I briefly looked into what it would take to exploit PoW to do something economically valuable like folding@home, and it looked a bit tricky. At first glance, these sort of projects seem a bit unsuitable for real-time PoW because they were designed to be run on desktops and so tend to do things in large batches. There probably are other use-cases that could be more suitable though.
Might be worth chucking that thought into Astra, especially if someone springs the $$$ money for it?
Re: It took a year to ship WebAssembly in Anubis
#217I completely understand this change (esp. with regards to the change in type of problem) but I must appreciate the irony that this is essentially making it more efficent -- i.e. reducing costs -- to do a proof of work task, which aims to increase costs ;-)
Re: It took a year to ship WebAssembly in Anubis
#218Earlier quoted context omitted.
It’s done out of necessity, you can read about why here: https://people.kernel.org/monsieuricon/creepy-crawlies As a user/reader/viewer I absolutely hate Anubis and usually turn around when I see it pop up (at least on my phone where it takes ages to compute), but with stats like that, I get why a site operator would resort to using it.
I think the kernel.org post proves the parent point rather than contradicts it. > At any one time, across 5 geo-distributed nodes, there are 14 CPU cores doing nothing but rendering git commits as html. 14 CPU cores total for running a website like kernel.org is laughable. This is not worth burning cycles in Anubis on client's devices, this is not worth the time of the engineer who worked on it. Provisioning more har…
I can’t say I really disagree, and as a visitor of the site that’s the solution I would prefer.
Re: It took a year to ship WebAssembly in Anubis
#219Earlier quoted context omitted.
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.
That’s the most insecure thing I’ve heard in a while. What other things randomly flashing across your screen disturb you? Do you imagine your coworkers keeping count of which ads are displayed in your browsers? Do you imagine that they don’t also see the Anubis loading screens?
Re: It took a year to ship WebAssembly in Anubis
#220Earlier 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.
It's fixed enough for how much they want it to be fixed (I.e. how much they are being paid to fix it)