[ SmokeDetector | MS ] Link at end of answer, potentially bad ns for domain in answer, potentially bad keyword in answer, blacklisted user (134): Recursively saving web pages by Joyjoy on superuser.com
@Yatin That pattern looks like it's already caught by Bad keyword in body, Blacklisted website in answer, Bad keyword in answer, and Blacklisted website in body; append -force if you really want to do that.
[ SmokeDetector | MS ] Bad keyword in body, bad keyword in title, pattern-matching product name in body, potentially bad keyword in body (292): Happy Dance CBD Oil by KieraBreke on apple.SE
@Yatin Actually, I'm looking at the transcript, and there have been similar watches, so maybe that's ok. I'm not entirely sure, so I won't approve it, but go ahead and make the PR, and someone else will take a look at it.
Matched by the following regexes: keto[\W_]*+body(?!tone\.com(?<=keto-bodytone\.com))(?!toneofficial\.com(?<=ketobodytoneofficial\.com))(?!toneofficielfrance(?<=facebook\.com/ketobodytoneofficielfrance))(?!toneofficialpage(?<=facebook\.com/ketobodytoneofficialpage))(?!toneusa(?<=sites\.google\.com/site/ketobodytoneusa))(?!toneofficialfrance\.tumblr\.com(?<=ketobodytoneofficialfrance\.tumblr\.com))(?:[\W_]*+(?:tone|avis|france|fr|web|review|offici[ae]l|page|usa|pill|\d++|[\da-f]{4,}+)s?)* on line 1963 of bad_keywords.txt
@Yatin Regarding this PR, note the above message suggesting this is already caught. Is there a reason why you are proposing to watch this again/specifically?
@cigien I watched individual ones for quite a while. Eventually, I just gave up due to there being soooooo many and relied on the blacklist of the various second level domain (e.g. webself.net in this case) and getting a keyword match on the subdomain as a secondary effect of using the more involved pattern for combinations of the product name and associated words and numbers (which is really there to pick up domains and URL path fragments which are not otherwise caught).
Do we have a policy on the merits of adding watches for things already caught by other watches? I would think that it's almost certainly pointless, except perhaps if you were planning to add a targeted watch for a specific thing that could later become a blacklist item.
The problem is, would you even be able to determine whether that watch or the other more general watch was responsible for catching posts when deciding whether to elevate it to a blacklist?
@Yatin 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 I think I understand. The second level domain catches most things, but specific domain watches are fine so long as they don't duplicate other watches of course. That seems to match up with what I'm seeing in the history. Thanks.
@Yatin 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.
@double-beep Thanks for pointing it out. It's been resolved. The apparent reason GitHub decided to stop running GitHub Actions was that it was having problems communicating to the email address for SmokeDetector. However, the email address was working. The address has been re-verified with GitHub and we've substantially reduced the emails which GitHub should be sending to SmokeDetector, which should help to alleviate any intermittent issues causing future problems.
@Yatin I'm not actually on Teams, but I had meant to join about 2 weeks ago, so thanks for the reminder :) I'm not too sure about making a post about it, because I'm not confident I would be able to give general guidance on these cases, nor provide justification for that. I'll look into this a little more, and if/when I feel comfortable that I know exactly why those watches are ok, and in which cases they aren't, I'll make a post for sure.
[ SmokeDetector | MS ] Bad ip for hostname in body, bad keyword in body, bad keyword in title, blacklisted website in body, body starts with title and ends in url, +7 more (1023): MariCanna RX CBD Oil by piperbrackin on astronomy.SE
@Makyen I've never seen you or anyone do that before: swapping the alternations to avoid having to force the watch. Is there a benefit to doing that? Or is there some other reason than to avoid the force?
@cigien I've done it many times. I generally do it when I know what will trigger SD to complain about it also being detected by some other watch. It's my preference because it's a better verification that I know why SD is complaining, rather than just overriding the warning from SD with -force. If I just override with -force then it overrides everything, which may include something I'm not aware of, or not actually wanting to override.
Making the change to the regex to prevent matching by the thing(s) I know about is something of a shortcut to a more detailed investigation as to what is really causing the complaint, or prevents making the assumption that what I think I know is the problem really is the problem.
Usually, I'll remember to make the adjustment without being reminded to do so by a complaint from SD, so most/many times of my previously doing so would not have had the attention drawn to it of SD first complaining.
@CodyGray Yes, the regexes are equivalent as to what they will match. The advantage is that I don't, and anyone manipulating the entry in the future doesn't, need to use -force. Using -force prevents SD from running checks. Using it implies that you know exactly why SD was complaining about the regex, and doesn't allow SD to check for things that you might not be thinking about.
If I adjust the regex in a way that keeps it equivalent, but won't trigger SD's checks for the things that I do know about, then the checks will still be run and be able to tell me about any issues which I'm not thinking about, which is what the automatic checks are there to do. Obviously, it's not possible to do this all the time, or at least not easy. But, if it's an easy change, then it's probably a better option.
@Makyen That's fascinating. I really like the idea of verifying I know what I'm doing, and this seems to be a very nice example of that. I'll be sure to try that out next chance I get. Thanks for the explanation.
Yeah, I wouldn't have noticed what you'd done if you did that without SD reminding you. If you did have to edit it and didn't add force I would probably have noticed, since I don't expect you to make typos. Anyway, I don't read all the regex watches you make, though I try to, so I might have just missed it.
@CodyGray The primary reason to add regexes like the above is that spammers tend to like to make mash-ups using the words for their product. For example, the above regex will catch something like "maricannarxcbdoil.com", which the regex which I was avoiding, the one that catches "cbd oil" on its own, will not. Adding the regex also has the effect of putting the product name in the why data, which helps when humans are looking at it.
So... the two regexes weren't identical in what they would catch?
Chat not having a proper diff function, I was just relying on my poor eyeballing skills, and combined with my limited regex knowledge, that may have led me astray.
@CodyGray The two regexes in the different versions of my message will catch the same things. Both will catch some text which will have as a sub-portion the text "cbd oil", which is also caught by a blacklist entry. The second version of mine, after being processed by SD into something to test, will not contain "cbd oil", so won't be caught by the blacklist which looks for that text, because that blacklist doesn't check for "oil cbd".
