There’s a significant distinction between servers that are actively malicious as you’re describing and servers that aren’t fully compatible with certain features, or that are simply buggy.
Lemmy, for example modifies posts federated from other platforms to fit its format constraints. One of them is that a post from Mastodon with multiple images attached will only show one image on Lemmy. Mastodon does it too: inline images from a Lemmy post don’t show on vanilla Mastodon.
I’ll note that Lemmy’s version numbers all start with 0. So do Piixelfed’s. That implies the software is unfinished and unstable.
PhilipTheBucket@ponder.cat 3 weeks ago
This is backwards in my opinion.
What you described is exactly how it works. Everything in the network is potentially badly behaved. You need to put on rate limits, digital signatures for activities back to actors, blocks for particular instances, and so on, specifically because whenever you are talking with someone else on the network, they might be badly behaved.
In general, it’s okay in practice to be a little bit loose with it. If you get some spam from a not-yet-blocked instance, or you send some server a message which it has a bug and it doesn’t deliver, then it is okay. But, if you’re sending a message which can compromise someone’s privacy if mishandled, then all of a sudden you have to care on a stricter level. Because it’s not harmless anymore if the server which is receiving the message is broken (or malicious).
So yes, privacy is different. In practice it’s usually okay to just let users know that nothing they’re sending is really private. Email works that way, Lemmy DMs work that way, it’s okay. But if you start telling people their stuff is really private, and you’re still letting it interact with untrusted servers (which is all of them), you have to suddenly care on this whole other level and do all sorts of E2EE and verification stuff, or else you’re lying to your users. In my opinion.
iltg@sh.itjust.works 3 weeks ago
taking care of bad servers is instance admin business, you’re conflating the user concerns with the instance owner concerns
generally this thread and previous ones have such bad takes on fedi structure: a federated and decentralized system must delegate responsibility and trust
if you’re concerned about spam, that’s mostly instance owner business. it’s like that with every service: even signal has spam, and signal staff deals with it, not you. you’re delegating trust
if you want privacy, on signal you need to delegate privacy to software. on fedi to server owners too, but that’s the only extra trust you need to pay
sending private messages is up to you. if i send a note and address it only to you, i’m delegating trust to you to not leak it, to the software to keep it confidential, and to the server owner to not snoop on it. on signal you still need to trust the software and the recipient
this whole “nothing is private on fedi” is a bad black/white answer to a gray issue. nothing is private ever, how can you trust AES and RSA? do you know every computer passing your packet is safe from side chain attacks to break your encryption? you claimed to work in security in another thread, i would expect you to know the concept of “threat modeling”