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.

@Thib @cwebber i feel like this is misattributing consequences

3 is not a side effect of 2. 3 is the primary purpose. it is a bug and a huge mistake to treat it as a mere "side effect". 1 is a side effect of 3, if anything.

also, your issue with 1 is not wholly a mistake of the protocol in full. the mistake is sharedInbox for private posts --private posts should *not* be delivered to people outside their audience.

Follow

@trwnh @Thib @cwebber

> the mistake is sharedInbox for private posts --private posts should *not* be delivered to people outside their audience.

Right but even if it's not a sharedInbox it needs to exist on the shared server. If I block X@Y, and A@Y is a friend who can get private posts, no matter what happens, server Y is going to need to handle my private messages I send to A. And if Y is malicious, well.

This might be solved with some kind of end to end encryption.

@darius @Thib @cwebber well if a server is showing messages from one actor's inbox to another user that isn't authorized to view the inbox, then at least that makes it spec-incompliant

but yes, encrypting inboxes with your key could be done (shifting the problem slightly, from "malicious software" to "malicious admin"). you'd have to run your own client for it to matter, and monolithic apps like mastodon effectively bundle the client with the server.

@trwnh @Thib @cwebber I guess my main issue here is that you have to assume that malicious actors won't comply with the spec.

@darius @Thib @cwebber i guess my issue is that mastodon's architecture creates new problems outside of the spec

@darius @Thib @cwebber which is to say, the lack of client-server separation + the reliance on nonstandard signalling that is defeated even by one's own broken app-logic

almost everything about blocks in masto is broken, because masto itself makes broken assumptions. more specifically it's conflating authority and responsibility.

the server is leaking info between actors bc it *is* the client. users on shared instances may as well be using the same client, because they are (with ACLs).

@darius @Thib @cwebber if messages were sent to actors instead of instances, then there wouldn't be so many issues with blocks or whether they are explicitly signalled.

mastodon software effectively "knows too much", and this is why it assumes others must also know what it knows.

@trwnh @darius @Thib @cwebber
Maliciousness is not an actual requirement for harmful behavior. It's enough to do unwanted favors with the best intentions. Mastodon makes some compromises for performance and other compromises to support interaction. The sum of these compromises is a problem

First, you cannot send "Reject: Follow" when you mean "Block" because you're still federating block information even if you're not using the syntax described in the spec. You're also expecting the target server to retain that information, which is neither reasonable nor possible to assurance

Second, the origin has to provide explicit routing when message delivery may be affected by information that the destination server doesn't have. If you need to deliver to collections in most cases, then you need to identify the exceptions and handle them at origin

When someone on an instance is blocked by the sender then that instance can't be relied on to expand collections in its shared inbox. I'm not addressing implementation details beyond that. Perimeter security with current practices means that instances supporting vulnerable people need to block instances that allow toxic members or federate with toxic instances. That's what needs to be improved immediately

Maliciousness is a problem, but it's not *this* problem. Vulnerable people are capable of dealing with harmful situations decisively. The problem is dealing with centrists leaking information to harmful people while they waffle about the nature of the threat. If implementations deal with the leakage, theorists have a grace period to work on more comprehensive ways to address active threats

@yaaps [Dropping others because this is off topic]

this is why I am working on my "neighborhoods" concept: small networks of servers that all mutually whitelist one another (a complete graph), where it is increasingly difficult to add further nodes to the neighborhood. The idea is: messages can federate within a neighborhood but don't leave. It's kind of like a federated whitelist instead of a federated blocklist, except the the "federation" only goes to the members of the whitelist

@darius
That's really nice idea for a new scope, assuming that the implementation doesn't limit all public messages to the whitelist scope. That's effectively how Kitty.Town and some other instances with particularly vulnerable populations work. In the absence of whitelist functionality in Mastodon mainline and inability to access alternatives, the admin is hypervigilant (in the sense of the pathology) about new members and instances, curating such a neighborhood. It's a very restful space to belong

I'm setting up email this week, finally, which has been the blocker to setting up my spouse's instance. If there's a testing branch for this before they launch, I can use it. I can also think of a few admins in a position to patch their instances to test it, if you'd like me to tag them

@yaaps I'm still a few months away from making this scope. Maybe 6 months away. And yes the idea is it's in addition to being able to post "public" to the world

@darius
Hopefully loving.ink will be production by then, but I don't mind setting up a test instance

@yaaps @darius @Thib @cwebber Reject Follow is imo distinct from Block and also from Undo Accept Follow

if the Follow is stored (as it should be, since Follow must be Accepted and therefore cannot be transient) then you should be able to send Undo Accept Follow to return that account to the "follow requested" state, and Reject Follow to explicitly deny the request.

>instance can't be relied on to expand collections in its shared inbox

i'd argue this is true *always*, not just with blocks.

@yaaps @darius @Thib @cwebber in short: it is a Bad Idea to deliver non-public activities to sharedInbox, full stop. that cedes access control completely (and access control requires, well, *control*)

@trwnh
Reject follow in the absence of a follow is problematic. There's no problem rejecting an actual follow request or undoing an accept, but in the absence of a follow request it's just an obfuscated syntax for "block" and the obfuscation has been defeated

The expectation that a remote instance maintain a copy of any specific object is onerous, and that is required to honor a preemptive reject follow

Yes, delivery to the shared inbox is the root of many issues. I'm assuming that eliminating or significantly changing the nature of shared inbox is non-negotiable, though

You lose control as soon as data is in clear text on the remote and we're not getting end to end encryption anytime soon with such a large portion of users accessing the service through the browser

Whether it's desirable that ActivityPub be anything other than a deniable and insecure surface layer for negotiating secure connections over other protocols remains an open issue
@darius @Thib @cwebber

@yaaps @trwnh @darius @cwebber Mastodon reject follows along with blocks if there is an existing follow not if there isn't

The “stealth” blocks will not send a Block but it will send a Reject (and an Undo if there was an Accept) if and only if there is a follow request/active follow

@Thib
Okay. I had a misunderstanding that reject follow without an existing follow was being sent (or perhaps considered).

I'll find the source of that misunderstanding later and see if I can get some clarity on how that happened
@trwnh @darius @cwebber

@yaaps @darius @Thib @cwebber all Follow activities are a request by default convention. if your account is unlocked, the Accept is sent automatically. you can't Reject a Follow that doesn't have an id, so there's no such thing as a "pre-emptive" activity.

@yaaps @darius @Thib @cwebber re: "secure connections over other protocols", i find it best to think of activitypub as a wire format. c2s is basically imap and s2s is basically smtp. you can do pgp or autocrypt on top of cleartext if both clients support it (e.g. imagine if your inbox was decrypted in pinafore)

@yaaps @darius @Thib @cwebber
the issue with that would be key management, which right now is done on the server. you would have to sync your keys between clients (and this would have to be protected by some other mechanism, e.g. a password that is not discoverable by your sysadmin -- hashed, salted, etc)

Sign in to participate in the conversation
Friend Camp

Hometown is adapted from Mastodon, a decentralized social network with no ads, no corporate surveillance, and ethical design.