3 ms·

Then you'd just give visitors of your websites no recourse and no information whatsoever on how to fix the problem. The benefit of client-side CAPTCHA is that h

by kccqzy 3y ago

Then you'd just give visitors of your websites no recourse and no information whatsoever on how to fix the problem. The benefit of client-side CAPTCHA is that humans at least can pass it and fix the problem even if something they don't control (such as their IP address having bad reputation due to shitty ISP) is causing problems. As a website operator it's easy to look at the spam that is getting through and be happy that's it's zero. But do you get any idea how many actual humans that you have incorrectly rejected? You don't have that data and it's really easy to screw up there. Of course if your website is small nobody cares. If you are bigger like Stripe you simply get bad publicity on HN. People on HN love to hate on mysterious bans and blocks just because they do something slightly unusual and your backend-only analysis flags them as suspicious. Abuse fighting is hard.

jsnell 3y ago
And just to be clear, it doesn't need to be either captchas or doing heuristic abuse detection on the backend. In the ideal case you're making a decision in the backend using all these heuristics and signals, but the outcome is not binary. Instead the outcome of the abuse detection logic is to choose from a range of options like blocking the request entirely, allowing it through, using a captcha, or if you're sophisticated enough doing other kinds of challenges. But proof of work has basically no value as am abuse challenge even in this kind of setup, the economics just can't work.
- deleted 3y ago
  [deleted]
dimmke 3y ago
>Then you'd just give visitors of your websites no recourse and no information whatsoever on how to fix the problem. This is a weird assumption. What's preventing a backend system from saying "Hey, we think you're a bot. Here's an alternative way to contact us." You obviously don't want to give away enough to help bot developers get through your system, but that's not the same as no resource and no information. >But do you get any idea how many actual humans that you have incorrectly rejected? Yes - like I said in my other comment, this new system actually logs all submissions. It just puts the ones it identifies as spam into a separate folder. Akismet also has the ability to mark things as false positives or false negatives. I think that automated form submissions are very context specific. So, the example I wrote about is for a marketing site, and it's a business that primarily targets other businesses. Most of the spam it gets is for scummy SAAS software, SEO optimization, etc... But my personal website has a very simple subscribe by email form. There were definitely a few spam submissions - someone just blasting out an email address and signing it up to whatever form would accept it. When I implemented double opt in - gone entirely. My larger point was that as an industry, we seem to have just capitulated to client side CAPTCHAs. And it sucks. It's one of the many shitty things about the modern web. But I think it's become just an assumption that it's needed, and we haven't reexamined that assumption in a while. I think it'd almost be better for there to be something could spin up in a container that has a base machine learning model, but can "learn" as you manually indicate messages etc... and then you can also choose a threshold based off your comfort level.
- kccqzy 3y ago
  > This is a weird assumption. What's preventing a backend system from saying "Hey, we think you're a bot. Here's an alternative way to contact us." Not a weird assumption, but a necessary assumption based on considerations of scale. A small-scale website that doesn't receive too much spam attempt can manually classify spam by human agents. A medium-scale website can have CAPTCHA to let through some visitors and the rest goes to human verification. You appear to be in this bucket. When the scale is huge, no other alternative way to contact exists. CAPTCHA becomes your only tool. In other words, CAPTCHA is only necessary because of scale; what do you think the first A stands for? But because of scale, alternate ways stop working.
  - dimmke 3y ago
    >When the scale is huge, no other alternative way to contact exists 1. This still doesn't preclude giving a blocked user recourse or information. Like how a streaming website will say "Hey, you're using a VPN. We don't allow that" - the user's recourse is to turn off the VPN, or find a new VPN that their service won't detect. 2. The case you're outlining is different from the scenario that most users are presented with a CAPTCHA. I encounter it when I am using a VPN and Googling something with Incognito mode. That means Google has already applied some heuristics and thinks that chances are higher than normal that I'm a bot (not logged in, no cookies allowed, masking IP address) before presenting the challenge. In those cases, you're probably correct that presenting a CAPTCHA is a reasonable option. I just think it's weird to have CAPTCHA be the default/first line in many cases. Especially with the focus on things like converting users.
    - sellyme 3y ago
      > Like how a streaming website will say "Hey, you're using a VPN. We don't allow that" - the user's recourse is to turn off the VPN, or find a new VPN that their service won't detect. No, the user's recourse is to stop using the streaming website and go back to piracy instead. Any speedbump to UX is a lost customer. You can not and should not assume that users are going to jump through hoops, because the overwhelming majority will not.
hedora 3y ago
Client side captchas are obfuscated code, so the bar of “the user can debug the problem and fix it themselves” is pretty high. Also, reCaptcha definitely engages in both hell-banning and allows incorrect answers to pass the test. I assume the logic for those things is mostly server side.

by kccqzy 3y ago

jsnell 3y ago

And just to be clear, it doesn't need to be either captchas or doing heuristic abuse detection on the backend. In the ideal case you're making a decision in the backend using all these heuristics and signals, but the outcome is not binary. Instead the outcome of the abuse detection logic is to choose from a range of options like blocking the request entirely, allowing it through, using a captcha, or if you're sophisticated enough doing other kinds of challenges. But proof of work has basically no value as am abuse challenge even in this kind of setup, the economics just can't work.

deleted 3y ago
[deleted]

dimmke 3y ago

>Then you'd just give visitors of your websites no recourse and no information whatsoever on how to fix the problem. This is a weird assumption. What's preventing a backend system from saying "Hey, we think you're a bot. Here's an alternative way to contact us." You obviously don't want to give away enough to help bot developers get through your system, but that's not the same as no resource and no information. >But do you get any idea how many actual humans that you have incorrectly rejected? Yes - like I said in my other comment, this new system actually logs all submissions. It just puts the ones it identifies as spam into a separate folder. Akismet also has the ability to mark things as false positives or false negatives. I think that automated form submissions are very context specific. So, the example I wrote about is for a marketing site, and it's a business that primarily targets other businesses. Most of the spam it gets is for scummy SAAS software, SEO optimization, etc... But my personal website has a very simple subscribe by email form. There were definitely a few spam submissions - someone just blasting out an email address and signing it up to whatever form would accept it. When I implemented double opt in - gone entirely. My larger point was that as an industry, we seem to have just capitulated to client side CAPTCHAs. And it sucks. It's one of the many shitty things about the modern web. But I think it's become just an assumption that it's needed, and we haven't reexamined that assumption in a while. I think it'd almost be better for there to be something could spin up in a container that has a base machine learning model, but can "learn" as you manually indicate messages etc... and then you can also choose a threshold based off your comfort level.

kccqzy 3y ago
> This is a weird assumption. What's preventing a backend system from saying "Hey, we think you're a bot. Here's an alternative way to contact us." Not a weird assumption, but a necessary assumption based on considerations of scale. A small-scale website that doesn't receive too much spam attempt can manually classify spam by human agents. A medium-scale website can have CAPTCHA to let through some visitors and the rest goes to human verification. You appear to be in this bucket. When the scale is huge, no other alternative way to contact exists. CAPTCHA becomes your only tool. In other words, CAPTCHA is only necessary because of scale; what do you think the first A stands for? But because of scale, alternate ways stop working.
- dimmke 3y ago
  >When the scale is huge, no other alternative way to contact exists 1. This still doesn't preclude giving a blocked user recourse or information. Like how a streaming website will say "Hey, you're using a VPN. We don't allow that" - the user's recourse is to turn off the VPN, or find a new VPN that their service won't detect. 2. The case you're outlining is different from the scenario that most users are presented with a CAPTCHA. I encounter it when I am using a VPN and Googling something with Incognito mode. That means Google has already applied some heuristics and thinks that chances are higher than normal that I'm a bot (not logged in, no cookies allowed, masking IP address) before presenting the challenge. In those cases, you're probably correct that presenting a CAPTCHA is a reasonable option. I just think it's weird to have CAPTCHA be the default/first line in many cases. Especially with the focus on things like converting users.
  - sellyme 3y ago
    > Like how a streaming website will say "Hey, you're using a VPN. We don't allow that" - the user's recourse is to turn off the VPN, or find a new VPN that their service won't detect. No, the user's recourse is to stop using the streaming website and go back to piracy instead. Any speedbump to UX is a lost customer. You can not and should not assume that users are going to jump through hoops, because the overwhelming majority will not.

hedora 3y ago

Client side captchas are obfuscated code, so the bar of “the user can debug the problem and fix it themselves” is pretty high. Also, reCaptcha definitely engages in both hell-banning and allows incorrect answers to pass the test. I assume the logic for those things is mostly server side.