Also with multiple requests from the same IP in a short timespan, the difficulty increases.
There are downsides to to any captcha, but in my opinion make a much better tradeoff. Accessibility and privacy are respected, and there are no annoying tasks.
The difficulty increase per IP can be seen as a form of soft rate limiting, it's shared between all websites (which is where it's different from ordinary rate limiting). In the future we may use IP reputation lists to guide the initial difficulty too - but we haven't implemented that yet.
I think that no perfect captcha can exist, which is inherent to the problem. Proof of work makes different fradeoffs, and perhaps it is cheaper to attack still - I think it's a much more friendly solution for users though (accessibility, privacy, simplicity, fairness, UX).
Maybe in the future the solution would be something like this: a long PoW-based captcha that runs in the background as well as a vision task for the user, whichever gets solved first.
But say, there's a website and it's a likely target, you implement IP protection, fine, the user uses residential proxies. Now your best bet is to go off fingerprinting, but there are marketplaces which sell those too in bulk.
Maybe I'm wrong, but wouldn't the best approach be to stick to human interaction puzzles, which are hard and don't have a set way to solve by a machine(for now)?
Adjusting based on average monthly salary in Bangladesh (157$) [1] and the US (4056$) [2] that would be similar to an American making 5.2$/hour which is surprisingly close to the current minimum wage in the US (7.25$/hour) [3]
So I guess this must be a fairly decent way to earn money if you're young/poor in Bangladesh...
[1] https://tradingeconomics.com/bangladesh/wages#:~:text=Wages%.... [2] https://www.thestreet.com/personal-finance/average-income-in... [3] https://en.wikipedia.org/wiki/Minimum_wage_in_the_United_Sta...
> So I guess this must be a fairly decent way to earn money if you're young/poor in Bangladesh...
Solving dumb captchas is never a fair or decent way to earn money, not when you are poor and definitely not when you are young. Creating living conditions for other human beings where they can be easily exploited and used for mindless degrading work such as solving dumb captchas is one of the most grotesque things of the 21st century.
The arms race is bad for everyone, in both examples, but the underlying problem is a fundamental one of misaligned incentives.
For someone who has little expertise in this specific field, how are you calculating this?
I'm convinced CAPTCHA are no better than fake/dummy security cameras.
I've seen people report that they have reduced spam to near nothing already with just a honeypot, but of course I can't verify those claims.
I will change the wording on the website and remove the percentage.
Can verify from personal experience. I once implemented a simple honeypot approach on a small blog site. It immediately cut down automated "drive by" comment spam to almost nothing. I never tried to quantify it, but it was the difference between dozens of spam comments a day and maybe one or two a week (which I assumed were probably manual submissions).
Most spam bots are pretty unsophisticated it seems, and do not pay any attention to a honeypot field being hidden either by CSS or JS.
After a few months you check how much spam arrived at either and get your number?
The solving can be a few times slower on a low end device which you should keep in mind. To aid with this when setting the difficulty for your website it shows you an estimate for various device types. This is indeed a downside of PoW approaches.
There is one factor that helps: you can start solving as soon as the form loads, so as the user enters their details/comment it can start solving - I have a hunch that people on mobile devices are inherently slower at entering their data which should help a bit..
Anyway - if you set the difficulty quite high and the solving takes 30 seconds, it takes the user 15 seconds to enter the form - the user would still have to wait 15 seconds. That's not very different from the time to solve image captchas (it's actually lower and doesn't come with a 2MB payload download which isn't great on phones either, and they can keep their privacy + sanity). You could give the user something to do that makes sense for your website (ask them for feedback?).
In general, I use form autocomplete to fill this quickly. And on the contrary, my mobile signups are faster than desktop because the lastpass firefox extension on desktop takes longer to detect the form before the autocomplete can begin than my phone does.
In all, this sounds really promising though. I’d venture that most spammers already have higher end machines than end-users to solve existing captchas.
I’d probably approach this with a different strategy. I’d send an encrypted time stamp as the nonce. On the client, I’d first do a few easy PoW tasks and estimate the PoW difficulty for the given machine that would take at least X seconds to do. Then, send the PoW, the encrypted time stamp, and difficulty to the backend. If it’s been shorter than X (with a margin of error), or the PoW is wrong, it’s not valid.
In this scheme, it doesn’t matter how powerful the device is, a core is going to do some work for X seconds or at least be throttled by time.
Tad amusing after all this time people still don't understand why proof-of-work schemes exist.
Rate limiting has zero cost to an adversary. PoW has physical costs. It's in the name :)
But seriously I like the idea, although it seems trivial for someone to attack a protected site by exhausting its subscription level? Are there any protections against that?
Right now we manually look at the limits and are reasonable with overages - also we can see how many captchas were unsolved.
As someone working in the field, I also doubt your claim "will prevent 99.9% of spam" is based on real data. Modern headless browser spambots are not deterred by this kind of approach.
(Edit: looks like the poster admitted this number was entirely made up later in the thread.)
Maybe not everyone but a lot of people use captcha services to prevent automation from being used to extract/insert data. I know as a developer that there is always a chance of bypassing this, even with Google's reCaptcha, but your service seems to make this trivial, so many won't even go beyond your demo.
Right, unfortunately you've completely misunderstood the point of Friendly Captcha, a question which is answered right there on its main page.
>>How does FriendlyCaptcha tell apart bots from humans?
>>It doesn't, FriendlyCaptcha adds a small cost and complexity for spammers that becomes large at scale.
You might also want to rebrand to use a different word than "Captcha" as you're not actually telling robots and humans apart, you're simply adding PoW to an action, nevermind if they are robots or humans.
So instead of blaming users for misunderstanding your message, maybe try working on making your messaging a bit clearer so for the people who know what captcha is, don't get confused by your own definition of it.
I'm using latest Firefox on GNU/Linux. Admittedly I've got a lot stuff blocking all sorts of things, and I'm not really sure what's kicking to block background workers, but I'm glad it's blocked. Anyway, after disabled literally all blocking tools that I have, it still refuses to load.
We test the captcha in browsers up to 8 years old and on many devices, do you perhaps have background workers disabled entirely? Here is a link to the widget on its own [1], does that have the same behavior? How about a minimal worker example [2]?
[0]: https://github.com/FriendlyCaptcha/friendly-challenge [1]: https://unpkg.com/[email protected]/index.html [2]: https://jsfiddle.net/christopheviau/90syrp0q/
The reason you wouldn't always want to start it in the background is if the user may not intend to submit the form (perhaps it's a form that is in your footer of every page and only a small percentage of users intend on sending it). Starting it on focus of the form is a good default.
20 seconds would be a fairly high difficulty. It's up to the site owner to decide what makes sense for them.
If anybody comes up with a useful computational task with a small bundle size that can be verified cheaply that would be the holy grail - until then the computation is only there as a form of hashcash.
It’s also nonsense to compare the computational cost of N seconds of sustained, maxed out useless computation to the milliseconds of compute time needed to decode an image, or the minimal power usage of waiting on network data.
It's reaching a point where encapsulating a VPN with anti-captcha is something I'd pay for.
Yes but no. Anonymized identifiers can be deanonymized. They should utilize zero-knowledge proofs in such a way that they can prove "yes, I have an identity verified by entity X (and Y and Z) (based on passport/phone number/...)", without disclosing any of those details.
It could, optionally, yield an identifier unique to each requester and unlinkable to others unless an explicit proof of the link is provided. Though if this is included, there has to be some mechanism to avoid huge ad networks sharing the same "requester entity".
This is a solved problem. All that's left is politics, implementation and alignment.
I have actually discussed the concept in the past [0], and I exchanged some emails with the guy in that thread to talk more about technical details. We all seem to agree that design and political will are the problems, not technology.
What I was basically saying in the comments, in general terms, is that you might have one primary identifier, and then somehow you can get more identifiers that are tied to your main one, but that might have different expiration periods, might grant access to different levels of information about you, and might be limited to a certain number for each service you use. Of course, there are quite a few ways to implement such a system. And that's precisely why I'm more focused on the design, usability and characteristics than the underlying technical implementation; I think the best we can do if we ever want to see this happen is to spread the idea in terms that anyone can understand [1]. I mean, I'm interested in the technical details too, so I'm just complementing and contextualizing a bit here.
[0] https://news.ycombinator.com/item?id=22180120
[1] ...or discuss more the idea among those that are interested and setup a demo website to make it easier to spread the word, even if there's no actual implementation behind it and it's just a mock-up. I'm quite busy at the moment, but I'll definitely do something along those lines when I have some time.
Actually, I would prefer: "Yey, this one-use temporary ID is tied to an identity which is known to behave on public websites." Or "... is tied to an identity which is known to be knowledgeable on topic X". Or whatever information is needed at the time.
Next time a new ID will be generated and the identity provider will vouch for it. No passport or phone number should be required.
Edit: fixed spelling.
I've used the service in the past, though it's far enough in the past all I can say is it worked once upon a time, no clue if it's still reliable.
"Because scaling. It is our God-given right."
I wonder if they’ve partially automated recaptcha, or if hCaptcha is just a bigger pain in the neck. (I usually can’t solve a reCaptcha in 15 seconds...)
As much as I agree with your dislike of captchas, I don't think this is true at scale (unless universal online identities existed, which could and should include anonymous identifiers by design). When you need to accept information from anonymous users (comments, votes, forms, registrations), there's no way to not invade users privacy and not waste their time, unless you are manually filtering / moderating all the input data, in which case you can't really say it scales. You might say emails can solve the problem. Well, they don't really solve the problem against dedicated attackers / spammers, and they do invade privacy for the average user. You can use statistical approaches to try to reduce privacy invasion or others, but I don't know of anything that really solves the problem without manual identity verification at some point.