[:61784703] Registered answer as true positive and blacklisted user. [:61784702] Registered answer as true positive and blacklisted user. [:61784699] Registered answer as true positive and blacklisted user. [:61784698] Registered answer as true positive and blacklisted user. [:61784696] Registered answer as true positive and blacklisted user. [:61784695] Registered answer as true positive and blacklisted user. [:61784693] Registered answer as true positive and blacklisted user. [:61784691] Registered answer as true positive and blacklisted user.
@forest Just in case you're not aware, you can give feedback to a bunch of SD messages quickly like that. IIRC you have to skip log messages, so check out the Wiki page if you want github.com/Charcoal-SE/SmokeDetector/wiki/…
@Makyen Thanks. I did try searching the transcript for "contact", but... that resulted in more false-positives than I cared to look through. :-) I trust that if it's an experimental watch you recently added, you'll be fairly good about staying on top of checking the FP rate, and, more importantly, its success at detecting what wouldn't otherwise be caught.
@SmokeDetector tpu- This is just meaningless gibberish, with more gibberish on top of it. Whether rude or not (which requires an assessment of motives), it's an abuse of the system, the exact kind of thing (meta.stackoverflow.com/a/317611) that we endorse flagging as R/A.
It catches where the phrase "Student Saathi" (with or without whitespace or intervening non-word characters) appears, but does not match "studentsaathi.com", so the two regexes work in tandem. One watches the domain itself, while the other watches the phrase but not the domain. Keeps them from overlapping.
@cocomac The regex contains an unescaped ".", which should be "\." in most cases. Append -force to the command word(s) if you really want to add the pattern you provided.
TBH, this should probably be added to Offensive Answer Detected, and some people spell piece with the i and e flipped, hence the two periods (to match any character), and some people replace the i in the last word. Actually, Offensive Answer Detected (or the watches?) probably should have period characters for the vowels in the swears
I'm not going to without asking anyone first, but IMO the vowels in profanities should be replaced to match any single character. At least for now, that should do, but checking for that is a TODO
> Potentially bad keyword in body, potentially bad keyword in title, potentially bad keyword in username, toxic body detected ---------- Potentially bad keyword in body - Position 0-13: peice of sh!t Potentially bad keyword in title - Position 0-13: peice of sh!t Potentially bad keyword in username - Position 0-13: peice of sh!t Toxic body detected - Perspective scored 0.8831064
> Potentially bad keyword in body, potentially bad keyword in title, potentially bad keyword in username, toxic body detected ---------- Potentially bad keyword in body - Position 13-26: Piece of SH*T Potentially bad keyword in title - Position 13-26: Piece of SH*T Potentially bad keyword in username - Position 13-26: Piece of SH*T Toxic body detected - Perspective scored 0.88651687
> Potentially bad keyword in body, potentially bad keyword in title, potentially bad keyword in username, toxic body detected ---------- Potentially bad keyword in body - Position 0-13: piece of sh*t Potentially bad keyword in title - Position 0-13: piece of sh*t Potentially bad keyword in username - Position 0-13: piece of sh*t Toxic body detected - Perspective scored 0.89158845
@cocomac You can try for yourself here (which has a live test for the API we use). If you just test on the "A>" portion, or even "A>" and "B>", it detects it. But, the more text you include, the less likely it is to detect it as toxic.
It does, actually, make sense that "piece of" is required to get it to be detected. That's actually good, because it reduces FPs.
True, but given that the i in the profanity was obfuscated, IMO it is probably better to be safe. Testing on that site it gives about 80%... what is our current baseline for toxic answers?
Overall, there's usually more needed in a post to make it offensive than a single use of the word "shit". For example, there are > 10,000 hits for "shit" on SE (in text, code, and URLs), and about 1,000 of "sh!t". Most of those are likely to be, at worse, repairable offensive posts, with many of them being completely legitimate uses of the word.
Yeah, that's also another good point. That answer I reported could easily have contained that rude phrase but not been flaggable or reportable if it had contained a useful/relevant answer somewhere within it.
Not that I'd be too fussed about SD detecting answers that are in dire need of repair.
I'm a bit surprised that "piece of SH*T" wasn't already caught as that can be a red flag (although there are quite a few FPs). That said, I fully agree with requiring "piece of" to avoid FPs. Though it is enough of a red-flag, I do feel it is worth having on the watchlist
@AndrewT. 'https://android.stackexchange.com/questions/43361/what-information-does-stock-android-send-to-google-by-default-and-how-do-i-opt/43390?r=SearchResults&s=18%7C3.1577#43390' is not caught by a blacklist or watchlist item.
@CodyGray 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 word(s) if you really want to add the pattern you provided.
Makyen/EC2-linux received failover signal. <-- This probably shouldn't have happened. Check if Osiris is operational (e.g. !!/location) and consider executing !!/standby Makyen/EC2-linux to put this instance back in standby. (@Makyen)
@CodyGray That pattern looks like it's already caught by Blacklisted username Append -force to the command word(s) if you really want to add the pattern you provided.
@cigien I'm aware of the user and site that they spammed, but I'm confused by our conflicting feedback on metasmoke.erwaysoftware.com/post/382201; what do you see that I missed?
I spent way too long trying to find the spot in the code that's responsible for the spacing for the red X and green check, but failed. Would love to see a non-clickable bit of space between them
Hmmmm... well, there already is some non-clickable space between them, but it's just a single whitespace, so gets collapsed down to whatever your browser chooses to collapse that down to. We, obviously, can add some more space there.
Yes, an actual Issue on GitHub would help track the request.
