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:


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.

  • gedaliyah@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    ·
    15 hours 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.orgOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      6 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 🙄.

  • SorteKanin@feddit.dk
    link
    fedilink
    English
    arrow-up
    10
    ·
    21 hours ago

    Is there an issue about this in the GitHub tracker? It could be an unintentional consequence.

    • Admiral Patrick@dubvee.orgOP
      link
      fedilink
      English
      arrow-up
      8
      ·
      22 hours ago

      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 lol

      Just 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).

  • pelespirit@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    4
    ·
    22 hours ago

    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.

  • lambalicious@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    4
    ·
    18 hours ago

    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.

    • OpenStars@piefed.social
      link
      fedilink
      English
      arrow-up
      1
      ·
      6 hours ago

      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.

      • lambalicious@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        1
        ·
        5 hours ago

        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.

        • OpenStars@piefed.social
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          1
          ·
          2 hours ago

          Most Lemmy issues lay in wait for literally many years before being worked on at all. At best, the devs struggle to work with their command of the difficult Rust language, while at worst they pick and choose primarily issues that they want to see implemented on their home instances lemmy.ml and Lemmygrad.ml, while the needs of the wider Threadiverse are less important to them. (Or both?:-P)

          Which btw is somewhat fine - this is FOSS we are talking about here - except that many people would like to donate to them in hopes that an increased level of code development would occur, only to be extremely disappointed to find out just how much of those funds goes instead to maintain lemmy.ml (seemingly including time spent moderating extremely controversial topics such as criticisms of Russia, China, or North Korea).

          Also, there are very long-standing bugs that have been well-known for many years that go unresolved. This is why I say that it is likely unintentional. Authoritarians tend to not have much sympathy for people who want to individually curate their experiences on the platform, vs. simply taking what is given and STFU about it, at least as far as admins are concerned - i.e. curation for them is done at the instance or community moderator level, rather than the individual human. So not much time is expended upon those features - see e.g. the horribly named (so much so as to almost be disinformation) “instance block” that still allows “blocked” users to read, vote on, and reply to your content, plus send you DMs, and then a later code change further added the ability for those DMs to trigger notification pings - again, this is what rights the “BLOCKED” users have, to someone wanting to block them, whereas conversely the rights of people wanting to institute such a block include: shutting the fuck up, and move to a non-Lemmy platform (including the OP’s dubvee.org since he personally instituted real blocking capabilities there, at least specifically for Lemmy.ml, whereas PieFed allows a user to custom block any instance they choose, independently of instance admin approval).

          See also https://jeena.net/lemmy-switch-to-piefed and https://slrpnk.net/post/29381524 for some discussions about those long-standing bugs that remain unfixed for years and years and years. i.e. I have no problem believing that the devs gave so little attention to this particular issue as for it to have caused unintentional side-effects - at this point it would be more shocking to me to have read that it had been implemented correctly. 🤷‍♀️

    • unknown1234_5@kbin.earth
      link
      fedilink
      arrow-up
      8
      arrow-down
      4
      ·
      19 hours ago

      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.

        • unknown1234_5@kbin.earth
          link
          fedilink
          arrow-up
          3
          arrow-down
          1
          ·
          14 hours ago

          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.