Live data from Hacker News

It took a year to ship WebAssembly in Anubis

anubis.techaro.lol

91–100 of 226 posts

Re: It took a year to ship WebAssembly in Anubis

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

[flagged]

Re: It took a year to ship WebAssembly in Anubis

#92

Earlier quoted context omitted.

[flagged]

Anubis is significantly better than Cloudfare from a ux perspective because it doesn't require interacting with the page. Being gated by turnstiles and having to stop what youre doing while you're waiting is infuriating. To say nothing of Google hard blocking people it doesn't like out of websites and alluding to moving towards ID verification for its captchas. You sound like a child throwing a tantrum. Before throwi…

Argumentum ad "anime girl beats multibillion dollar company"

Re: It took a year to ship WebAssembly in Anubis

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

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 lost. Fighting it today is rough; tomorrow, futile.

Re: It took a year to ship WebAssembly in Anubis

#96

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

This could be done at the web server level, not requiring changes to Anubis

Re: It took a year to ship WebAssembly in Anubis

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

Not to mention it is the least efficient representation of git commits. It seems a lot of people are unaware that git generates the diff representation you see with "git show" on the fly -- internally, commits are Merkle trees representing a snapshot of the repo file contents.

As you said, if you actually want to interact with a remote git repo you'd do so with packfiles not diffs.

Re: It took a year to ship WebAssembly in Anubis

#98
post #75

Earlier quoted context omitted.

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.

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…

>Gotta agree. Turning tracking cookies off? Sure! Turning session cookies off and then complaining that the server doesn’t remember you? Uhhh…

No, because there are technologies that don't have this issue, eg. privacy pass.

Re: It took a year to ship WebAssembly in Anubis

#100
> 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?

Post reply on HN