Suboptimal and an inefficient use of resources, yes, but possibly the only way to combat bots without privacy intrusive services. I'm open to hearing alternative ideas, though!
Bots will trend towards resembling real users exactly.
All you can really do is make it expensive for a bot to spam requests. Everything else will be identical to humans one day, and in the meantime it's annoying to block legit Tor users or legit scraper bots.
Seems like this might exclude users lower-end electronics that might be low-income.
Check out this guy on YouTube, he can pretty much open any lock in thirty seconds without causing any physical damage, will change your whole perspective on security.
https://youtube.com/c/lockpickinglawyer
It’s better to plan for people getting in then depend on preventing it.
If someone wants to make 10,000 accounts, I'd rather it cost them 5 cents per captcha solve, $500, than for it to be free.
Some attackers can make it pay off, but many can't, so they don't try. That makes my life easier, as I'm the one being paged during an attack.
Then you just need to make sure your algorithm is also space-hard and resists parallelization so GPUs and ASICs can't get it.
Basically it's a password hash, like Argon2. I think libsodium already has an official WebAsm build, so there you go.
Web browsers also have "crypto.subtle" but it's not allowed on file:// (making testing on local difficult) and I don't know if it has password hashing.
Generating 1MM units of PoW will always be more efficient than 1MM people generating each 1 unit of PoW.
Optimization always works better at scale. Therefore an attacker always has the upper hand.
PoW is absolutely useless as a CAPTCHA and doesn't even do what C.A.P.T.C.H.A. says.
It is true that it can still be annoying for extra CPU work though (and may waste energy), and if they both disabled scripts/workers and also won't or can't do otherwise despite that it will still be denied access.
Turns out when you zoom a picture in far enough, large bus windows, train windows, and building windows all look very similar.
I mean, if that's an intentional exception for personal scripts, that's awesome, but it doesn't really seem to serve the expectations of a CAPTCHA then.
Also, while I like the idea, I fear this could stop working in the long term.
With cryptocurrencies, PoW works because the "good guys" (miners) and the "bad guys" (double spenders) have equal access to computing power: If the difficulty increases, both can simply add more mining hardware and stay in the game. If the "bad guys" threaten to get an advantage, the system can always increase the difficulty without risking to lock out the "good guys".
With CAPTCHA, the situation is different: Here, the "bad guys" (spammers) still have as much computing power available as they can buy and stuff in their data center. However, the "good guys" (regular users) have hard constraint: They have to use whatever hardware the browser runs on (which might just be a smartphone) and they can't spend more than a few minutes to solve the puzzle - otherwise, the user will probably grow impatient and give up.
This means, you can't easily increase the difficulty of the puzzle without locking out regular users. If the captcha grows popular, there can easily be a situation where you'd make the captcha unsolvable for all regular users ling before it would become unsolvable for spammers.
No Bitcoin PoW works because of economics and game theory; it is rational if group of people invested a lot of resources into mining and building consensus that they will stick to that consensus in order to preserve their wealth.
Read what Satoshi said in the Incentive section of the Bitcoin Whitepaper: "If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins. He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth."
I mean, even in the regular, non-crypto economy there are lots of products that are sold at a loss for strategic reasons.
But you're right, that explanation wasn't quite correct. My point was that cryptocurrencies rely on the assumption that all legitimate users taken together have more computing power than a typical malicious user. That assumption is supported by game theory and made use of with dynamic difficulty adjustment.
However for a PoW captcha, the assumption does not hold: The captcha has to be solvable by WASM on a smartphone, otherwise it would lock out legitimate users. And that is a pretty low bar for an attacker to meet, computation-wise.
Isn't this already the case with other captchas where you can pay people to solve them for you? You could easily build a programmatic solution for that. If you're willing to "invest the work", nothing can really stop people automatically.
But I think the problem is that a PoW captcha can be cracked significantly more easily than a regular captcha:
For a regular captcha, a spammer would have to deal with brittle image analysis software or find people willing to do extremely boring, borderline illegal work for pennies.
For a PoW captcha, they have to load the page in Selenium and... that's it. All that's left is a slight bump in the power bill.
1. LSAT[1] support for micropayments (recently mentioned on HN[2])
2. RandomX[3], mining XMR for the site owner
Both provide something useful, replacing advertising and/or subscriptions for the site owner, rather than solely wasting energy. Let's eliminate captchas and advertising together.
[1]: https://lsat.tech/ [2]: https://news.ycombinator.com/item?id=28459713 [3]: https://xmrig.com/docs/miner
Any mining-based payment will inherently be worse and less efficient than a money-based payment, especially for mobile.
Excellent for preventing spam: https://twitter.com/lntxbot
The animated demo shows this perfectly. The bar which is showing the progress in the proof of work could just be a simple timer, and it would look exactly the same.
The back end generates the page, and makes a note of the current time. Then it doesn't accept the submission until N seconds have passed since that time. The animated bar on the front end is just for show; the browser isn't what is enforcing it.
Proof of elapsed time requires nothing from the other party. If I want proof that you spent at least 30 seconds waiting from the moment I gave you some starting signal, the only evidence I need to trust are the readings of my own stopwatch.
And so, that's why we need proof of work; thank you for bringing my derailed narrative back on the proper technical track.
Makes a note where exactly? In a data store? That means that I'm allowing an untrusted entity to trigger an action that requires me to store and later query my data store. That's a bad idea. The whole reason to have a captcha at all is to stop bots from overloading your system. The data store is a major bottle neck in most systems.
Proof of work is stateless. It's fast to verify. If you sign the challenge input before giving it to the user, you can also statelessly verify it's a legit challenge. No data store needed until after verification is complete.
Edit: also what ahsima said! The point of a captcha is to make it more expensive to use a bot net against you. Timers don't do that.
This stateless principle is implemented in TCP SYN cookies for warding off SYN flood attacks, for instance.
Thank you, also.
So if I have 100 cores available, I can run 100 sessions in parallel.
Type of spent resource is rather irrelevant, isn't it?
An attacker can easily an cheaply generate way more PoW than a legitimate user by optimizing their system.
This is just an "unskippable" delay timer not a CAPTCHA!
It does not. Its broken the day someone who can code wants to beak it.
>The user is not as affected by the cost...
Its exactly the opposite it affects the user not an attacker who can generate millions of PoW units on toaster for a few bucks. Or even use another systems idle time. No human needed == its super cheap. Unlike real CAPTCHAs where you need to pay real people to solve them.
Because of improved interfaces to exploit the poor, a spammer can already pay to have humans solve captchas using an API, just as well as they could pay for computing time to solve hashes.
As such, if you were to tune the difficulty of a computing proof of work to be more expensive to compute than to pay the lowest bidding human farm to solve a captcha, it should be better at decreasing spam.
If you would raise the PoW to cost more than that the average user would simply be unable to solve the PoW it in a meaningful time on their hardware.
Any waiting period for calculation that won't annoy users is not long enough for an attacker to not still be able to spam, given that they will be solving them 2-100x faster with an optimized native implementation vs in a browser.
It also doesn't work as a turing test, because by their nature computers are good at batch solving proofs of work.
I once started an anonymous email service with browser-based PoW for antispam. It didn't work.
You'd need users to do like, several hours of in-browser PoW to make it viable as an anti-abuse measure. Anything less means a bot farm is posting spam dozens of times per hour.
Frictionless micropayments are still a pipe dream today, as any useful technology available to do so has basically been outlawed in the USA without a multimillion dollar license, and a KYC department, et c. It's a real shame because we have all of the technology for cash-based anti-abuse bonds and the like. It's just illegal to deploy it unless you go full MSB.
Spammers aren't sitting there at an interactive session, waiting to create an account while staring at a spinner.
Not only is it a total privacy invasion, all the burden is borne by the service providers for implementing the government’s universal financial surveillance.
That's a problem; captchas need a fallback mechanism for situations when JS is disabled.
(I think that could be arranged; e.g. in the no JS case, the web application just spits out some token, which the user must copy and paste into some program that does the work, and then passes the answer back into the web application.
This seems like a very significant limitation. Is there a way around this?
My first though is that if instead of one problem 100x as hard you solved 100 easier problems. That at least would give you a somewhat accurate loading bar, but I'm not sure if that would actually reduce your variance.
There are tons of things in nature that are like this, for example how long it takes a spinning quarter to topple over on the table and land heads or tails. Its theoretically possible it could balance perfectly and never fall, but how many times have you seen that IRL???
It is completely fine to use it to build an application for a client. Such an application cannot become a product without becoming open source, however.
GPL is a great license, but for libraries (or „building blocks“) it greatly limits their usage. Not everybody wants to license their application as GPL. Just like not everybody likes bananas. Some prefer peaches or oranges.
It's perfectly possible to make a memory hard PoW that's instantly verifiable, by using something other than hashcash. Examples include Cuckoo Cycle [1], and Equihash [2]. These can easily be made to use hundreds of MB in solving, while verification is memory less.
But I'm curious if it might need more work in the 'accessible' area. Like, for example, is the progress bar percentage-done exposed in an accessible way? I don't see anything obvious here: https://git.sequentialread.com/forest/pow-captcha/src/branch... , seems like it just changes width via css styling, but I could be missing it. I'm not sure it presents an easily understandable reason why the submit button is disabled, that you need to wait, etc, either.
So I don't really have a great way to make it accessible to blind users at the moment, but it's only a couple code changes away, while most other "Captcha" solutions might require a redesign before they could be considered accessible.
This project is also cool: https://git.sequentialread.com/forest/greenhouse
A reverse proxy that lets you split the "public-visible focal point" part of a web server from the "Holds a lot of private data and runs code" part. So the latter can run in someone's living room.
It will redirect you to a unique link tied to your IP/User Agent string so if you want to see it again you will have to click the original link again.
Good thinking!
