[:55209931] Blacklisted user - blacklisted for //politics.stackexchange.com/questions/56180 (https://metasmoke.erwaysoftware.com/post/257551) by the metasmoke API
@RyanM Messages/reports from SmokeDetector in Charcoal HQ are generally kept as records. If you really need to delete a message, please use sd delete-force. See this note on message deletion for more details.
That seems to have an awfully high FP rate, though I'm not sure how to check.
Third one I've seen in the past few days
Pasting the regex from the file into the MS search results in an error with a stack trace. I'm not going to link to that search because of the offensive language in the regex, but the regex is here for anyone who's wondering what on earth I'm talking about.
@MarcoBonelli Yes, it appears to be a bug. Opening an Issue on GitHub would probably be a good idea.
@RyanM You won't be able to link to the search in chat, because the URL is too long, by more than an order of magnitude (I get ~7255 characters for the URL). You'd have to use a URL shortener. :)
To get it to not generate an error, you need to eliminate the variable length negative look-behind, which you can approximate by using a moderate number of fixed length cases (i.e. replace it with a few fixed length negative look behinds). However, the regex is likely to take a considerable amount of time to run on MS (hmm.. it wasn't too bad, actually).
IIRC, the regex was initially developed to catch a particular troll, and has been updated with additional Trollish wording.
At this point, its primary benefit is to detect some posts which we don't otherwise detect. Out of the most recent 100 results, there are 2 TP which would not have otherwise been caught. I didn't check further.
As of the current time, it has: Results (3889), True positives (2313), False positives (1342), NAA (77), for about 59.48% TP. However, that's biased, as it contains data from prior to the regex being added to the watchlist.
@thesecretmaster I've remembered the other thing which would be really nice to have in MS search, which shouldn't be too difficult: being able to limit the search to only posts created/detected between to specified date/time marks, or just only posts created/detected after a specified date/time.
Having the ability to limit the results by date would allow us to do searches for things like the above watch, but only include those which were detected after the watch existed. That could provide a significantly better metric of how well the regex is doing.
[ SmokeDetector | MS ] Bad ip for hostname in body, bad keyword in body, bad keyword in title, blacklisted website in body, link at end of body, +3 more (589): Free Cell Keto Free Cell Keto by welkerDolee on superuser.com
Mysql2::Error: syntax error, unexpected '@', expecting $end: SELECT COUNT(*) AS count_all, `posts`.`is_tp` AS posts_is_tp, `posts`.`is_fp` AS posts_is_fp, `posts`.`is_naa` AS posts_is_naa FROM `posts` WHERE (MATCH (`posts`.`body`) AGAINST ('%oscarwhitehackersworld@gmail.com%' IN BOOLEAN MODE)) GROUP BY `posts`.`is_tp`, `posts`.`is_fp`, `posts`.`is_naa`
[ SmokeDetector | MS ] Blacklisted website in body, potentially bad ip for hostname in body, potentially bad keyword in body, blacklisted user (172): What is QMS Certification? by Iso KUWAIT on mathoverflow.net
Well, I have a bias towards using regexes, so I'm not really the right person to consult on what might be useful to other people. As I understand it, clicking the LIKE checkbox was making them operate as expected.
@SmokeDetector Is there a significant performance gain from making those \W*'s greedy? Or is the regex engine smart enough to know \W* followed by a \w is always going to be greedy?
@NobodyNada There is a performance gain, but I haven't quantified it with this regex engine, and it, of course, depends on the input. In general, it's not something that a regex engine special cases all that thoroughly, but some do cover the case automatically.
@Mast Try it out with some test data on regex101 with PCRE selected and see how many steps it reports and how much time it takes. If it's really bad (as in catastrophically bad), then it should fail CI testing.
@JohnDvorak Unspecified, but I'd assume that it would be the number of evaluation steps the PCRE regex engine has to take to evaluate the regex against the test data you've provided.
At best, it will be a rough evaluation. If you want to get a better feel for what a particular regex costs, you can try your regex against the test data we use for CI testing using the actual regex engine. However, that's really a limited subset of possible input data.
@JohnDvorak Not necessarily. As the simplest case, consider .{600}, which requires zero steps to confirm that it does not match a 500-character string.
(or theoretically could, I haven't tested that...)
@NobodyNada I would just like the search to find posts which contain the string without fiddling, I try to avoid regex when I can but it seems pointless when the regular search is so erratic
@user12986714 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.
What are we supposed to do with that Anthony fellow? This user is a known troll. Posts absolutely uninformed questions about all kinds of topics, half the time offensive. The offensive ones can be flagged as such, but a lot of them really aren't obvious. Metasmoke search
[ SmokeDetector | MS ] Bad ip for hostname in body, bad keyword in body, blacklisted website in body, pattern-matching product name in body, potentially bad ns for domain in body, +1 more (394): It Furthermore Fabricates Mass by zora bailey on astronomy.SE
