Ben HalpernIf you've been around DEV for the last few days, we apologize for the feed having too much spam.
The spam fight is an ongoing battle for any platform like ours, and it's something we always need to improve on, especially as we propagate our open source code into the universe via Forem more and more.
We have had several spam mitigation efforts in place, but they're only as good as the patterns we're preventing, and this bout with spammers is providing us with opportunities to really close the loop on some of the big outstanding issues.
The biggest problem with our current spam tactics is... observability... We have functionality in place, but it's a little burried and hard for us to get a sense of what is going on. So our improvements need to be steeped in allowing us to identify when spammy tactics are occurring so we can adjust our code.
Fighting spam is a multifaceted issue that touches rate limiting, user experience for early users, balancing concerns over false negatives vs false positives, etc.
Patterns
A quality of spam is that it usually easy to spot patterns... That is because for spam needs scale to be effective, as well as a particular outcome in mind.... Totally chaotic spam does not have the same incentives as precise spam.... Though chaos is also worth fighting.
We already fight off certain patterns, but we need to do more of that, and we need the actions to be as observable as possible. Currently we just don't raise the issue enough to the people involved and it's hard to be aggressive when you're treating things as too much of a black box.
Add ability for admin to add anti-spam terms
#10615
What type of PR is this? (check all applicable)
- [ ] Refactor
- [x] Feature
- [ ] Bug Fix
- [ ] Optimization
- [ ] Documentation Update
Description
This adds the ability for admins to modify a list of terms which may indicate spam. But unlike past "quiet" spam indicators, this automatically creates a vomit reaction which an admin can later manually reverse or at least be aware of. In the past we have modified spam-related scores but it hasn't really worked effectively into our workflows. I think this reversible action should be how we raise spam automatically in general.
With comments I decided to limit it to newer accounts because we're examining the whole comment and not just the title. But this can be modified over time. If a support admin is seeing false positives with a term they should consider removing those. We can alter the logic over time to ensure as few false-positive scenarios as possible.
This is the start of a pattern-based spam prevention approach that raises the issue to human mods. This will get more sophisticated over time. It will pair with more adjustments to rate limiting and onboarding.
Further adjustments to the feed are also forthcoming, to ensure that even if there is spam, it affects fewer users directly.
As an open source company we look forward to squashing these issues in the open and sharing all of our learnings going forward.
Happy coding ❤️
