[ SmokeDetector | MS ] Few unique characters in body, no whitespace in body, potentially bad keyword in body, repeating characters in body (266): identify japanese font pls? by S A R U on graphicdesign.SE
@SmokeDetector While I agree that this should not be red-flagged, or be TP, in its current state, in the state that it was reported (i.e. with body content equivalent to a keyboard mash and a title that didn't constitute a question on its own), I'd be fine with a system level block.
@NobodyNada It's probably good to change your feedback now, but your FP was good and important to have given initially once you'd seen that the question had been edited, because your FP triggered the notification to flaggers, which allows them to evaluate the question themselves.
There have been a few autoflagged posts where I've intentionally given FP feedback initially in order to trigger that notification.
@Stormblessed FYI: An autoflag of yours was used to flag this post [ MS ], which was edited during the grace period to be just above the point where many of us feel it should be flagged. You may want to evaluate it yourself.
@paper1111 Same for you ^, but you may not get this ping message in a reasonable time-frame, as it looks like you haven't been active on SE for a while, but I figured you'd still want to be aware of the situation and have the possibility of making your own evaluation.
@NobodyNada @RobertColumbia If, in addition to your NAA feedback, you raised an NAA flag on this post [ MS ], you may want to consider retracting the flag. The user has edited the answer so it at least addresses the question.
@Makyen what do you think about splitting your link-at-beginning-of-post watch into a seperate reason, like we have for "link at end of answer?" We've had it on the list for over a year, accuracy is about the same as link-at-end (60%), and it would make it a lot more obvious to see at a glance why the post was reported.
@NobodyNada It should be moved into it's own reason. I've been intending to do so for way too long. In my mind, I've lumped doing that in with adding the domain whitelist checking to most reasons (actually planned as pre-removeal of the links, with option to use it or not in each detection).
@Makyen great, I can go ahead and split that out. I won't implement the whitelist checking just yet since that's a little less trivial and I don't have a ton of time, but I may be able to take a look at that in the future.
@NobodyNada OK. By "whitelist" I wasn't meaning the whitelist that's currently an inherent part of that regex. I was assuming that the portion which is already in the regex would remain. The whitelist I was referring to was the MS based one that's been implemented for some detections.
Note that there are two regexes that do the starts with link detection in the watchlist. One of them should remain on the watchlist, as it's much more prone to FP (and should already be exclusive of the one which should move into it's own reason).
@NobodyNada IMO, there is benefit to watching the specific room, assuming it's something which might be reused in spam. I don't think that we'll ever see the %TP be high enough on chat.whatsapp.com by itself for us to blacklist it. OTOH, if we continue to see that specific room used in spam, then we could end up blacklisting just the room. Putting it on the watchlist now leaves us a marker that we've previously seen it.
Although, given that it's a case-sensitive identifier used in a URL, I'd have put it in (?-i:).
However, that's just a general opinion on identifiers used with other things which we can watch, but won't be able to blacklist. I'm not familiar with chat.whatsapp.com, so I'm unsure what those identifiers are used for. From context, I'd assumed that it identified a chat room that might exist for a while, thus potentially be reused in spam. If those identifiers from chat.whatsapp.com are single-use items, then there's no purpose in watching it.
@Makyen I wondered about that, but I suspected the watchlist search will stop at the first match and so we'd just see the chat.whatsapp.com watch. I'd have to confirm that behavior though.
!!/test chat.whatsapp.com/L1kVNQTkuJ02USuqXCynZF (testing another WhatsApp room that's watched)
> Potentially bad keyword in body, potentially bad keyword in title, potentially bad keyword in username ---------- Potentially bad keyword in body - Position 0-17: chat.whatsapp.com, Position 18-40: L1kVNQTkuJ02USuqXCynZF Potentially bad keyword in title - Position 0-17: chat.whatsapp.com, Position 18-40: L1kVNQTkuJ02USuqXCynZF Potentially bad keyword in username - Position 0-17: chat.whatsapp.com, Position 18-40: L1kVNQTkuJ02USuqXCynZF
@NobodyNada As you determined, it would be prevented from matching, if there was overlap in what was in the actual match of the regexes. For instance, the (?-i:LOFAlKcTJErIGJBlDqabsL) regex shouldn't be implemented as chat\.whatsapp\.com/(?-i:L1kVNQTkuJ02USuqXCynZF), because it definitely which would be shadowed by the chat\.whatsapp\.com earlier in watchlist (i.e. earlier in the overall constructed regex).
If the chat room ID wasn't sufficiently unique (e.g. the ID was custom selected by the spammer to be a non-unique name, username, etc.), then it would be necessary to use something like (?-i:L1kVNQTkuJ02USuqXCynZF)(?<=chat\.whatsapp\.com/(?-i:L1kVNQTkuJ02USuqXCynZF)).
Note that the look-behind is at the end, rather than first. Having the look-behind at the start of the regex requires dramatically more CPU (up to an order or 2 of magnitude more), because if it's at the start, then it must be checked every non-match, rather than only on almost-matches.
To dramatically reduce CPU cost, you really only need the look-behind to be after the first couple/few/several unique characters (depending on how unique), but not breaking up the main portion of the regex makes it overall much more human-readable, IMO.
In other words, I find it much more obvious what (?-i:L1kVNQTkuJ02USuqXCynZF)(?<=chat\.whatsapp\.com/(?-i:L1kVNQTkuJ02USuqXCynZF)) is trying to do rather than (?-i:L1kVNQ(?<=chat\.whatsapp\.com/(?-i:L1kVNQ))TkuJ02USuqXCynZF). At least to me it's much more readable, and doesn't cost all that much more CPU (and the extra CPU time is only spent when it's a match or near non-match (both very rare)).
Are there specific reasons not to have naa feedback on questions? We can theoretically just change naa to vlq and then enable it on all posts. Then we have a complete spectrum of tp<definitely spam> -- vlq<terrible post but not spam> -- fp<legitimate post>
@user12986714 I don't know for certain, but I imagine it's because trying to determine whether a question meets a site's quality standards is a LOT more nuanced than trying to determine whether an answer is link-only or otherwise NAA
@NobodyNada Looks that there is at least legitimate use case for posts like {"title": "How can I do X", "body": "a"*1024}... BTW if we can't decide so in a case, just pretend that vlq is disabled, as the current status.
@user12986714 [This is just me repeating back a synopsis of the responses I've seen when it's previously been suggested]: Basically, because implementing it is a significant PITA, which would require going through lots of code/data for little benefit (from MS' POV). NAA as a feedback exists only to make the humans giving feedback happier/more comfortable. From MS's POV (i.e. from the POV of autoflagging), NAA==FP.
Just FYI: Implementing VLQ (NAA for questions) has been suggested several times, with basically the above response given each time I've seen it brought up.
@Makyen 1) MS can just do nothing about past report 2) this is mainly an issue when I am now trying to implement ml for SD (somewhat like halflife), where I wish to tell my algorithm that tp is positive, fp is negative and vlq is neutral.
@user12986714 I'm not the one to discuss this with. I'd strongly recommend searching in chat and reading through the previous times it's been suggested. After you've done that, you'll know which people to discuss it with and the pro/con arguments which have previously been presented.
Again: From this project's POV NAA==VLQ==FP.
Note: I actually agree that it would be nice to have a bit more differentiation in feedback. Having VLQ for questions has the potential to make the data we're collecting more generally applicable, and would make the humans giving feedback more comfortable. Having even further differentiation in feedback would be beneficial. For instance, it would be helpful to the project as it now exists to have a feedback category which is TP (system level block OK), but autoflagging is not-OK.
@Makyen (this is about pr 3860, major refactoring of globalvars.py) well I suppose you can directly commit onto that pr, since you have write access and I have checked the allow maintainer to commit box, and that this doesn't create new conflicts. (I really should post this on gh, but I am not using my computer)
@user12986714 My note to self really was just a reminder to myself. It was just one of those "why are we repeating code here" things. It really has nothing to do with your PR, other than the PR touches those lines, so they are obvious in the diff.
@Makyen 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 "adjust the above if/else after it's merged" This is mainly about the "after it's merged" part :-P Also it is such an elegant way to do this, and can solve another minor but itchy issue in seconds.
@user12986714 Yes, I understand it's intended to be for titles (i.e. it won't match bodies). I'm not surprised that it would show a high TP rate on MS, but I'm more concerned about those people who think their question is "important!!!!!!!!!!!!!!!" :;
@user12986714 just FYI: I ran a grep on a 3-year-old Code Golf data dump I had lying around, and there were 377 questions with a ! at the end of the title
38 on a Graphic Design.SE data dump
and I don't have any more old data dumps lying around
@Shree OK. I'm going to need to see what the impact is of doing that (i.e. if there's anything that needs to happen first, or if there are any specific database concerns). [In other words, how to make sure it's clean from our POV.]
@NobodyNada the problem is, there are 15967903 posts... So fp in one day, suppose 10000 posts are made, is 5. However the benefit vs fp tradeoff may not be worthwhile
@Shree I understand that it may not be any of my business, but I'm curious as to why you want your account deleted. Are you willing to share your reasons?
@Shree is that message the reason you feel unsafe? The decision is yours of course and maybe there's some context I'm missing, but everyone seemed pretty friendly there; it doesn't look to me like anything bad happened
@Shree OK. I'm sorry to hear that. I don't see anything in the conversation you linked to that I would think would make you feel unsafe, but I accept that you do. I see some miscommunication, but ... I'm not sure how that communicated "unsafe".
Deletion: It may be a bit while I try to contact others who have previously deleted an account in order to verify doing so isn't going to break things. I've already pinged them elsewhere, but they are likely asleep at the moment. IIRC, there were definite issues the last time a user who was a substantial contributor asked to have their account deleted. I'm vaguely remembering the issues required direct database manipulation, which I can't do. I'd like to avoid any such issues, if possible.
In the meantime, I would suggest you go to this page on SO and click on the "remove" button associated with any metasmoke related application. That will invalidate the token(s) which MS has, which will greatly reduce any possible harm that could possibly be caused.
@Shree Thank you for trying to explain. I appreciate your doing so. I definitely want you to feel safe. I am saddened to see you go, both from a personal standpoint and from the project's point of view. For the project, your contributions have been quite significant and very helpful. Thank you for the work you've put in. From a personal standpoint, I will miss seeing you around here.
Please be patient while I wait to hear back from @Undo, who is more familiar with what happened the last time a significant contributor's account was deleted, and who is better able to handle any unexpected issues which might happen when deleting your account (e.g. can directly edit the database).
If you have not done so already, please go to your Stack Overflow Applications page in your profile and "remove" any access which metasmoke has.
[ SmokeDetector | MS ] Bad ip for hostname in body, bad keyword in body, bad keyword in title, blacklisted website in body, pattern-matching website in body, +3 more (493): What Trainee Fat Burner? by wandalone on math.SE
