4 ms·
> 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
by 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 agoJust 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.