https://en.wikipedia.org/wiki/Hashcash
The original Bitcoin paper even cited Hashcash as inspiration.
https://www.researchgate.net/publication/374638786_Proof-of-...
"Proof-of-Work CAPTCHA with password cracking functionality"
The "work" is "to use the distributed power of webusers’ computers" to "obtain suspects’ passwords in order to access encrypted evidence" and "support law enforcement activities".
Funny how that isn't mentioned anywhere in the linked site.
"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.
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 like this. Allows for reasonable bots like IA without the mindless wasteful AI scrappers.
One advantage a PoW "CAPTCHA" system holds is that the service operator can change the algorithm whenever they want. This may make an ASIC approach too risky to bother with. The JS<>ASM crypto bridge would nevertheless require some optimization from the browser developers.
Some cryptocurrencies which aim for ASIC resistance create PoW algorithms that would require re-implementation of a significant fraction of the the CPU die to be a viable ASIC attack vector. An example of that would be randomx[1]. Using it for in-browser PoW would require native support as it will not be competitive against the bots with just a JS or WASM implementation. A modification would need to be made to not be abused for crypto mining. This will also link the cost of the PoW solution to the opportunity cost of mining the respective cryptocurrency which is well understood.
JS crypto is only used as a fallback, Rust WASM is used for solving.
I feel like accounts that require phone verification are already similar in that they require a some cost to access. It obviously wouldn't stop a large corporation from buying up thousands of numbers if they needed it for a specific purpose, but it would be prohibitively expensive for most to try this.
The benefit of the SIM system is it actually costs zero for people since they already have a cell phone.
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.
This captcha still lets all traffic through. Except now you waste the battery of honest users.
Even HN proponents of the idea don't use it on their own sites.
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.
Paired with this, and if there is a way to block out DDOS https traffic then we might be able to stop dependence on Cloudflare altogether.
I don't know enough about the underlying proof-of-work stuff to comment on how effective this could be, but I think it's pretty funny that the UI examples say "I'm a human".
I guess "there's only a few of me at most" or "I could allocate enough computation to this that I'm probably not up to no good" don't read as clearly.
At the time, it was an idea based on spam prevention active systems. However, for the browser, there are many issues with such solutions—if you can solve it, then bots can too. It slows them down a little, but that's about it.
also i like how it's a reference to both CAPtcha and "no cap"
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.
(I really couldn't care less about the climate debate, but waste is waste.)
Actually, this just uses SHA-256 hashing, which already has specialized CPU instructions (that browser WASM can't use) and ASICs.
I can't see how this isn't DOA?
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.
And they (probably?) use the computation power to crack passwords from people to let the government agencies access their accounts...
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.
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/
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
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.
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.
Then, if someone is logged in, you can throw TOS their way, and make it a legal problem.
There's no way in he'll I'm going to create an account on every site I want to read, and absolutely I'm not submitting my number for the eternal, unrelenting spam.
I have enough crap from the legitimate companies selling/leaking my number, to now deal with _that_.
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.
I do think that calling this a CAPTCHA when it's not actually intended to distinguish humans from computers is a bit misleading, but I can see why you would do that
If some site uses this and I only want that site as an attacker or as a personal scraper or etc, this is keenly ineffective at proving human vs bot.
FWIW, I do believe you just made a few unintentional awkward choices instead of being malicious... But a product associated with something like this is a hard sell.
what it's literally just the default emoji for cap
> lack of acknowledgement on your site (until now)
i've added a note
[1]: https://github.com/tiagorangel1/cap/blob/main/wasm/build.js
Very surprised to get pushback on what I thought was an industry standard lmao
So would bad actors. Which is why everyone uses normal captchas and not mere PoW.
PoW is the easiest captcha to beat.
Every time a new submission is created on HN, you have a curl script that posts a comment on it shilling your product. (According to the /newest tab there seems to be one submission every few minutes.)
What's harder for you to automate: the comment always posts successfully after 500ms, or you get a Cloudflare Turnstile captcha every time?
> CAPTCHA alternative