PoW rate limiting actually pre-dates PoW cryptocurrency, the former has just had a resurgence recently in response to AI scrapers pissing in everyone's pools.

https://en.wikipedia.org/wiki/Hashcash

The original Bitcoin paper even cited Hashcash as inspiration.

I think it's only more expensive for bots, though just as easy for bots.

The problem with bots is they quite often farm this out to stolen resources. It makes sending whatever they are sending slower, but doesn't stop it.

Think of crawlers: a crawler typically makes hundreds or thousands of requests per second. The owners of the crawler then sell this data for X$, or gain X$ profit.

Proof of work adds a very small cost to each individual request, increasing the cost of crawling to a number higher than X. Because actual humans make very few requests, we don’t notice the increase in cost.

It's equally easy for both. But people using broswers only do it a few times, while bots need to do it many times. A second for a human every X pages is not much, but it's a death-knell for the general practice of bots (and they can't store the cookies because you can rate-limit them that way).

Imagine scrapping thousands of page, but with a X>1 second wait for each. There wouldn't be a need to use such solution if crawlers were rate-limiting themselves, but they don't.

i wrote a bit about it here: https://capjs.js.org/guide/effectiveness.html

Probably to demonstrate. Attaching to a form submission or any modifying action would work.

They don't detect if you're a human exactly. What they do is they create a calculation expense that is negligible if there's one of you but adds up quickly if you're running a bot farm that needs to send out 10,000 requests a second.

So I click the button, my browser does a quick proof-of-work, no big deal.

But an automated script will have to complete that proof-of-work every time it encounters it, skyrocketing the cpu costs for the server.

They don't detect if you're a bot or not; it just makes it more expensive, the idea being that doing $action 10,000 (or more) times becomes much more costly for the attacker, preferably to the point where doing $action (posting spam, creating accounts, etc.) is no longer profitable. It's probably more useful to see it as a ratelimiter than a bot detection mechanism.

They make it expensive to run large scale bots, so that deters the bots.

And they (probably?) use the computation power to crack passwords from people to let the government agencies access their accounts...

Better suited for discouraging scraping. 2 cents * 300 scrapes = $6 although 2 cents is huge over estimation and you would probably not show this every time. Only when there is unusual traffic.

If it actually cost 2 cents, it'd be tremendously useful. There are huge tranches of abuse that would become unviable with that resource cost.

In reality passing the PoW will cost more like 1/10000th of a cent, and you can't make it cost significantly more (let alone 2 cents) without making access totally impractical for real users. Proof of work challenges for abuse are basically snakeoil, it's impossible to make the economics work.

I like the citizen science idea, the bitcoin one is so shitty. There was an epedemic of websites covertly mining in browsers a while back and this is a dangerous road to go down.

Do you have an example of scientific grid computing that is expensive to compute but cheap to verify? Those are the properties this needs.

Because the overhead of orchestrating and distributing the problem would be much larger than the amount of work you can do in 1 second?

"invisible mode" in CAPTCHAs are great for login forms. In the background the captcha runs. If it passes, the user doesn't need to be bothered with it. If it doesn't, the user is presented the standard captcha.

I agree I hate the CF captcha popups, but I think this is a result of AI scraping. GET requests can be expensive on dynamic sites with infinite paths — like a git host.

> how much more CO2 this is going to produce extremely minimal emissions, you're only solving a small cryptographic challenge after all.

Just wait until you see how much energy your browser consumes in idle mode.

Sorry what is IA?

Isn't IA's architecture pretty strained already without this?

What would that solve? A scraper could just have a wallet with 10$?

How do you know?

Such site is better provide some unique service no one else can.

There is no way I am sharing my phone number with random sites unless I absolutely have to, I get enough spam & scam already, and tracking potential is enormous.

> I was wondering if more sites will start to drift to a system where they require you to be logged in to an account attached to a SIM card in some ways.

I hope we move away from SIM cards - they'll require SIM based auth checks and low paid staff at cell phone companies will happily give away my SIM card to another phone to get a kickback from robbing people.

Yes because having an account gets around adblockers, anti tracking, age verification and section 230 removal issues. ToS is already weaponized.

> a SIM card

That's basically what remote attestation is. But it's using TPMs (or similar) rather than SIM cards. The TPM has a key signed by the manufacturer, and that key can be used to sign tokens to prove that you possess a physical TPM and have it in a mode that provides access to that key.

The problem with either is that the system doesn't work if you can get access to the keys behind the system. That means banning everyone who uses a vulnerable model of SIM card/TPM implementation. SIMs are cheaper to replace, but you'd have to replace millions of them every time someone manages to voltage glitch a SIM card.

If you own an iPhone or Macbook, you have access to a browser you already does this: https://developer.apple.com/news/?id=huqjyh7k

Phone number is also good because you can be reasonably sure as to whether it's voip or not. It is literally the one non-awful solution to the sybil problem we have discovered (the awful ones being things like gov id).

No need for the SIM, just being logged in to something will probably be enough to stop most crawlers.

Then, if someone is logged in, you can throw TOS their way, and make it a legal problem.

Yup, I've been running Altcha on pirsch.io for a while now, and it was super easy to set up, is free, and open-source.

One of the main reasons we've switched from hCaptcha is privacy. The server-side stuff can be self-hosted and there is a Golang integration. Really nice.

Here is the link for anyone who would like to take a look: https://altcha.org/

I'd be so happy if the Internet moved away from Cloudflare for Captcha. I got on their "bad list" at one point (for who knows why), and no matter how many times I checked the "I am a human" box their Captcha wouldn't let me through for a few days. I was unable to login to the portal of a product that we pay for. It was such a frustrating experience.

anubis is more like Cap's checkpoint, but still the implementation is very different.

I think it’s great. It tries to catch bots, which are capping that they’re human. :)

frfr?

too late to change now :)

also i like how it's a reference to both CAPtcha and "no cap"

scrapers usually don't render a webpage, else their scraping wouldn't be efficient at all.

> Normally, it is undesirable for users’ passwords to be cracked. However, in the case of law enforcement, we often need to obtain suspects’ passwords in order to access encrypted evidence. The obvious solution is to build powerful (and expensive) dictionary cryptanalysis computers. A less obvious approach is to use the distributed power of web users’ computers, as has been done in the Seti@Home (https://setiathome.berkeley.edu/ — suspended project) or Folding@Home projects (https://foldingathome.org/). The proposed approach can therefore support law enforcement activities while providing the desired functionality to the web community

"You're not allowed to visit this website unless you submit your computer to being part of the fed's password cracking botnet" that's a whole fresh hell. A better use case is right there in their own description! I'd love my captchas to be little Folding@Home problems.

Interesting discovery. This research sounds creepy and ill-advised, but my intuition suggests to me this is an innocent attempt to do something useful rather than waste energy on a PoW algorithm. My intuition also tells me that if this project became popular enough, attackers would break the algorithm fairly easily and the project would just revert to a more conventional PoW algorithm that doesn't try to be smart.

Definitely concerning, although I'm having trouble finding anything in the codebase to support this.

This paper even seems to contradict aspects of the project's no tracking stance. If someone told me this paper was for a different (but similar) project, I'd believe it after looking at the two side by side.

Would definitely want this to be addressed before I'd consider using it.

I think there's a good chance they just linked to the paper for technical background, unrelated to the paper's mention of law enforcement usage. The website mentions self-hosted, no third-party requests, etc. Unless they're flat-out lying.

Cap does not send any of the calculated hashes ANYWHERE, the white paper just details a bit how proof-of-work works and I thought that it would be interesting to share.

https://github.com/vaxerski/checkpoint has noscript mode.

> Also users may be at a disadvantage as JS crypto would not be optimized for PoW (for example lack parallel crypto capabilities or context switching between calls).

JS crypto is only used as a fallback, Rust WASM is used for solving.