3 ms·

The problem is that any solution so far proposed for this is very privacy-unfriendly. For example, Google proposed https://github.com/explainers-by-googlers/We

The problem is that any solution so far proposed for this is very privacy-unfriendly. For example, Google proposed https://github.com/explainers-by-googlers/Web-Environment-Integrity/blob/main/explainer.md https://github.com/explainers-by-googlers/Web-Environment-In... and this was shot down by privacy advocates (for very good reasons). So basically the choice for website operators is either to fight the bots and accept that their service will be unusable for some subset of their users or not fight the bots, which will lead to their service becoming unusable for everyone. More and more, you see services pushing you very hard towards using their app and the reason is that with the app, they are able to actually verify that you are likely not a bot (or rather, in reality, that at least the app is running on an actual physical device, mobile phone bot farms are unfortunately also a thing). As for Cloudflare - they offer it as a service, so when the website operator has a choice between using them or allocating several engineers for bot-fighting, why would they not just go with Cloudflare? Doing it yourself can be slightly higher fidelity, as you know your customers better, but it is also a lot of effort which could be better spent elsewhere.

devops99 2y ago
Why "fight the bots" anyway? If software that is acting out the will of some humans somewhere is retrieving static contents, what's the big deal?
soerxpso 2y ago
> either to fight the bots and accept that their service will be unusable for some subset of their users or not fight the bots, which will lead to their service becoming unusable for everyone. 2/3 of the issues OP listed would not make the service unusable for anyone if the botcheck were removed. 1. What would be the problem with allowing "bots" to opt out of receiving marketing emails? Why do I need to be a human to tell you to stop spamming me? Who is running such a bot, for what purpose? 2. What would be the problem with allowing a "bot" to log in to an already-verified human account a single time? The only situations where you actually need to confirm that a user "looks human" is for repeated connection attempts in quick enough succession to matter (DDoS prevention), or when they want to do something that someone would actually write a nefarious bot to do (mainly just creating posts/messages visible to other users).
- Raed667 2y ago
  Just an idea, what if malicious bots started unsubscring thousands of email addresses to harm your business. Even if you send a confirmation email afterwords that's potentially millions of emails you are sending because of bots.
  - arielcostas 2y ago
    > what if malicious bots started unsubscring thousands of email addresses to harm your business. GP said: >> need to confirm that a user "looks human" is for repeated connection attempts in quick enough succession to matter (DDoS prevention) And even in that case, you could implement other solutions. For example, for unsubscription links, you could pass a "token" in the query string that "verifies" that it's the address' owner unsubscribing. You could generate such token either stateless (JWT, for example, then verify it) or store it somewhere along with the address.

devops99 2y ago

Why "fight the bots" anyway? If software that is acting out the will of some humans somewhere is retrieving static contents, what's the big deal?

soerxpso 2y ago

> either to fight the bots and accept that their service will be unusable for some subset of their users or not fight the bots, which will lead to their service becoming unusable for everyone. 2/3 of the issues OP listed would not make the service unusable for anyone if the botcheck were removed. 1. What would be the problem with allowing "bots" to opt out of receiving marketing emails? Why do I need to be a human to tell you to stop spamming me? Who is running such a bot, for what purpose? 2. What would be the problem with allowing a "bot" to log in to an already-verified human account a single time? The only situations where you actually need to confirm that a user "looks human" is for repeated connection attempts in quick enough succession to matter (DDoS prevention), or when they want to do something that someone would actually write a nefarious bot to do (mainly just creating posts/messages visible to other users).

Raed667 2y ago
Just an idea, what if malicious bots started unsubscring thousands of email addresses to harm your business. Even if you send a confirmation email afterwords that's potentially millions of emails you are sending because of bots.
- arielcostas 2y ago
  > what if malicious bots started unsubscring thousands of email addresses to harm your business. GP said: >> need to confirm that a user "looks human" is for repeated connection attempts in quick enough succession to matter (DDoS prevention) And even in that case, you could implement other solutions. For example, for unsubscription links, you could pass a "token" in the query string that "verifies" that it's the address' owner unsubscribing. You could generate such token either stateless (JWT, for example, then verify it) or store it somewhere along with the address.