@double-beep 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.
@double-beep 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.
> Questions seeking recommendations for specific equipment are off-topic, because they are primarily opinion based. Instead, describe the required function and setting in which the equipment will be used, and ask what you should look for to achieve that.
@SmokeDetector actually looks like a spam seed; the OP's home page is bestguitars.in and claims they are passionate about guitars, unlike what the question says
@Makyen Well, I haven't gotten the service to autostart after it crashes from nocrash.py yet... but it doesn't look TOO hard (but we want a 'clean exit' ala "The stappit command was called or a clean exit() was called" to not trigger a restart either). The tricky part here is, we'd have to specify the default 'startup' mode to 'standby', which IMO isn't a bad thing, since we can always kick an instance to Active with MS
@Undo It's not that hard, but it's still a fairly daunting task, depending on what exactly you need. Simple SystemD services can be made from anything, including non-forking processes like a Python script/worker that needs run on autostart but doesn't make for a good uwsgi app or such
i'll write up some things for how I did it for Smokey and put it somewhere. Gotta sanitize the data though, 'cause I had to define the env vars we use for auth in the SystemD file...
[ SmokeDetector | MS ] Url in title, body starts with title and ends in url, potentially bad keyword in body, potentially bad keyword in title, potentially bad keyword in username, +1 more (297): play918kiss.com/918kiss/ by 918kiss Malaysia on academia.SE
[ SmokeDetector | MS ] Bad keyword in link text in body, potentially bad asn for hostname in body, potentially bad keyword in body, potentially problematic ns configuration in body (69): What is network security by LearnFinder on superuser.com
@Undo @Makyen so Solar Flare has the experimental "Restart On Crash" cases, except where SIGINT or SIGKILL are sent to the underlying processes. (which would be equiv. to a KeyboardInterrupt or a straight "DIE PROCESS DIE" from the system)
Lunar Eclipse has everything BUT the autorestart case.
and the unit on Solar is set to only restart on: (1) a non-clean exit code, (2) an unclean signal, (3) a timeout of the service responding to pid checks, etc., and (4) the SystemD watchdog process seeing that it died off.
so we'll have to test it eventually, but with regards to Solar and Lunar, they're both SystemD-ified so if the container reboots it'll start the process back up in standby mode automatically once the network interfaces are actually up :P
How many instances of two people answering (and accepting) each other's questions would it be worth looking for before flagging for possible voting fraud?
@WaiHaLee i mean, if you think they're the same person I'd just flag one of the accounts for attention with a custom mod flag, and then leave it be, usually after I see more than one interaction in that manner.
but it typically would take some time before there's enough to support a full fraud claim that early on.
if you see a number of instances though, you should consider flagging :P
@JohnDvorak @CalvT I'd argue that "weight inflation" is reasonable, even desirable. We want SD to be able to grow and adjust. If we artificially limit SD to some concept of what the weight graph should be wrt. specific numbers, then we significantly limit how effective we can make SD. Doing so would effectively mean we could never create new detections, or otherwise scale the current number to the old detection/weight numbers.
The problem is that our weight data for the posts in MS doesn't reflect the current state of the detections in SD. That causes predictions about the current detected post (i.e. choosing to autoflag, or not) to be inherently inaccurate (to an extent).
The only way to fix that we are making predictions based on inaccurate data is to have SD periodically (weekly?) run through all the posts on MS and store the current set of detections which catch the post (obviously, saving the original for historical analysis). The current detections on all posts can then be used to determine the current weights for detections and posts.
While doing this won't make autoflagging perfect, it will at least mean we're making predictions based on the current state of SD's detections, rather than trying to match current performance up to what SD did years ago.
@Makyen 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.
@SmokeDetector xD: a translated piece of text: I am the famous DR SHORANMAN the strong basketball player who can solve your problem within 24 hours. Completely unrelated (basketball player can solve everyone's problems?!) and makes no sense in Greek.
@ThomasWard It's not quite obvious fraud yet, I don't think. There's one instance where A asked a question and B's answer was accepted, then B asked a question and A's answer was accepted.
Both A and B have the same info and location in their profiles.
@Makyen Very good points, which I agree with. What I would like to see some day (but probably never will) is findspam separated from Smokey, and made into an API. A bit like we use Perspective at the moment. I've been toying with this in CS, but I don't currently have the knowledge to develop this. That way we could recalculate the spam scores of posts on the fly if needed to.
Also I prefer a percentage based score as well, but again, that'll never happen as it's a huge change
There's also no need for that at the moment - what we have works fine
@ThomasWard It was on SO. The NAA answer that I flagged has since been deleted (I'd post a link but neither of us are 10k on SO). I'll mod flag the potential parent user and see what happens. Thanks for the advice.
yep. it's fairly straightforward, but it's probably still going to be fussed with.
it's in 'manual only' mode on my instances but when I finish tweaking when I enable the service it'll start at-boot after the network interfaces are actually up :p
@double-beep If you're going to have the \W* to catch extra characters, you can dispense with the @ and \. for just (?:\W*gmail\W*com)?. If you want to detect a step further in obfuscation (not a bad idea if the spammer starts heading down the obfuscation path), then what we've generally been using is: (?:\W*(?:at\W*)?gmail\W*(?:dot\W*)?com)?. It's not 100%, but it will get ~99.5%. Looking through "watched_keywords.txt", you'll find numerous examples that catch further obfuscation.
Notable among those is probably this one. It is, however, more complex than it needs to be, as it's testing for HTML entities between valid characters. I later figured out that SD converts all HTML entities to characters prior to processing the post, so accounting for them in the regex is not required.
[ SmokeDetector | MS ] Bad keyword in body, bad keyword in title, blacklisted website in body, body starts with title and ends in url, link at end of body, +4 more (690): Body Building Tips by Fannin1 on workplace.SE
