I was one of the trailblazers who defeded from .ml and once the domain filtering feature was added, I added lemmy [dot] ml to my domain blocks in the admin panel. Reason being, I don’t want .ml content including crossposts and re-posted images.
I thought that was working great until I noticed today that I hadn’t gotten any posts to !books@lemmy.world for several months. Even trying to manually resolve a post pulled from there directly, it wouldn’t load. Finally checked the server logs, and there was a Domain is blocked event right after the logged call to ResolveObject. Of course the logs didn’t say what domain.
Long story short, after scouring the randomly-selected test post to see if there was some kind of false positive, I finally realize there’s a “Related Community” link to a community on .ml in c/Books’s community description and that was what it was hitting on. Any post coming in to c/Books was being rejected because the community description linked to something in my site’s URL filters.
Edit: Okay, so I tried to reproduce this while I was putting together a bug report, and it’s no longer doing it. I re-added .ml to my domain filter list, and can still resolve posts to c/Books which has a link to .ml in its description. So maybe it was just a glitch? I’m gonna play around with it and see before submitting it as a bug.
This could be a major vector for malicious actors. Try to block me? I’ll just edit my description to cut off from every community.
Granted, I don’t think the instance level URL filters were meant to be used for the domains of other instances like I was doing here. They’re more for blocking spam domains, etc.
e.g. I also have those spam sites you see in c/News every so often in that block list (e.g.
dvdfab [dot] cn,digital-escape-tools [dot] phi [dot] vercel [dot] app, etc) , so I never see/report them because they’re rejected immediately.During one of the many, many spam storms here, it was desired by admins for those filters to stop anything that matched them from federating-in instead of just changing the text to removed on the frontend. So it is a good feature to have. Just maybe applied too widely.
Though I think if a user edited their own description to include a widely-blocked URL (no URLs are blocked by default), they’d just be soft-banning themselves from everywhere that has that domain blocked.
If a malicious community mod edited their communities’ descriptions to a include a widely-blocked URL, then yeah, that could cut off new posts coming in to any instance that has that domain blocked (old posts and the community itself would still be available).
All of those would require instances to have certain URLs blocked. The list of blocked URLs for an instance is publicly available from the info in
getSiteAPI call, so it wouldn’t be hard to game if someone really wanted to. Fortunately, most people are too busy gaming the “delete account” feature right now 🙄.Thanks, I appreciate the insight.
Is there an issue about this in the GitHub tracker? It could be an unintentional consequence.
I haven’t looked. Just noticed it earlier today and haven’t had time.
Whoopsie!
Lol. I guess now I gotta decide which is more annoying: Not having content from c/Books or having to deal with unwanted spillover from
.ml. I don’t have the chutzpah to ask the mods to change the community description lolJust figured this might catch other people off guard like it did me. I never would have expected the community description to be evaluated for the URL filter (only posts/comments).
Maybe this can be your first code change PR? 😉
That’s good to know.
Also, I think the larger instances are curating their front pages as well. I’m not techy, so correct me if I’m wrong, and that can’t even been done. It sure seems that way when you look at new on my home instance.
So, can’t even speak about a given community (just because they live in a certain instance) without getting blocked? Well now that’s censorship if I’ve ever seen any.
Tbf, this behavior is very much unintentional, as OP explicitly lays out, and would like to make others aware and stop it from happening.
Also, an individual user can “speak about” an instance just fine without getting thus censured - it’s only community sidebar descriptions being caught up in this sweep unintentionally.
So yeah, OP himself shares your distaste that this is a bad thing? But it is not a thousandth as bad as you are making it out to be - which given recent flamewars about Tankies vs. PieFed I wanted to make things crystal clear even if you meant every word there in jest, so that others do not get mislead.
Hmm it’s fortunate that this only applies to the sidebars, but that also makes me highly question that it is
very much unintentional
given it happens only there and not everywhere.
I unfortunately have worked with programming filters before (paid for it; still not worth it). The first thing you test about a filter in a development environment is that it filters out what you want. The second thing you test about a filter in a development environment is that it does not filter out what you don’t want. All that comes long before pushing to production (let alone on a Friday). That sounds like at least negligence, so it’s debatable if it’s actually unintentional.
Regarding an issue filed for this… well, issue, I can’t find any. Can’t file one either, since I don’t use a Microslop account anylonger. Kudos to whoever files the issue.
That’s a lot of work just to avoid switching to subscribed view.
you’re missing the point. in subscribed view .ml content can still appear. the point is to make it so that nothing from lemmy.ml can get through at all because the people on that instance suck to interact with.
I think you are generalizing too much.
its not necessarily every single user, but the vast majority of the time when you interact with a .ml account they act insane and are assholes. it may only be a vocal minority, but the mods do nothing to stop them and on .ml communities they actively support that behavior.
Their opinion is valid.
