tech, Mastodon, fediverse blocks, long 

Mastodon currently features two ways, as a user, to limit interactions with a given user, and one way to limit interactions with a given instance.

Regarding users, they are mute and blocks.

Muting an user means you don't receive notifications from them and you don't see them in your timelines. It doesn't give that user (or their instance) any information or require any collaboration from their instance.

Blocking goes a bit further by doing a few things:
1. Forcibly remove them from your followers and auto-reject follow requests (whether or not your account is locked)
2. Hide *your* content from them
3. (it's a bit of a side effect to 2) prevent them from interacting with you at all

Every single of those things can give out to that user that you're blocking them, though, and if they are remote, every single of those requires some kind of cooperation from their end:
1. If you have non-blocked followers on their instance, you're still sending your toots (including private) to that instance, so if the instance doesn't respect the “forcibly remove them from your followers” part, you're fucked. Ultimately, there is no way around it, but the protocol design could have been less error-prone.
2. This is mildly useful, can be very easily bypassed (just opening the profile in a browser for instance), and requires full collaboration from the instance their are on. Ultimately we can't do much better with regards to that particular limitation.
3. I'd argue this is more useful than 2. as preventing people from boosting and replying from blocked actors reduces the amount of exposure your content is likely to get in those circles you want to avoid. However, no matter how you look at it, this requires collaboration as well. But it should be possible (although very involved) to not require the collaboration of the very instance that is hosting offending actors (basically, you'd ask the instance of the blocked user if they accept the interaction and ask them to give proof that they do, then attach it to the interaction, and every collaborating instance would only accept it if it comes with proof)

Now, instance blocks. They're a mess. They are called “Hide instance” and it's not obvious if they block or mute instances. What they actually do, as far as I can tell, is:
1. Forcibly remove followers from that instance (thus requiring collaboration as stated previously, even if that's less of an issue because of 2.), reject any pending follow request from that instance
2. Stop sending anything from your account directly to that instance
3. Avoid showing you content or notifications from that instance
4. [in the development version only] if the “authorized fetch mode” is enabled, do not allow that instance to fetch anything (even public statuses)

The first and last point possibly give away (the first one proactively if you have any follower from that instance, and the last one passively) that you are blocking that instance, although it's not as obvious as the `Block` activity from user blocks.

Follow

tech, Mastodon, fediverse blocks, long 

@Thib I guess I'm thinking from a protocol standpoint, but from a *protocol* standpoint, 1 and 2 are definitely broken, and 3 seems effectively broken, but I'd like clarity. At any rate, with that much brokenness, a bad actor can merely host an instance designed to not collaborate and weaponize blocks, performing the opposite behavior. Blocks should not federate.

(... more about 3 cotd ...)

· · Web · 2 · 0 · 1

re: tech, Mastodon, fediverse blocks, long 

@cwebber yeah but there's nothing you can ever do about 1. if the remote instance is evil and you don't know it (and have legitimate followers here, or followers you think are legitimate). I mean, or you could do End-to-End encryption but let's be real, this isn't going to happen anytime soon

tech, Mastodon, fediverse blocks, long 

@Thib Is "preventing interactions" with 3 effectively "preventing boosts, replies?" But obviously from a protocol perspective, that can't happen (excepting preventing replies from showing up in the list, but you don't need to federate blocks to do that.)

Again, I feel like I come at this with a different security model (don't pretend we can prevent what we can't, because doing so increases the danger of our users).

tech, Mastodon, fediverse blocks, long 

@Thib How long until someone weaponizes this? It wouldn't be hard to fork mastodon or pleroma to use blocks as a sword rather than a shield.

(Anyway, I'm getting from this conversation that we both agree, I'm just troubled to see how bad it is presently... especially since we specifically put text in the spec to warn against this)

tech, Mastodon, fediverse blocks, long 

@Thib Just to spell it out: the obvious sword approach would be if Gab or etc started aggregating and publishing blocks to encourage dogpiling

re: tech, Mastodon, fediverse blocks, long 

@cwebber yes, preventing boosts and replies. Since cooperative instances hide the toot, that's a benefit we currently have. Not federating the block info makes the offending users be able to do that even if their instance is cooperative. The local instance can decide not to show and relay these replies to anyone, but anybody else following the blocked user will display them, as they won't know about the block.
Which may lead to other people piling up on the reply.

Sign in to participate in the conversation
Octodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!