[ SmokeDetector | MS ] Bad keyword in answer, bad keyword with email in answer, bad phone number in answer, pattern-matching email in answer, potentially bad keyword in answer, +1 more (439): California Freemason Records by Derrick Brian on genealogy.SE
[ SmokeDetector | MS ] Bad ip for hostname in body, blacklisted website in body, link at end of body, pattern-matching product name in body, pattern-matching product name in title, +1 more (592): Puri Skin Tone Cream Puri Skin Tone Cream by lepeldokse on superuser.com
[ SmokeDetector | MS ] Bad keyword with a link in answer, blacklisted username, blacklisted website in answer, potentially bad ip for hostname in answer, potentially bad keyword in answer, +1 more (327): How does weblogic clustering work? by svrtechnologies on stackoverflow.com
@tripleee That pattern looks like it's already caught by Blacklisted website in body and Blacklisted website in answer; append -force if you really want to do that.
[ SmokeDetector | MS ] Blacklisted website in body, link at beginning of body, potentially bad ip for hostname in body, potentially bad ns for domain in body, potentially bad keyword in body (144): What is ISO 27001 Certification? by Iso KUWAIT on meta.SE
@tripleee 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.
@Mast 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.
@SmokeDetector Translation (roughly): "Hello everyone, I am doing this testimony because of my happiness today, my name is Lillian, I have been married for more than ten years I left happy with my beautiful husband, until one day he" etcetera.
@SmokeDetector Looks unrelated but I'm not an SME. Hard to make heads or tails of it. On further reflection, it resembles a much worse version of the other answers.
@tripleee That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer; append -force if you really want to do that.
@Mast 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.
Matched by the following regexes: (?:contact|offer|join)(?<=^.{0,207}).{0,99}?\d{9}(?=.{0,99}+$) on line 18992 of watched_keywords.txt money\sritual on line 22454 of watched_keywords.txt
@tripleee Kinda suspect that wapcar was the spam there and the other two were for plausible deniability. I doubt carmax, yahoo autos, and some random website I've never heard of all decided to split the cost of hiring the same spammer.
@SmokeDetector fp- Not clear, might just be VLQ/bad English...inclined to give benefit of the doubt here. "Farm" sounds like a mistranslation of "community," e.g., the CPAN Testers community.
@RyanM the comment by the OP seems to imply that they are in cahoots with the troll who answered, I'm guessing they are just sock puppets of each other
[ SmokeDetector | MS ] Bad keyword in body, bad keyword in title, pattern-matching product name in body, pattern-matching product name in title, potentially bad keyword in body (392): What is Ketogenix Keto Diet? by Ketogenixksks on meta.SE
> Potentially bad keyword in body - Position 139-432: a>, seems like stm32 boot process is as follows:</p><ol><li>Check if FLASH is blank. if yes, goto bootloader mode</li><li>Check if BOOT0 pin is asserted. if yes, goto bootloader mode</li><li>goto Program mode</li></ol><p>My problem is the first condition on first boot.</p><p>when i buy
sdc bisect a>, seems like stm32 boot process is as follows:</p><ol><li>Check if FLASH is blank. if yes, goto bootloader mode</li><li>Check if BOOT0 pin is asserted. if yes, goto bootloader mode</li><li>goto Program mode</li></ol><p>My problem is the first condition on first boot.</p><p>when i buy
@Daniil ' a>, seems like stm32 boot process is as follows:</p><ol><li>Check if FLASH is blank. if yes, goto bootloader mode</li><li>Check if BOOT0 pin is asserted. if yes, goto bootloader mode</li><li>goto Program mode</li></ol><p>My problem is the first condition on first boot.</p><p>when i buy' is not caught by a blacklist or watchlist item.
[ SmokeDetector | MS ] Bad ip for hostname in answer, bad keyword in answer, blacklisted website in answer, link at beginning of answer, potentially bad asn for hostname in answer, +2 more (312): Double Hash Family Universality by pabowini on cs.SE
[ SmokeDetector | MS ] Pattern-matching website in answer, potentially bad ns for domain in answer, potentially problematic ns configuration in answer (80): SIM800L can't send SMS by محمد رحیمی on arduino.SE
[ SmokeDetector | MS ] Bad keyword in body, bad keyword in link text in body, bad keyword in title, pattern-matching product name in body, potentially bad keyword in body (361): How Does Prime TRT Work? by trtprimee on meta.SE
@RyanM You have to feed enough of the post into the !!/bisect to match the regex. Sometimes, regexes depend on more than just what is captured. For that particular one, it's a common one for people to be wanting to know what triggered the detection. I also wrote it, so I'm reasonably familiar with it and what its captures look like, even if it was in 2018. That one has a fairly distinct pattern to what it detects, which is described in the regex comment:
(?#buy before, in, or after a link within 400 characters without code; when watched, was 3077/2878/194/14 minus 12/2/10/0: 2018-12-14T21:43Z, or so)
regexes with a fair amount of wildcards are confusing either way; if you capture everything you matched, it's hard to tell from the captured text why it triggered; if you only capture the actual keyword, it's confusing when you try to !!/bisect the reported keyword without the context required by the regex
@RyanM it was implemented once and considered to be too much of a burden because the overhead was nontrivial
perhaps now our regexes are slightly better groomed so if somebody wants to take another look, it's not like we think it's a bad idea; but actually I'm afraid the conclusion might still be that we don't want to slow down Smokey for marginal usability gains
@RyanM That would effectively require running !!/bisect on every single post which was detected for one of the watch or blacklist reasons. Doing so would be a lot of extra processing for something that isn't, currently, used 90%+ of the time. It's also unclear how you'd want to store that information. Do you store the actual regex? the line number in the file? Storing the actual regex might be considerable extra data per report.
Storing the line number would require reconstructing what the file looked like at each point in time, so probably that way isn't all that helpful.
OTOH, storing the regex would allow assigning a weight based on the actual %TP of the regex that detected the post, but doing that is a considerable amount of additional processing, and it would include processing that would, under current designs, be taking place right where we don't want to really be having that extra processing taking place (i.e. in the autoflagging path, for every detected post).
So, the performance optimization is the existence of the blacklists and watchlists, instead of just "a list", where everything on the list has its own weight.
