Posting to raise awareness of this behavior with kbin. Maybe it’s something Ernest can address in the ActivityPub rewrite, maybe it’s something that doesn’t need to be (or can be) addressed at all.

On Mastodon, if you don’t like your instance or it’s in the process of shutting down, you can migrate your account to another instance. I was aware of this feature, but I hadn’t considered how such a move federates to kbin, until now.

I had blocked a user of a niche Mastodon instance, and then they migrated to a larger instance. After the migration, I started seeing their posts again, with my blocklist only containing the old account, not the new one.

Now to my knowledge, this feature of Mastodon is not a standard component of ActivityPub. I think it’s a great feature actually, but I’m concerned that enables a sort of harassment whereby an attacker can harass someone, get blocked, migrate to another instance, and continue harassing their target. This feature being non-standard, I don’t know how it gets broadcast to other instances, let alone if/how kbin should handle it.

Should kbin automatically update blocklists with the newly migrated account name and instance name? That feels like the ideal solution, but I don’t know how feasible it is. Just wanted to open this up for discussion and awareness.

  • RobotToaster
    link
    fedilink
    arrow-up
    16
    ·
    1 year ago

    From a software perspective, it isn’t the same user, it’s no different from making a new account on a different lemmy/kbin instance.

  • btaf45@kbin.social
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

    This is a feature, not a bug. I’m not sure how you know they are the same user, but if they do the same thing that got them blocked before, you can block them again.

    • HarkMahlberg@kbin.socialOP
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      I’m not sure how you know they are the same user

      Their old account has a blurb providing the new account name. In my case I’m not dealing with a malicious user, just one whose content I don’t want to see.

    • _s10e@feddit.de
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      You know they are the same user because mastodon has a protocol for Migration. Basically, you announce on the old instance what your new handle is and confirm from the new instance that this is where you came from. Mastodon then migrates your followers (and blockers). So you can change instances transparent to others.

      Of course, this migration is more work than simply creating a fresh account, so i doubt this helps against spammers, but it may help against annoying people.

  • dannekrose@kilioa.org
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    @HarkMahlberg

    The technical details will determine what can and can’t be done, but from the Mastodon documentation:

    https://docs.joinmastodon.org/user/moving/

    Moving your account is the same as redirecting your account, but it will also irreversibly force everyone to unfollow your current account and follow your new account, if their software supports the Move activity. Your posts will not be moved, due to technical limitations. There is also a 30 day cooldown period in which you cannot migrate again, so be very careful before using this option!

    Depending on if k/m/bin receives a “Move” activity, it may be possible to update user blocklists based on the information in the “Move” activity. However, “Move” activity is generally only sent to existing followers. (I don’t know all the details on that) Activities are generally sent to an instance to handle, not individual user accounts, though, so I suspect this might not be as big of a hurdle as it might seem.

    Short answer: Maybe. Depends on how they “Moved”. It wouldn’t be simple to implement, however I don’t see anything preventing it in this particular case. You should open an Issue for feature request for it. I recommend including the above piece from the Mastodon documentation, however in your issue.