Blacklisting or watching a keyword or a web site address cause the spam detection bot SmokeDetector to trigger an alert whenever that keyword or web site address appears in a post. In other words, it basically says that any post containing this expression is spam, or at least suspicious.
The website blacklist consists of a list of websites associated with known spam that automatically raise suspicion when posted anywhere on Stack Exchange.
Blacklisting a website makes SmokeDetector report every post that is posted or modified with a link to the website (formatted as a link or otherwise) in its text.
The keyword blacklist consists of a list of regular expressions which are frequently seen in spam, and only very rarely outside of spam posts.
Blacklisting a “keyword” (which can actually be a regular expression matching a phrase or a more-complex expression with alternatives, like
find (?:true )?love which matches either of “find love” or “find true love”) causes any post which matches it to be reported as probable spam by SmokeDetector. Matches are not reported in the middle of a word; the keyword expression “dog” does not match “doggone” or “endogenous”.
Similar to blacklisted keywords, but for numbers which the spammer intends to be interpreted by a human as a number (i.e. not for numbers used in URLs, where it is primarily interpreted by a machine). This list is primarily intended for phone numbers, but is not exclusive to only phone numbers. These are not regular expressions. They are just text. Entries are tested both verbatim and with a moderate amount of obfuscation intended to obfuscate numbers removed from the posts.
Each SmokeDetector instance maintains a very dynamic list of users which are “blacklisted”. Users are added to the user blacklist when a post they created receives
tpu feedback. Users are removed from the user blacklist when a post they created is given
fp feedback (not to be confused with
fpu feedback which adds a user to the username whitelist). Users can also be manually added to the user blacklist with
!!/adblu, or removed with
A user being on the user blacklist causes any post they authored to be reported when it’s scanned, but they will be immediately removed from the user blacklist if one of those reports gets
fp feedback. A user should be added to the user blacklist when it is substantially likely that posts by them which are scanned in the future will be true positive. In general, users should not be added to the user blacklist for vandalism.
“Watching” an expression causes SmokeDetector to report it just like a blacklist expression, but the rule weight is kept at one, in order to prevent matches from triggering autoflagging. The watchlist is considered an “experimental” detection reason. Posts which are detected for only “experimental” reasons are reported into only a limited set of chat rooms, because each room has to opt-in to receiving reports with only experimental detections. All reports are always sent to Charcoal HQ. That means you can use
!!/watch to try out different patterns experimentally, just to get an idea of what sorts of posts match a particular expression.
The list of watched expressions is maintained in the SmokeDetector GitHub repository, specifically in the file watched_keywords.txt. The format is slightly different from the other similar files; each entry is a tab-delimited record which includes a date stamp (expressed as Unix epoch, i.e. seconds since midnight Jan 1 1970 UTC), the user name of the person who added the expression, and the regular expression to watch for.
Similar to watched expressions, but for numbers which the spammer intends to be interpreted by a human as a number (i.e. not for numbers used in URLs, where it is primarily interpreted by a machine). This list is primarily intended for phone numbers, but is not exclusive to only phone numbers. These are not regular expressions. They are just text. Entries are tested both verbatim and with a moderate amount of obfuscation intended to obfuscate numbers removed from the posts.
We have established the following rules for watching and blacklisting.
A primary goal of the blacklists is to have a very high percentage of true positive (TP) detections. While it’s impossible to know what will happen in the future, the following general criteria for existing TP and false positive (FP) detections are used to make it much more likely that entries which are added to the blacklists will be seen only in TP posts in the future.
The general target for %TP is in 95%+ range (with some detection reasons below this). Existing blacklist entries which have a %TP rate notably below the overall %TP for the detection reason in which they are included should be either A) adjusted to improve their %TP (i.e. reject more FP posts), or B) moved to the watchlist.
fpufeedback in order to whitelist the user from username detections. However,
fpufeedback does not fully exempt users from such detections. It only prevents reporting if the only thing the post was detected for were detections in the username.
The criteria for blacklisting an entry is relaxed (see above) when the entry is promoted in spam posts which we identify as being part of a “preexisting campaign”. This means the spam posts containing the proposed new blacklist entry can be directly tied to other recent spam posts which contain campaign-specific blacklisted entries which already fulfill the stricter blacklisting criteria for at least one entry which is specific to that campaign (i.e. not just generic blacklisted terms like “keto”). In practice, this helps us trigger blacklisting early for sites or products which are clearly part of a series of spam from the same, or closely associated, spammers, where we can be reasonably sure that the only purpose of the entry is to have a different URL, or slightly different wording, than the other sites used in the preexisting campaign. Note that what is considered a “preexisting campaign” should be narrowly construed, and does not mean everything in an overall type of spam or spam which is for an overall type of product. (This is called “snowshoe spamming” – the tactic is to spread your footprint across many sites or slightly different keywords, so as to evade trivial duplicate detection.)
Some common criteria for establishing a campaign include:
The intent is to enable us to fast-track blacklisting when there is clear evidence that the new domain name (or product name, etc.) is a sockpuppet of an already known spammer, i.e. we can reasonably establish that it was basically created to evade any blacklisting or other negative reputation associated with another account.
You will want to test that the expression you want to blacklist or watch isn’t already covered by one of the existing patterns.
You can use
!!/bisect <string to test> to test to see if the text is matched by an existing watch or blacklist entry, and find out what that entry is.
!!/bisect only tests against the patterns contained in the lists maintained with the
!!/blacklist-* commands. You can test the string for matching all detections by using the
!!/test <string to test> command (or
!!/test-a <string to test> to test as an answer). The
!!/test commands will also test against some blacklist and watchlist entries which are contained in findspam.py.
Everyone with SmokeDetector privileges (if you don’t have those and would like them, read up on how to get them) can blacklist a website, though this will need to be approved by someone with code privileges if you don’t already have them. Additions to the blacklist must be valid regular expressions (regex). In reality that means for largely exact matches (like the website blacklist) that you ensure that special characters (like
.) are escaped. (Example:
There are two methods to add a website to a watch list or blacklist:
Propose a change to the relevant file on GitHub and create a pull request specifying why you want to blacklist the website.
Use the pertinent chat command in any of the Smoke Detector chatrooms. This will create a pull request containing your change for you.
!!/blacklist-website <regex>to blacklist a web site
!!/blacklist-keyword <regex>to blacklist a keyword expression
!!/blacklist-number <number>to blacklist a phone number (not things like URL path fragments, which can’t be obfuscated; use !!/blacklist-keyword for those)
!!/blacklist-username <regex>to blacklist a username (display name)
!!/watch <regex>to add something to the watch list (keywords, web sites, and usernames)
!!/watch-number <number>to add a phone number to the watch list (not things like URL path fragments, which can’t be obfuscated; use !!/watch for those)
If you’re blacklisting or watching a complex regex to match a whole bunch of different stuff, it’s probably better off in the pattern-matching section of
findspam.py. You’ll need to propose a change to the file on GitHub for this; ask for help if you’re unsure what to do. However, if you think something might be appropriate for the pattern-matching section of
findspam.py, it’s reasonable to put it on the watchlist first, so we can collect data as to how accurate it is, without giving extra weight to something that might catch a lot of false positive posts.