28

Recently, spammers on WordPress Development discovered a "new" trick - the grace period. They post a spam post without the link and immediately edit it in.

Yesterday, I happened to spot yet another occurrence of this trick, and reacted quickly to insert a comment that gracefully broke their trick, which resulted in the following scene (click to enlarge):

The original version of the post can be found on metasmoke.

The problem is, while the late-edit wouldn't change the outcome of the post when it's reviewed by humans, it does result in taking longer to delete the spam post (sometimes as unnecessarily long as hours) by preventing the post from being autoflagged, or other automated measures meant to nuke spam faster.

What's worse, it's a clear sign that big-time spammers are experimenting, trying to get around any spam filters on Stack Exchange, be they official or community-maintained. I think we here at Stack Exchange should always stay one step ahead of our rivals.

If I were to say, I'd suggest that an edit shouldn't be considered "in grace period" if it meets certain criteria. Examples of edits that should break the grace period would be adding an extra link, or when the majority of the title or the body has changed (which will also effectively address this declined feature request).

Or maybe just send the post to the realtime tab (155-questions-active) whenever it's edited, be it in grace period or not?


Fun fact: the broken grace period earned that spammer a badge.

  • 5
    Breaking the grace period really isn't required. IMO, a better solution would be for the automated tools to recheck the post when there's a grace period edit, just like any other edit. Ideally, there would be a feed which provides, at least, notification that a post was edited during the grace period. The lack of such feed is the real problem, IMO. The alternative from the automated tool's POV is to recheck every post after the 5 minute grace period. However, rechecking everything after 5 minutes doubles API accesses and results in spam exiting minutes longer than with immediate checking. – Makyen Jan 16 at 7:03
  • 2
    See also meta.stackexchange.com/questions/307637/… for a specific idea along these lines. – Nathan Tuggy Jan 16 at 7:40
  • 6
    Speaking as a mod on WordPress.se, this problem is quite urgent. We are overrun by spam at the moment. – fuxia Jan 17 at 9:33
  • The fix for the non-SE automated scripts that check for spam or other abusive behavior should check once on initial post, and again at the end of the grace period. That then allows you to catch any grace period edits without requiring SE to expose information about when a grace period edit happens in the API. SE could of course adjust their internal spam detection scripts to re-check on any grace period edit. – Servy Jan 17 at 15:31
  • @Servy While that would work, the problems with that approach is that it (about) doubles the number of requests to the SE API needed to obtain the data, and increases the time from the spam being visible to when it's detected from seconds to minutes. SmokeDetector (SD) is the main consumer of the data that we're talking about. SD routinely uses 12,000 to 16,000 SE API requests every day. Re-requesting every post would increase that to 24,000 to 32,000 SE API requests/day. Some optimizations could be done for that, but most such (e.g. deeper queues) would increase detection delay further. – Makyen Jan 17 at 19:00

You must log in to answer this question.

Browse other questions tagged .