-
-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Find alternative to reCAPTCHA (Google's spam prevention) #1647
Comments
hCapctha seems tobe very popular for solvers on GitHub itself, from a cursory search. |
I don't think we currently need an alternative. The "buster" solver is a browser extension. The kind of bots we are worried about don't use a regular browser with extensions installed, because then a normal human could just do it. It's about scaling up. I have yet to see a proof of concept that this captcha is really as bad as argumented here. I will close this issue if no further information or arguments are provided. |
It usually requires no interaction from humans, but if your score is too low, that's when you get a challenge (supposedly; I didn't see it in the official docs).
Not sure what this is based on. You can easily run "headless" FF or Chrome instances, or cannibalise the extension and run it in Node or something. And a quick web search suggests that yes, v3 can also be broken. All of this is missing the point: reCAPTCHA is a Google product, and Google is not your friend. If you wanted to use reCAPTCHA v3 properly, clients actually need to load and run JS from Google on most pages. That would be a very bad idea. |
So where does that information come from?
But we don't use it on most pages. We also use YouTube as the place to watch the very content our site is designed around. We also allow embedding YouTube directly in our submissions or forum posts. Many other very popular websites also use reCAPTCHA. I don't understand what this issue is for. If you want complete isolation from Google that's fine. But then you also have to accept it if there is a a decision against Google isolation. Marking this reCAPTCHA as a "security" issue of our site is backwards. It'd be a security issue if we didn't have a CAPTCHA. And looking realistically, what we have currently is the best you're going to get, considering the site circumstances. It's a solid working solution requiring no further maintenance and is future proof. |
Sorry, but I have to stand up for this one, and that involves tearing apart your argument.
I think it's in one of the articles I linked, but that's also how v2's invisible mode works. The alternative would be you're just locked out of the form, which would be dumb. The official docs do say "reCAPTCHA v3 will never interrupt your users," so maybe it is that after all.
This was always just an example.
That's right, the site doesn't implement reCAPTCHA properly at the moment. It needs to track users by design—that's nominally how it knows what fake traffic looks like. This is why I suggested alternatives based on proof-of-work.
By proportion of time spent "on" the site, watching encodes may be the biggest, but encodes are hosted on the Internet Archive as well as YouTube. And emulator playback is also an option.
Trivially blocked client-side.
Not relevant.
You should reasonably expect that choosing not to patronise Google would lock you out of their services (and third-party services which are deeply integrated with e.g. Drive). You shouldn't expect it to lock you out of half of the Web.
You should know this issue predated the new label—but I'd also argue that forcing clients to run opaque third-party code is a security issue, as well as a privacy one.
The solution that's not implemented properly is the best you're going to get? |
Okay that post is kind of too long for me to understand. Sure, consider my replies "torn apart". I'll let adelikat handle this one. |
It can be, but it's exceptionally rare. |
This is the actual reality for some users who are having trouble even registering onto the site. The implementation done in here at least will just make it so the user cannot register if their score is too low (and there's typically no way to fix that other than trying a different internet connection / maybe some VPN) At the very least we should not be using some purely invisible service, if it means a human in any possible case has no way to register onto the site. |
3 of 53 responses or ~5% said they don't use YouTube, which I'd say is a not insignificant proportion, but the sample isn't nearly large enough to say anything. Videos on the TASVideos channel regularly get a couple thousand views. With #1790 merged, the site is now firmly on v2 of reCAPTCHA, so our earlier bikeshedding over how feasibly v3 can be attacked is no longer relevant. What benefit the CAPTCHA provides remains questionable. |
Over the years we have had some pretty massive bot account spam. Years back, on occasion, our captcha would get cracked and we would get 2-3 new accounts a day that were spam. Then we update the captcha and it goes away. To this day we get the occasional spammer. We know we have a problem here, and I believe it would get worse without a captcha |
No-one ever suggested there should be no CAPTCHA on the site. |
reCAPTCHA is easily defeated for cheap (and, seeing as the client makes a request to a Google-owned domain, isn't exactly the best idea for user protection).
Some alternatives:
The text was updated successfully, but these errors were encountered: