3 ms·

a spammer can automate the spamming via tools like autohotkeys, rather than modding a client. It's slightly more resource intensive, but not by much imho. Prev

by chii 4y ago

a spammer can automate the spamming via tools like autohotkeys, rather than modding a client. It's slightly more resource intensive, but not by much imho. Preventing spam is more a task for server-side detection and filtering. Gmail's been doing it very well for decades, and i can't see why similar methods won't work for messaging. And adding a rate-limit server-side is another defence. The least useful option of banning modded clients for chats is a bad trade-off for most users whilst providing very little actual protection.

mike_hearn 4y ago
Stuff like AutoHotKeys is far slower than a multi-threaded bot driving the protocol directly, and spam is all about speed/volume, so in practice if spammers are reduced to that it's a big win. Gmail actually does rely on various forms of "anti cheat" to control spam, including obfuscated code that detects attempts to automate the browser. That doesn't help for inbound mail but it helps a lot to stop people sending spam from Gmail.
- chii 4y ago
  > Stuff like AutoHotKeys is far slower than a multi-threaded bot driving the protocol directly Not by an order of magnitude, esp, for chat applications that are limited by http application protocols. > ..that detects attempts to automate the browser. Nobody sends spam from the gmail web browser client, but suppose google successfully bans (somehow?) all other email clients, the enterprising spam sending people would still easily automate the browser, esp. with things like autohotkeys (which doesn't require modifying the browser itself, nor run code in the browser). The point is, banning a client side mod for any service is irrational if the justification is to prevent spammers.
  - mike_hearn 4y ago
    I used to work on Gmail anti-spam. Blocking attempts to send spam through the browser UI was most of our job. Driving browsers by things like AHK is (a) detectable and (b) definitely slower by more than an order of magnitude! You can much more easily run many requests in parallel (through proxies) within the RAM budgets of ordinary desktop/laptop computers, when going direct to the network. You don't have to believe me, go read spammer forums to see people discuss how much better multi-threaded bots are. "the enterprising spam sending people would still easily automate the browser, esp. with things like autohotkeys" It's not at all easy for them, and people who try approaches as simple as that don't make any money. Or didn't when I worked on it at least. "The point is, banning a client side mod for any service is irrational if the justification is to prevent spammers." That belief is widespread, but I built a part of my career on proving it wrong. We got unexpectedly excellent results from cracking down on alternative clients that were pretending to be browsers.

by chii 4y ago

mike_hearn 4y ago

Stuff like AutoHotKeys is far slower than a multi-threaded bot driving the protocol directly, and spam is all about speed/volume, so in practice if spammers are reduced to that it's a big win. Gmail actually does rely on various forms of "anti cheat" to control spam, including obfuscated code that detects attempts to automate the browser. That doesn't help for inbound mail but it helps a lot to stop people sending spam from Gmail.

chii 4y ago
> Stuff like AutoHotKeys is far slower than a multi-threaded bot driving the protocol directly Not by an order of magnitude, esp, for chat applications that are limited by http application protocols. > ..that detects attempts to automate the browser. Nobody sends spam from the gmail web browser client, but suppose google successfully bans (somehow?) all other email clients, the enterprising spam sending people would still easily automate the browser, esp. with things like autohotkeys (which doesn't require modifying the browser itself, nor run code in the browser). The point is, banning a client side mod for any service is irrational if the justification is to prevent spammers.
- mike_hearn 4y ago
  I used to work on Gmail anti-spam. Blocking attempts to send spam through the browser UI was most of our job. Driving browsers by things like AHK is (a) detectable and (b) definitely slower by more than an order of magnitude! You can much more easily run many requests in parallel (through proxies) within the RAM budgets of ordinary desktop/laptop computers, when going direct to the network. You don't have to believe me, go read spammer forums to see people discuss how much better multi-threaded bots are. "the enterprising spam sending people would still easily automate the browser, esp. with things like autohotkeys" It's not at all easy for them, and people who try approaches as simple as that don't make any money. Or didn't when I worked on it at least. "The point is, banning a client side mod for any service is irrational if the justification is to prevent spammers." That belief is widespread, but I built a part of my career on proving it wrong. We got unexpectedly excellent results from cracking down on alternative clients that were pretending to be browsers.