[ SmokeDetector | MS ] Potentially bad ip for hostname in answer, potentially bad keyword in answer, potentially problematic ns configuration in answer, blacklisted user (74): Send newsletter by suncart on magento.SE
@Makyen That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body Append -force to the command if you really want to add this pattern.
@tripleee Indeed, and it's already caught one FP since watched in the last few hours. It seems to be a reasonably common function name. If there are more FPs soon, I'll unwatch this.
> Numbers-only title, potentially bad keyword in body, potentially bad keyword in title ---------- Numbers-only title - Position 0-15: +82-19-378-4105 Potentially bad keyword in body - +82-19-378-4105 found verbatim Potentially bad keyword in title - +82-19-378-4105 found verbatim
np. Note that if you really want to get the full results, you can strip out all the punctuation, and intersperse the digits with \W*+, and then simply do a regex search on MS. It's fairly annoying to do that though, so until someone automates that process, LIKE should be a reasonable enough approximation.
@cigien Sounds like a job for a userscript, although running regex on a regex always gives me headaches. JS does too and I'm not sure when I'll be ready for a double headache again :-)
@Mast @cigien I use the following bookmarklet to generate an MS search from the currently selected number watch text:
javascript:(function(){
/*The code to get the selected text on multiple platforms is from [this SO answer](stackoverflow.com/a/5379408) by Tim Down*/
var text = "";
const activeEl = document.activeElement;
const activeElTagName = activeEl ? activeEl.tagName.toLowerCase() : null;
if ((activeElTagName == "textarea" || activeElTagName == "input") && /^(?:text|textarea|search|password|tel|url)$/i.test(activeEl.type) && (typeof activeEl.selectionStart == "number")) {
text = activeEl.value.slice(activeEl.selectionStart, activeEl.selectionEnd);
It produces a reasonable approximation. It does not, however, handle some issues.
@Makyen I've updated this a bit to warn about number watches which are too long or too short. It will still search for them on MS, but you have to confirm that you want to continue.
Just FYI: I have a change to the number watch in process which will correct an issue about not testing all possible number lengths for perspective number sequences separated by non-digit characters, expand it a bit to allow for a little bit of the most common obfuscation, expand the possible exact matches, expand the range of digits which is considered a number, and both warn when an exact match isn't possible and not permit adding a number match which is impossible for the algorithm to match.
When that happens, the above bookmarklet will need to be updated.
@SmokeDetector @JeffSchaller That's the actual watch, which is 169 Total / 114 TP (67.46% TP) / 49 FP / 2 NAA, which is not awesome, but not all that bad.
The lookarounds are explicitly non-capture, so don't show up in what's detected. There's no (reasonable/performant) way to determine which regex matched and indicate that there are lookarounds.
np. It would make some situations easier for humans to immediately know which entries were matched. Unfortunately, there isn't a quick way to do it. The only way would be to run !!/bisect on each post that matched any watch/blacklist entry. !!/bisect is ... not quick (a few/several 10s of seconds per tested text). We just can't put that much SD CPU time into every detected post. It would be possible to back-fill, but then we'd really need another (or larger) compute resource.
We'd also have to pick a way to have MS store the information, as it's not something we'd want to have in the why data all the time (having it always visible would make it more difficult for a user to quickly see what was detected).
It might be something that could be added, or at least closely approximated, by a userscript. JavaScript has made improvements to its regex engine, so more regex entries are possible to run under native regexes, although it would be helpful to have a regex implementation which handled regex syntax a bit closer to PCRE, and, in particular, added variable length look-behinds.
Hmmm... an alternative would be to add a !!/bisect-post <MS postID> command, which would make it easier for users to test the actual post text and get a report of all matching watch/blacklist entries.
@cigien There's no point watching this. The only occurrences of this name in reported spam all contain the same spam domain, and with dozens of accounts with this username, we're not going to blacklist it anyway.
@Makyen That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body Append -force to the command if you really want to add this pattern.
