So apparently as a default feature Pleroma has an option to circumvent and ignore blocks.
Can someone make me a version of the gab-blocking code for Pleroma, please? I suddenly feel very unsafe.
Pleroma has become a MASSIVE security issue for vulnerable people, for targets of harrassment and stalking. Kaniini is going full mask-off fascist here, in enabling online abuse and I'm going to have to say that they need to get in the fucking ocean with their attitude towards other's safety and lives.
Kaniini is a fascist who is enabling fascist abusers and defends it in the flimsiest of ways #mastodev
still pissed about pleroma devs being fash
@Pyretta When I have pointed this out, I have been told that Kaniini is trans and/or native american, and hence it is logically impossible that they are a fash enabler.
still pissed about pleroma devs being fash
@ansugeisler the good ol black friend defense, huh? Uncle Toms were a thing, y'know.
still pissed about pleroma devs being fash
@ansugeisler (inb4 someone says i can't say that cause I'm white, i'm not claiming anyone here is an Uncle Tom, but there's a historical precedent for minorities betraying their own)
@Pyretta Ok, so let me make sure I understand this.
AP works, by sending toots between servers automatically, if the two servers know they exist.
AP still sends toots to servers if some users have been user-blocked, and it's on the receiving end to uphold that.
Problem 1 is Pleroma not honoring user-blocks.
@Pyretta And problem 2 is Pleroma sharing toots between them, making it possible to get toots even from instance-blocking instances?
@octet33 No, no problem 2, just problem 1. All instances share all toots, blocks or not (aside from instance blocks)
So enforcing a block is as simple as just not giving toots to the pleroma instance?
There's no leaking from unblocked instances to blocked instances?
@octet33 Yeah, but if user A on Instance A (which federates with Instance B) has user B on Instance B blocked, user B can just stop honouring blocks with this pleroma feature and see User A's toots anyway. If Instance A blocks Instance B, then it no longer works. . . until content federates to Instance B through Instance C from instance A
@Pyretta So toots I'm'a have to get the Whiteboard.
@octet33 so unless your federation is airtight, people can read your toots because federation leaks and they can just stop honouring blocks thanks to the Litigation Bunny and the other asshole pleroma devs.
@Pyretta So this isn't malicious sharing between pleroma instances, but rather an inherent security flaw of AP affecting all implementations.
So only instance B would need to be Pleroma for problems to result?
@octet33 If instance B is pleroma then users on that instance can read through personal blocks if they like. Instance blocks usually get circumvented by federation unless a concerted effort is made (like with Gab).
@Pyretta There could be another solution through protocol modification, if federation from C was merely a reference to A (rather than a copy of the toot), but that'd still require buy-in.
Frankly, I'd imagine that any competent admin would be scared half to death of block circumvention.
@octet33 Yep! Block circumvention is way too easy, lots needs to be fixed before it's even remotely safe. I guess you would have to attach "do not federate to these instances" data to toots as they get federated out, so any pull request by a blocked instance gets denied by any instance, not just the parent instance of the toot.
@Pyretta In other words, AP wasn't ever designed for security and that's suddenly a massive problem that could render the entire protocol unusably unsafe unless community-level resolutions are implemented.
Kinda like MS Windows.
Someone needs to come up with an alternative federation protocol.
@octet33 AP was never designed for security, then Pleroma came along looking to deliberately exploit that and just what the hell.
@Pyretta It's like when the first computer viruses were written and did MASSIVE damage and even still, on many operating systems the best security measures are just finding programs that look like they might be malicious with AV scans (rather than systems to ensure a virus can't cause problems).
@Pyretta The only truly perfect alternative is centralized moderation (e.x. Birdsite), and that only works if the moderators are reliable (which is impossible at the scale of Twitter, or probably even the entire Fediverse.)
@octet33 Twitter is okayish security wise (you can see around blocks if you log out and you know someone's @ and they're not a locked account) but the moderation and algorithms and advertisement are downright hostile.
@Pyretta Yeah, that's what I meant by centralized moderation requiring reliable moderators.
AP trades easier selection of moderators (and smaller-scale moderation), for less technical security.
@Pyretta Wait what ? Oo
@Ambraven The main dev, Kaniini implemented it because "blocking is broken anyway"
@abgd @policeinchains @Ambraven Yes it does, because pleroma instance A may be blocked by Mastodon instance A but if it isn't blocked by Pleroma instance B and Pleroma instance B still federates with Mastodon instance A, Pleroma instance A can still populate its federated timeline with public toots from mastodon instance A.
@abgd @policeinchains @Ambraven Masto instances will pull public toots from anywhere, but it will check if you're blocked by the OP of the toot before serving it to you. (Or the clientside sees that you're blocked by the OP of the toot and hides it from you, i'm not quite sure). Pleroma has an option to strip this all out.
@Pyretta because of the way federated blocks work the people on k**ifarms were able to track people who block them, which gave them more opportunities to harass people from other accounts. that actaully happend and it’s disturbing. both federating and non-federating blocks are valid options with upsides and downsides. do not see how that makes kaniini a fascist
@Pyretta ok let’s explain this slowly, since it’s a common yet invalid complaint
when you block someone from mastodon/pleroma, your instance will store “pyretta has blocked meaniemaster” next to your profile record
if you have federating blocks turned on, your instance will tell meaniemaster’s instance that you have blocked meaniemaster. please unfollow meaniemaster from this account. the server can behave badly here and tell meaniemaster “hey you just got blocked by pyretta” - he can tell his friends, and they can all be meanies in backlash
if you have federating blocks off, or the other instance chooses not to listen to block messages (“circumventing”, as you put it), your instance still knows that you blocked meaniemaster. he just won’t know that fact.
no matter which of the above actions happen, your instance will know that you have blocked meaniemaster and will not send your statuses to his instance, nor show you anything he sends to you
in reality, provided you trust the instance you live on, blocks will behave entirely as expected. the use case for turning them off is as @epicmorphism xplained - it’s to keep the blocked user in the dark as to what has happened.
@Pyretta Wow, that's no good! Thanks for making me aware about this issue in Pleroma services.
@Pyretta I thought you could manually block instances as an instance admin and your instance just won't send anything to them
@Pyretta like, the gab block thing is just automatically added to that list, so doing that yourself for your instance is the same thing afaik
@efi ahahahahaha no. Federation circumvents that because while my instance won't send anything to that instance, another instance I *do* send to might, and then the only thing stopping people on that instance is the client-side saying "this person has you blocked so I'm hiding this" and kaniini thought it would be lulzy to make an off switch for that (enabling creeps like kiwifarms who popped up on pleroma to stalk people through blocks)
@Pyretta yeah, but I was talking about the code you referred to that blocks gab
@efi well it means that any time a gab instance tries to pull from my instance, it just gets the line shut on it and it doesn't get to pull.
@Pyretta that still doesn't help with federated messages
@efi most masto instances have that now so they won't give content to gab either. Pleroma with its allowing you to spy on people that have you blocked has become just as much of a security issue that needs collective action like that.
@Pyretta ah, you're talking about blocking pleroma instances? I misread, then
@efi Yes. If they're gonna present a safety risk like that then yes.
@Pyretta ignore me, I thought we were talking about a different thing
A home for those who're trying to be better people- hence, afterlife.