I am, but what I said was more of a hypothesis than a fact :)
From what I understand of reCAPTCHA, the model isn't static and is continuously learning from every interaction[0]:
> reCAPTCHA’s risk-based bot algorithms apply continuous machine learning that factors in every customer and bot interaction to overcome the binary heuristic logic of traditional challenge-based bot detection technologies.
I don't know the energy demands of such a system.
mCaptcha, under attack situations, will at most take 5s of CPU time on a busy (regular multitasking with multiple background process) smartphone.
mCaptcha uses PoW and that is energy inefficient, but it not as bad as the PoWs used in blockchains. The PoW difficulty factor in mCaptcha is significantly lower than blockchains, where several miners will have to pool their resources to solve a single challenge. In mCaptcha, it takes anywhere between 200ms to 5s to solve a challenge. Which is probably comparable to the energy used to train AI models used in reCAPTCHA.
The protection mechanisms used to guard access to the internet must be privacy-respecting and idempotent. mCaptcha isn't perfect, and I'm constantly on the lookout for finding better and cleaner ways to solve this problem.
Yes, the only differences are that mCaptcha is 100% FOSS and uses variable difficulty factor, which makes it easy to solve Proof-of-Work under normal traffic level but becomes harder as an attack is detected.
To impose delays, there must be some way of identifying users individually. But to do so will have privacy implications. PoW is a stateless way of imposing delays without the privacy implications of tracking.
That said, it isn't perfect. I'm on the lookout for cleaner and more efficient ways of doing it.
Agreed, it's been an interesting discussion so far with lots of interesting ideas. mCaptcha is a very niche software, that will only work some use cases, but that's okay as long as whoever's deploying it is aware of its drawbacks. :)
I haven't encountered a case where multithreading will make the algorithm weaker, but I do have a variation of the benchmark code(on disk, at the moment) that will spin up multiple worker threads to compute PoW.
Apologies, the project isn't ready to be showcased yet. I literally woke up to a message from a friend that said it was on HN. I wish I could explain it on here, but I'm afraid it isn't that easy. Here's the high level overview:
1. mCaptcha sends a PoW configuration(first XHR request in the demo widget[0]) which includes a challenge text("string"), a salt and a difficulty factor
2. Client generates proof of work by concatenating "string" + salt until difficulty factor is met. If difficulty factor isn't satisfied, it will continue trying to generate Proof of Work(PoW) by appending nonce and incrementing it until the difficulty factor is satisfied.
3. Client sends PoW to mCaptcha, which includes nonce, original salt and "string"(second XHR request in the demo widget)
4.mCaptcha computes hash for "string" + salt + nonce. If difficulty factor is met(i.e resultant hash > difficulty factor), then mCaptcha responds with access token.
5. Client sends access token to the web service.
6. Web services authenticates access token with mCaptcha and only grants access to protected resource, if the token checks out.
I will work on a more detailed specification and report back when it is ready(3 weeks, I think)
> Thinking about it a bit more, systems like mCaptcha and Botpoison aren't really CAPTCHA in the strict sense
Very true! I chose to use “captcha” because it's easier to convey what it does than, say, calling it a PoW-powered rate-limter.
> The real value is in the combination of factors, especially what BP call the "session and request analysis" and other fingerprinting solutions.
Also true. I'm not sure if it is possible to implement fingerprinting without tracking activity across the internet --- something that a privacy-focused software can't do.
I have been investigating privacy-focused, hash-based spam detection that uses peer reputation[0] but the hash-based mechanism can be broken with a slight modification to the spam text.
I would love to implement spam detection but it shouldn't compromise the visitor's privacy :)
[0]: please see "kavasam" under "Projects that I'm currently working on". I should set up a website for the project soon. https://batsense.net/about
Accessibility is a critical to mCaptcha. In fact, Codeberg is trying out mCaptcha purely because of its more accessible[0]. That said, it is possible to choose a difficulty factor very high to deny access to folks with older, slower devices. A survey to benchmark mCaptcha performance on devices in the wild is WIP[1]. I hope it will provide insights to help webmasters integrating mCaptcha to select difficulty factors that work for their visitors.
Only recently, yes. WASM performance is tricky. A memory-heavy algorithm will DoS visitors.
That said, there are protections within mCaptcha to protect against ASICS(PoW result has expiry and variable difficulty scaling), but they are yet to be validated. If they should prove to be insufficient, then I'll try a different approach with memory-heavy algorithms.
Thank you for your detailed response, you raise some very interesting and valid points!
> JS engines (or even WASM) aren't going to be as fast at this kind of work as native machine code would be
You are right. mCaptcha has a WASM and a JS polyfill implementations. Native code will definitely be faster than WASM but in an experiment I ran for fun[0], I discovered that the WASM was roughly 2s slower than native implementation.
> It's also based on the assumption that proof-of-work is going to increase the cost of doing business
mCaptcha is basically a rate-limiter. If an expensive endpoint(say registration: hashing + other validation is expensive) can handle 4k requests/seconds and has mCaptcha installed, then the webmaster can force the attacker to slow down to 1 request/second, significantly reducing the load on their server. That isn't to say that the webmaster will be able to protect themselves against sufficiently motivated attacker who has botnets. :)
> There's also the risk that any challenge that's sufficiently difficult may also make the user's browser angry that a script is either going unresponsive or eating tons of CPU, which isn't much different from cryptocurrency miner behavior.
Also correct. The trick is in finding optimum difficulty which will work for the majority of the devices. A survey to benchmark PoW performance of devices in the wild is WIP[1], which will help webmasters configure their CAPTCHA better.
[0]: https://mcaptcha.org/blog/pow-performance Benchmarking platforms weren't optimised for running benchmarks, kindly take it with a grain of salt. It was a bored Sunday afternoon experiment.
> I appreciate the effort towards better UX, but there are already "invisible" CAPTCHAs like Botpoison that discriminate better than this.
Interesting project, thank you for sharing! From Botpoison's website[0] under FAQ:
> Botpoison combines:
> - Hashcash , a cryptographic hash-based proof-of-work algorithm.
> - IP reputation checks, cross-referencing proprietary and 3rd party data sets.
> - IP rate-limits.
> - Session and request analysis.
Seems like it is PoW + IP rate-limits. IP rate-limits. though very effective at immediately identifying spam, it hurts folks using Tor and those behind CG-NAT[1].
And as for invisibility, CAPTCHA solves in mCaptcha have a lifetime, beyond which they are invalid. So generating PoW when the checkbox is ticked gives optimum results. But should the webmaster choose to hide, the widget, they can always choose to hook the widget to a form submit event.
yikes! The docs had an overhaul last week, that link was removed as part of the overhaul. Should have paid more attention. Should be fixed now :)
> A one-sentence describing exactly what it does and how it works would help ;-)
Here goes nothing:
mCaptcha is a privacy-focused, highly accessible CAPTCHA that uses Proof of Work for rate-limiting. It makes the bot/spam spend more time and work sending the request than it takes for the server to respond.
> Instead of an easy mode and advanced one I would use a single mode with a calculator, that way it is more transparent to the user and it would make the process of learning the advance mode and concepts easier.
Makes sense, I'll definitely think about it. The dashboard UX needs polishing and this is certainly one area where it can be improved.
> Also, here: https://mcaptcha.org/, under the "Defend like Castles" section, I think you meant "expensive", not "experience".
Fixed! There are a bunch of other typos on the website too, I can't type even if my life depended on it :D
> How does that work without becoming a SPOF for taking down the website ? Can't a user/botnet with more CPU power than the server simply send more captchas than can be processed ?
Glad you asked! This is theoretically possible, but the adversary will have to be highly motivated with considerable resources to choke mCaptcha.
For instance, to generate Proof of Work(PoW), the client will have to generate 50k hashes(can be configured for higher difficulty) whereas the mCaptcha server will only have to generate 1 hash to validate the PoW. So a really powerful adversary can overwhelm mCaptcha, but at that point there's very little any service can do :D
> In addition, using sha256 for this is IMHO a mistake, calling for ASIC abuse.
Good point! Codeberg raised the same issue before they decided to try mCaptcha. There are protections against ASIC abuse: each captcha challenge has a lifetime and also, variable difficulty scaling implemented which increases difficulty when abuse is detected.
That said, the project is in alpha, I'm willing to wait and see if ASIC abuse is prevalent before moving to more resource-intensive hashing algorithms like Scrypt. Any algorithm that we choose will also impact legitimate visitors so it'll have to be done with care. :)
I used "captcha" to simplify mCaptcha's application, calling it a captcha is much simpler to say than calling it a PoW-powered rate limiter :D
That said, yes it doesn't do spambot form-abuse detection. Bypassing captchas like hCaptcha and reCAPTCHA with computer vision is difficult but its is stupid easy to do it with services offered by CAPTCHA farms(employ humans to solve captchas; available via API calls), which are sometimes cheaper than what reCAPTCHA charges.
So IMHO, reCAPTCHA and hCaptcha are only making it difficult for visitors to access web services without hurting bots/spammers in any reasonable way.
From what I understand of reCAPTCHA, the model isn't static and is continuously learning from every interaction[0]:
> reCAPTCHA’s risk-based bot algorithms apply continuous machine learning that factors in every customer and bot interaction to overcome the binary heuristic logic of traditional challenge-based bot detection technologies.
I don't know the energy demands of such a system.
mCaptcha, under attack situations, will at most take 5s of CPU time on a busy (regular multitasking with multiple background process) smartphone.
[0]: https://www.google.com/recaptcha/about/