Live data from Hacker News

It took a year to ship WebAssembly in Anubis

anubis.techaro.lol

151–160 of 210 posts

Re: It took a year to ship WebAssembly in Anubis

#151
post #75
post #48

Earlier quoted context omitted.

That just creates another problem: if you're taking any measures to reduce tracking (ie. clearing cookies on shutdown or using temporary containers), this won't work. If anubis was being deployed on a site that a user visits often (eg. HN), the user might be convinced to whitelist it, but most anubis deployments are on random blogs or fediverse instances that I might not visit again in months. I'm certainly am not go…

Look, if you're going out of your way to break expected behaviour on websites you shouldn't be surprised when people code to the most common denominator and then you have weird subtle breakage as a result.

Clearing cookies when all you want to do is read static content is not "breaking expected behaviour on websites".

Re: It took a year to ship WebAssembly in Anubis

#152

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.

I wonder if you could convince the Anubis author to implement x402 payments to bypass the PoW

[flagged]

Re: It took a year to ship WebAssembly in Anubis

#153

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…

It's amusing (although disheartening to me as someone who builds online games) that wasm is now being treated like a flash plugin by sysadmins. You're not entirely wrong, but it's just funny to me that we took a full ten years to get back to roughly the same place. Now with Ruffle running Flash in wasm, no less! We build shit that doesn't work in the DOM, search engines hate it, walled gardens try to block it, admins fear it, they shut it down and the whole thing starts over.

Re: It took a year to ship WebAssembly in Anubis

#154
post #69
post #63

Earlier quoted context omitted.

That argument also works against anubis. Why bother forcing clients to solve a PoW challenge, when you're fighting a bunch of unsophisticated attackers that will be deterred by a javascript challenge that requires them to solve `result = x + y`?

[flagged]

Not only is this not true, you are misgendering Xe. They use they/them pronouns.

Re: It took a year to ship WebAssembly in Anubis

#155

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

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

Re: It took a year to ship WebAssembly in Anubis

#156

> In my experience the kinds of people who run this exact combination of circumstances also tend to be the kind of people that have a wide variance in the level of kindness they display to the authors of open source programs that happen to be in their way. Love this. There’s been past discussion on HN re how OSS maintainers are treated, and this is such a wry sentence. I really appreciate the tone / attitude to the p…

Can you translate the American for me? “Wide variance”, does that they’re being assholes?

> Can you translate the American for me?

I'd say "wide variance in the level of kindness" is a rather British way to describe some of the opinions that have been voiced.

Re: It took a year to ship WebAssembly in Anubis

#157
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…

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.

Re: It took a year to ship WebAssembly in Anubis

#158

Earlier quoted context omitted.

Can you translate the American for me? “Wide variance”, does that they’re being assholes?

> Can you translate the American for me? I'd say "wide variance in the level of kindness" is a rather British way to describe some of the opinions that have been voiced.

100%, author lives in Canada and the phrasing has the British heritage of Canadian English.

Re: It took a year to ship WebAssembly in Anubis

#159
post #87
post #85

Earlier quoted context omitted.

Scrapers scrape every link they can find. The git host example is probably the one which Anubis is the dumbest defense for: the main reason to have those links is for easy machine interaction. So that's dead when you implement it. So why even host the links? It's a git repo: send them a local got client and let them clone the repo in browser or something.

The main reason to have those links is for people to click on them. No sensibly programmed machine is scraping diffs from a git web front end.

That's exactly what's happening to the Linux git repository. The server constantly has mutltiple CPU cores dedicated to rendering git of various old, dead branches in html for scrapers.

Re: It took a year to ship WebAssembly in Anubis

#160
post #88
post #71

Earlier quoted context omitted.

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.

That is true, but if you have Anubis you presumably do intend to `Disallow` all bots.

Not necessarily. You might want to rate limit bots instead of disallowing them.
Post reply on HN