Edit: Okay, so I tried to reproduce this while I was putting together a bug report, and it’s no longer doing it when I was following my “steps to reproduce”. 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. But I do know before I removed .ml from that list yesterday, it refused to because of the link in the description (none of the test posts hit on that domain) and consistently said Domain is blocked. :sigh:

Edit 2: Ok, now it’s behaving as described. There must be some lag/delay between adding a domain to the filter list and it applying to inbound federation. Submitting a bug.

Edit 3: Bug 6320

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 [email protected] 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.

  • gedaliyah@lemmy.worldEnglish
    4·
    1 day ago

    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.

    • Admiral Patrick@dubvee.orgOPEnglish
      2·
      21 hours ago

      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 getSite API 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 🙄.