@Makyen That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body; append -force if you really want to do that.
@Makyen This detects the username too, which, IMO, is going a bit too far with only 1 (now 2) detections from a user with that username, and the posts are at least somewhat on-topic (i.e. they are about a Woocommerce plugin). While I agree that it's quite likely a post by that username is going to be promoting their plugin, detecting the username should be something we do when there's a pattern of using the same username on multiple accounts/sites, or if there's a longer history of spam.
@ArtOfCode thank you very much. You guys do such a great service all the time, and at times like this, I'm so glad to know your protection is in place.
@Makyen In case you're not aware, prefer watching numbers with the leading plus sign if it appears. The RegEx for extracting numbers tries to match a leading plus sign:
Post - Username `Whatsapp For Ecommerce` similar to *watsappforecommerce* at position 19-38, ratio=0.9743589743589743 Username - Position 0-22: Whatsapp For Ecommerce Blacklisted user - blacklisted for //stackoverflow.com/a/52858261 (https://metasmoke.erwaysoftware.com/post/139667) by the metasmoke API
@iBug A) The !!/watch-number which you are probably looking at was for a post which contained the number in 3 different formats, thus the "normalized" match is the most likely. B) Testing indicated that it detected it normalized either way. The same detection reason is reported for detection where verbatim or normalized.
Thus, the only reasons to try for a verbatim match is either a performance benefit, or users perceiving a higher value in a verbatim vs. a normalized match in the "why" info (which is a debatable benefit). The overall performance difference if having to test normalized is negligible, as all cases are tested for a non-detection. Thus, I don't really see it as that desirable to try to pick a version that will obtain a verbatim match (and certainly not in the case you're likely looking at).
In addition, I don't really see the desirability of having + characters in the actual test. We should permit them in the list, as it's likely users will copy them anyway. Personally, I would have chosen to strip them from the list of detections prior to using them for the detection.
Basically, yes. :-) However, in that particular case, I really didn't see any benefit of trying for a verbatim match, given the three different formats used in the post.
[ SmokeDetector | MS ] Url-only title, blacklisted website in body, blacklisted website in title, body starts with title and ends in url, link at end of body, +5 more (794): nutritionless.com/veda-soothie/ by Fukopumu on askubuntu.com
@SmokeDetector This has been edited during the grace period, and after the grace period, into an answer. So, while what was detected by SD is NAA, it's not currently something that should be flagged.
[ SmokeDetector | MS ] Url in title, bad keyword in body, blacklisted website in body, blacklisted website in title, body starts with title and ends in url, +6 more (888): nutritionless.com/veda-soothie/ by Fukopumu on drupal.SE
[ SmokeDetector | MS ] Blacklisted website in body, link at end of body, pattern-matching website in body, potentially bad ns for domain in body, potentially bad keyword in body, +1 more (398): Record Your Daily Nutrient Intake by user886966 on askubuntu.com
@iBug IMO, doubling up on blacklist reasons for identical detections is wrong, unless we are specifically targeting something due to an excessive wave of ongoing spam/R/A (and it should be only temporary; removed when the wave passes).
I'm aware that one is actually a pattern. As I've said several times: IMO, that pattern should be moved into a pattern match reason, not the blacklist. However, at least the last time I checked, it was maintaining a good enough TP/FP rate to match what we expect to see on the blacklist.
Sorry for raising this up weeks later, because I just checked my flag logs today.
My spam flag on this answer was
declined - a moderator reviewed your flag, but found no evidence to support it
(Note: Post is already deleted and user nuked)
According to metasmoke, the post content was:
...
@iBug Is there a particular reason you used spam on that as opposed to R/A? Although they're pretty much the same at the end of the day from the point of view of their effect he's got a point it's not really spam.
@iBug I wondered if that was the case, but you might be better adding that to the question - at the moment it sounds like you manually did it plus many people including mods probably aren't familiar with FIRE.
While this specific instance may have been the lack of functionality in FIRE (the ability can be there at this point, I need to merge it and push it out), the larger issue, IMO, is that SmokeDetector/metasmoke only casts spam flags, it does not cast R/A flags. Thus, there are going to be spam flags cast on R/A posts whenever they are autoflagged.
[ SmokeDetector | MS ] Url-only title, bad keyword in body, bad keyword in title, blacklisted website in body, blacklisted website in title, +6 more (889): nutritionless.com/veda-soothie/ by Muig on askubuntu.com
[ SmokeDetector | MS ] Bad keyword in body, link following arrow in body, pattern-matching product name in body, pattern-matching website in body, potentially bad keyword in body, +1 more (394): where to buy Keto Supply Australia by stevwright on stackoverflow.com
@SmokeDetector User has rolled-back to the vandalized version and continues to post multiple inappropriate comments. I've custom mod-flagged the question and R/A flagged the answer along with multiple comments.
@SmokeDetector The user self-deleted the question.
@SmokeDetector And then undeleted it and rolled it back to the vandalized version.
Sorry for raising this up weeks later, because I just checked my flag logs today.
My spam flag on this answer was
declined - a moderator reviewed your flag, but found no evidence to support it
(Note: Post is already deleted and user nuked)
According to metasmoke, the post content was:
...
