@Makyen Oh wow, interesting. I, somehow, had not heard any of that story. I don't understand why you would be denied permission to have that in a userscript. We're not talking about auto-flagging, as far as I can tell; FIRE is only on-demand flagging. So I don't know what the concerns would be about having a userscript running in a user's browser raise flags using the SE API on behalf of that same user.
Honestly, that seems less concerning and controversial than centralizing flagging via MS.
@CodyGray The concern was specifically from the user who initially created FIRE. Basically, they don't like the fact that the SE API makes you match up the text name of the flag, which might change and is different for each language used for localized SE sites. They felt there was too much risk and didn't want to have that risk in FIRE. It's not a concern I consider to be nearly as significant as they appear to feel it is, and I don't really, understand why they feel it's such a risk.
Not liking the underlying issue of the SE API using changeable, language-localized values to be the only thing that identifies the flag types is something I definitely understand, and agree is just wrong/inappropriate/bad design for the SE API. What I don't really understand was their evaluation of the level of risk wrt. FIRE implementing it, and that the risk couldn't be appropriately mitigated.
@Makyen Oh, I see. Yeah, thanks for clarifying. I assumed it was some sort of concern from staff or others about the risks, not from the developer. I also agree that's very bad API design, but it's something we battle with constantly. Close votes work the same way, for example.
@SmokeDetector Why was this answer not automatically scanned and reported? The blacklisted website was in every version. SD should have scanned this twice half an hour prior to it being manually scanned. It should have been reported with a first automatic scan 1/2 hour earlier, 5 minutes after their first one was also manually reported. Are we dropping these somehow? Is the 155-questions-active WebSocket not including them?
I know we've had reports, from time to time, of posts not being reported, but that's been presumed to be that there was a grace period edit. It's not possible for the issue on this one and the user's other one to be a grace period edit, now that < 10 rep users don't have a grace period. The other one by this user was manually reported 6.5 minutes after posting and has no edit.
Post manually scanned by user *cocomac* in room *Charcoal HQ*.
Blacklisted website in answer - Position 41-52: pdfgear.com Blacklisted user - blacklisted for https://tex.stackexchange.com/a/645455 (https://metasmoke.erwaysoftware.com/post/368424) by https://chat.stackexchange.com/transcript/11540?m=61209723
If the 155-questions-active WebSocket doesn't have all the active questions from sites other than SO, then we're going to have to change things up quite a bit. That's going to be a bit messy.
Hmmm... there's some code to account for potentially missing questions, but it wouldn't help for answers to older questions. There's also the issue of not including questions which have too low of a score (more an issue for meta sites, but also main sites). OK. Yeah, it looks like we're going to have to go with the recently active questions route for all sites. It's really the only way to be sure (hopefully that isn't filtered too).
@SmokeDetector Yeah, yeah. I forgot I was replying to you.
@Makyen Are you sure it wasn't grace-period...? This user has 7 rep on Tex SE, so presumably at one time they had 11 rep, which would have allowed grace period edits
@cocomac There's 2 actual revisions about a minute apart. Both revisions have the blacklisted website in them. They didn't get their 1 upvote until 1/2 an hour after both answers were posted.
@Makyen Hmmm... that should probobly be looked into. But given that you're a mod on SO, are you able to nuke their account across the network to insta-kill all their spam? I see they got suspended on SO, but do site mods have the ability to fully nuke an account...?
Although I guess if a mod went rouge you wouldn't want them being able to nuke random users across all of SE just because they had an account on one site
@cocomac Yes, for obvious cross-site spammers it would be quite convenient. Even without a rouge mod, there are users who behave very differently on different sites and definite differences in the opinions held by moderators on different sites as to if some users should be suspended, let alone nuked.
I thought mods could destroy acounts on their site... when I look at my flags, I see quite a few users that are simply replaced with a non-linked user##### name, pretty much only for phone-number spam and users that post one R/A thing and that's it... do CMs really do that? I thought that was the local mods
@CodyGray Oh I see, that makes sense. Network-wide suspensions would be nice, but I could see how it could be risky due to per-site policies. SD being able to blacklist users across the network would be handy, so I may look into that some more in a few weeks (I'm pretty busy for a couple weeks)
@Makyen sigh Thinking it through, the current method of getting posts on all sites, other than SO, definitely has holes through which posts will fall (I can think of at least a couple ways it would routinely happen). We definitely need to change that, but I'm unsure what the impact on SE API quota use will be.
@CodyGray When the code was worked on, years ago, it was known that the 155-questions-active WebSocket filtered out a significant percentage of active SO posts, so a different method of fetching all recently active questions is used.
@Makyen Ah, and that same socket does the same filtering for other non-SO sites, but the different method is only used for SO?
@cocomac No change in policy. It's pretty silly to argue that it shouldn't be downvoted, given that raising a spam flag implicitly downvotes it. Glorfindel's answer there says clearly that "it doesn't matter if you downvote it or not". That means it doesn't matter.
The visibility issue noted by JonW is solved as long as someone raises a spam flag on it. It only takes one person. That's why it's harmful if people downvote in lieu of flagging, but totally irrelevant if people downvote in addition to flagging.
@CodyGray Fair enough, OK. I was just confused because I've seen reminders on Unix Meta SE regarding it from high-rep users, but I'm happy to downvote as well. I don't really have an opinion, so I'm happy to go with whatever
The only relevant factors that I can think of are: (1) it's kind of a waste of time to downvote, but, on the other hand, it doesn't take much time at all, and (2) it could be argued that it's wasteful of your daily vote allotment to downvote spam, but since the votes are returned once the post is deleted, that doesn't matter for spam, either.
@Makyen The reality, however, is that there isn't a WebSocket subscription, or combination of WebSocket subscriptions (without signing up for every question individually, which isn't realistic), which doesn't filter some things out. Accounting for that is sort-of handled by the code used for other sites, but it's not really covered.
Basically, we need to switch over to using the same method for every site which we use for SO.
@tripleee That pattern looks like it's already caught by Blacklisted website in answer and Blacklisted website in body Append -force to the command if you really want to add the pattern you entered.
@JeffSchaller That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer Append -force to the command if you really want to add the pattern you entered.
@JeffSchaller That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer Append -force to the command if you really want to add the pattern you entered.
[ SmokeDetector | MS ] Link at beginning of answer, potentially bad ip for hostname in answer, potentially bad ns for domain in answer, potentially bad keyword in answer (38): interrupted printing by Xiaomai technology on askubuntu.com
