@Makyen There are multiple possible things this still might match, which we don't want to match. Given that the goal was to watch a specific domain, it's better to watch the actual domain. Alternately, we could use something that excluded even more possible things we don't want to match: e.g. support\W*office(?<![. "]office)\.com
Hmmm... That's the pattern matching bad number which we have in the bad keyword file. IMO, it would be nice to move that out into a different detection, given that it's really a relatively broad pattern 234\W*[89][01]\d\W*\d{3}\W*\d{4,10}, instead of specific numbers that have been caught. IIRC it's TP/FP rate was in the ballpark for a bad keyword, but I can't double check that at the moment, due to regex searches on MS not working.
[ SmokeDetector | MS ] Bad keyword in body, blacklisted website in body, pattern-matching product name in body, pattern-matching website in body, repeated url at end of long post (493): It is challenging to get thinner by user10501498 on stackoverflow.com
[ SmokeDetector | MS ] Bad keyword in body, bad pattern in url body, blacklisted website in body, body starts with title and ends in url, potentially bad keyword in body, +1 more (489): excessive amount by Viwxlaoh on codereview.SE
@gparyani That pattern looks like it's already caught by Blacklisted website in answer, Pattern-matching website in body, Pattern-matching website in answer, and Blacklisted website in body; append -force if you really want to do that.
@makyen Since you recently fixed a lot of fire bugs, could you take a look at this bug: chat.stackexchange.com/transcript/message/38471269#38471269 Fire seems to access the toastr object before its loaded, it only happens like 25% of the time, and so far I can only reproduce it if I just start google chrome, and have the charcoal HQ as my homepage (my default setup) but when it happens, its really annoying as you don't get any feedback from fire. I am on Google Chrome 69.0.3497.100 now
@SmokeDetector marked the post as spam because it was linking with a referalcode/dummy domain to a shady website not following the GDPR and was looking shady
@Ferrybig Sure. Thanks for bringing it to my attention. I wasn't aware of it as an issue. I must admit that I've never encountered it as an issue. However, changing how those dependencies were loaded as one of the first things I did on my personal copy, which would have masked the issue. At the time, changing that was mostly a philosophical difference on my part as to how to load required resources in userscripts, not because I'd experienced any actual error.
Given that there's an actual problem, rather than just a difference of opinion about implementation, I'll add that to the changes I merge.
[ SmokeDetector | MS ] Body starts with title and ends in url, link at end of body, pattern-matching website in body, potentially bad ns for domain in body, potentially bad keyword in body, +1 more (297): Niwali Keto or guarana (its chemical by StosePople on askubuntu.com
@tripleee That pattern looks like it's already caught by Pattern-matching website in body and Pattern-matching website in answer; append -force if you really want to do that.
^ having your web site hosted by Namecheap's web servers is quite distinct from having your DNS on their nameservers, though this feels slightly like doubling down again; on the other hand, again, the evidence is quite compelling chat.stackexchange.com/search?q=as+22612&room=65945
Keeping the old design negates all of the benefits of creating the new design for SE. There's no way they'll support that; if you want to keep the old design, it'll have to be a userscript/userstyle.
it's per host, not per domain; you could have www.example net and mail.example.net on different hosts, and thus also at least in theory in different ASNs
though in practice of course most legitimate sites want all their eggs in one convenient basket on a single bill etc
(you also have to have a Smokey key to be able to create domains in the first place, so if there is anything it's restricted to runners and traceable to who did it via the key)
maybe check that it works correctly with hosts with multiple IPs; they could also be in multiple ASes (google.com is a good example, though it's probably additionally behind regional load balancing, so you get entirely different lookup results in different regions)
@Makyen That pattern looks like it's already caught by Potentially bad asn for hostname in answer and Potentially bad asn for hostname in body; append -force if you really want to do that.
@Glorfindel That pattern looks like it's already caught by Potentially bad asn for hostname in answer and Potentially bad asn for hostname in body; append -force if you really want to do that.
@Makyen That pattern looks like it's already caught by Potentially bad keyword in answer, Potentially bad keyword in body, Bad keyword in body, and Bad keyword in answer; append -force if you really want to do that.
@Makyen Hmm... Looks like we're already watching \W*콜걸\W* and 콜걸. The former wouldn't match, because it's assuming that \W* is using the non-Unicode definition of \W (known issue). The latter, 콜걸 by itself, appears to be assuming that the use of the WORD flag results in a (?w:\b) match as the bookends. Given that it didn't match, that is not the case. (Just FYI: @iBug)
[ SmokeDetector | MS ] Bad keyword in body, bad keyword in title, bad keyword with email in body, email in body, pattern-matching email in body (368): Do you need a loan? by Damond Stefan on money.SE
