Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nerf posts that have been flagged as spam #1381

Open
cellio opened this issue Aug 16, 2024 · 7 comments
Open

Nerf posts that have been flagged as spam #1381

cellio opened this issue Aug 16, 2024 · 7 comments
Labels
area: ruby Changes to server-side code complexity: average Not particularly hard, not particularly trivial. priority: medium type: change request New feature or request

Comments

@cellio
Copy link
Member

cellio commented Aug 16, 2024

Related to meta:291174

The linked meta post requests a spam reaction to alert readers, but that risks people reacting but not flagging (and then the post never gets addressed). Also, reactions are not anonymous and maybe this should be. An answer suggests disabling links if a post has a spam flag. Let's build on that.

Proposal: if a post has a threshold number of spam flags, disable links. Because that could be confusing, also add a notice along the lines of "links have been removed pending human review" to the bottom of the post. Spam isn't the only problem case here (there's also malware), so I'd rather not say "spam" in the notice, but we can certainly wordsmith this.

As for the threshold: a single flag seems consistent with close votes and our current small size, but I don't know if that will always be true, so let's code it in a way that's easy to change later, or maybe even make it a site setting.

Doing this would make meta:291184 redundant, I believe.

@cellio cellio added area: ruby Changes to server-side code type: change request New feature or request priority: medium complexity: unassessed Needs further developer investigation before complexity/feasibility can be determined. labels Aug 16, 2024
@ArtOfCode-
Copy link
Member

The easy way to do this would be a JS flag that sets links' href to javascript:void(0) if the post has been flagged as spam. That wouldn't neutralise links for users without JS, though.

The harder but proper way to do it would be to trigger an automatic edit (including post history event) when a spam flag is created to edit links out of the post.

@ArtOfCode- ArtOfCode- added complexity: average Not particularly hard, not particularly trivial. and removed complexity: unassessed Needs further developer investigation before complexity/feasibility can be determined. labels Aug 24, 2024
@cellio
Copy link
Member Author

cellio commented Aug 25, 2024

The easy way sounds reasonable to me. Plus, if we do it the harder but proper way, we also need to catch if those flags are declined and update the edit history again. A runtime check for "is there currently a spam flag?" seems more resilient. (Also, we wouldn't want to attribute those edits, so that's more complexity.)

@ws909
Copy link
Contributor

ws909 commented Aug 25, 2024

As I’ve mentioned before (I don’t really agree with this whole idea, but I’m outnumbered there), this does let flaggers create far too much noise when they, in fact, only have the ability to flag and not handle flags, for a reason. Automatically editing because of flags gives flaggers quite a big opportunity to cause permanent massive disruption and noise. If CD had a post timeline like on SE, you could at least minimize the impact by putting it there instead, if flags are going to change post properties. Automatically editing is just a bad idea.

@Oaphi
Copy link
Member

Oaphi commented Aug 25, 2024

Can't we just derender links for posts with spam flags as it's trivial to get that info via a query? Will require a couple of changes to the views and the controller, but worth it in the long run, imo.

This way we also have the benefit of, if users are fast enough, preventing those links from being forever embedded into scraper sites and the IA.

@ws909
Copy link
Contributor

ws909 commented Aug 31, 2024

Can't we just derender links for posts with spam flags as it's trivial to get that info via a query? Will require a couple of changes to the views and the controller, but worth it in the long run, imo.

This way we also have the benefit of, if users are fast enough, preventing those links from being forever embedded into scraper sites and the IA.

That's a far, far better idea, although I'm still skeptical (however, that skepticism can rest on Meta). It still lets bad flags cause frustration and confusion. Legitimate users may end up asking on Meta why links in their posts aren't working. Having a question for that on Meta isn't an issue, but it puts extra toll on the victim. It might also lead to comments under posts, but those will primarily be of permanent disruption to the post author, curators and moderators, however, that disruption will be minimal, and is more of a fault with the comment system as it stands now.

So in terms of actually letting flags have an immediate effect, this seems the best possible one.

@ws909
Copy link
Contributor

ws909 commented Aug 31, 2024

Also, if this is implemented, it may be worth looking into doing it for R/A flags, too, as posts can link to blatantly offensive or abuse websites without in itself being spam. From experience on SE sites, I think it would be wise to not activate it for R/A flags in the meta category.

@ws909
Copy link
Contributor

ws909 commented Aug 31, 2024

How much toll will this put on curators and moderators, if the link is disabled?

If it's a disabled titled ([title](mylink.com)) link, there will be no way to easily grab the link without crawling through the post source, manually marking and copying the link out of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: ruby Changes to server-side code complexity: average Not particularly hard, not particularly trivial. priority: medium type: change request New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants