[ SmokeDetector | MS ] Few unique characters in body, no whitespace in body, no whitespace in title, repeating characters in body, repeating characters in title (396): xxxxxxxxxxxxxxxxxxxxx ✏️ by Jiker on stackoverflow.com
[ SmokeDetector | MS ] Blacklisted username, misleading link, pattern-matching website in answer, potentially bad keyword in answer, potentially bad keyword in username (193): Ubuntu 18.04 UFW setup by Wesley Atwood on askubuntu.com
Experimental reasons - such as potentially bad keyword - usually have a locked weight (1 or 0), and aren't reported in rooms that have experimental reports turned off if it's the only reason on that report.
If it's weight locked at 0 for now it should be marked as experimental - especially while it's so new (under a month, looks like).
[ SmokeDetector | MS ] Few unique characters in body, mostly punctuation marks in title, no whitespace in body, potentially bad keyword in body, repeating characters in body, +1 more (354): -------------------- ✏️ by paxito on stackoverflow.com
Yeah the answer seemed only tangentially related to the question, so I threw a blurb of it into google and the top result was that article. It's a semi-common tactic. Any time you see "Username similar to website in answer" you should be looking for some dubious stuff.
@Mithical @Mast Experimental reasons are locked at 1. Reasons which are not explicitly marked as experimental are held at 0 until they accumulate 20 detections. After 20 detections, their weight reflects the historical accuracy of the detection. That's our normal process for "new" detections.
While this particular detection being under it's own name is new, it's not a new detection. The "scam aimed at customers in {}" detection has actually been around since 2015. Throughout the vast majority of that time, it was placed under "bad keyword in", with just a different indication in the why data.
However, its historical accuracy is ~34%, which is dramatically different from what our target is for "bad keyword in". Due to this substantial difference, I split it out into its own named detection, so that the actual weight which is justified by its historical accuracy would be applied, rather than the ~90 weight which it was getting by being under "bad keyword in". The PR doing that was PR #5087.
That PR also moved the "customer support phrase in" detection, which had also been under "bad keyword in", under "potentially bad keyword in", as once the duplicate detections with existing "bad keyword in" regexes were removed, it just didn't have the volume of detections to justify its own detection.
At the same time, I also split out the "health-themed spam in" detection, which had also been included in "bad keyword in". That was done in PR #5086. The "health-themed spam in" detection has a much higher %TP of 98.83%, which was a much better match to "bad keyword in". However, it's significantly different from what "bad keyword in" is primarily doing, so I preferred seeing it as its own detection.
[ SmokeDetector | MS ] Few unique characters in answer, no whitespace in answer, potentially bad keyword in answer, repeating characters in answer (264): Show then Hide in Pygame by THE DEAD DUDE on stackoverflow.com
