I wouldn't call it Pixelfed's vulnerablility, but a reminder that nothing on Fediverse is private. Even if Pixelfed is fixed, someone can create rogue instance to read other's private posts.
this post was submitted on 26 Mar 2025
162 points (96.6% liked)
Fediverse
32310 readers
278 users here now
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).
If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!
Rules
- Posts must be on topic.
- Be respectful of others.
- Cite the sources used for graphs and other statistics.
- Follow the general Lemmy.world rules.
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration)
founded 2 years ago
MODERATORS
If I understand it correctly, it's kind of both. Sounds like Pixelfed didn't follow best practice setting privacy guardrails in follow request approval, and it exacerbates the inherent lack of privacy on the fediverse.
You're right of course, anyone (with the coding chops) could've intentionally set up an instance that does the same for malicious purposes. That should be a wake-up call for anyone who thinks ActivityPub is a great sexting medium.
I dont know about other fedi services, but lemmy tells you at message composition, that DMs are not safe/private. If pixelfed doesnt do this, then that is really the issue.
receiving posts is trivial but you need to convince others to send it to you. i can't just set up a malicious instance and get your private posts, i need to convince you to send them to me, and once convinced i can use any normal software to access it, no malicious custom thing needed. literally just follow me from a mastodon.social throwaway and you get my followers-only posts. content addressing is great on fedi and your instance sends your private posts exactly to who you want and noone else. pixelfed receives a private posts and shows it to third parties, its not the system's fault.
fedi is not great for sexting because your pics just sit in clear on your server admin's machine and all dms are easily searchable on db, it's a whole other issue
The whole point of this issue with Pixelfed is that none of what you describe is required.
Find any follower of a Fediverse account of any kind (Target Account) that's on a Pixelfed server. Go to that Pixelfed server, view "private" posts from Target Account there.
No need to set up a server, or get sent anything. Granted, even without this flaw ActivityPub is not the way to go for anything private.
load more comments
(1 replies)
I kinda of lean towards the idea of "private accounts" being a bad idea as a result, just because it creates a false sense of security. But I'm not in the target demographic so idk
Yeah this just sounds like one of the drawbacks of a federated system. In order for people on remote servers to be able to see your "private" posts, your local server has to feed that info to them and trust them to handle it appropriately.
Wait, are new instances federated by default?
I thought admins had to choose who they were federated with.
There's easily over a thousand fediverse instances at this point, having to whitelist them all would be impractical.
Okay but this demonstrates why defaulting to federation is a bad idea, doesn't it?
The issue is that if you don't default to federation, it becomes essentially impossible for new instances to join the fediverse. A potential new instance would have to go around to every single existing instance and ask to be allowlisted, which is onerous for both the new instances and for the large server admins who would be getting tons of requests. It would also essentially kill small-scale selfhosting as a result.
The entire point of the fediverse is to federate. Not federating by default kills discoverability and the potential for discoverability among other things
It demonstrates that nothing on the fediverse is private, and bad hacks that pretend otherwise are a terrible idea.
Imo it demonstrates that for certain threat models the fediverse simply doesn't have the 100% secure answers.
load more comments
(1 replies)
The private account would still need to accept a follower from that rogue instance.
Yes, but account/instance would need to actively research which instances are rogue, and beware of them. It could be solved by creating tool which would automatically detect this ~~vulnerability~~ feature.
If you have a private account, why would you accept a follow from a user on a rogue instance?
I guess you would need to trust your friend to vet whatever instance they join. And you’d have to vet that you aren’t getting catfished by a threat actor using a friends identity but those are all problems regardless of whether that’s fixed since a malicious admin would have access to your posts so your friend can subscribe to them in the first place, whether this is fixed or not
Edited to add: I got this around the wrong foot, see the reply to this. /edit
Not necessarily, as clearly stated in the linked article:
But sure enough, the toot was followers only and the person that had liked it was not following her Mastodon account. When I took a look at the other persons profile on pixelfed.social, I noticed that the instance was nevertheless claiming the account was following her.
When pixelfed assumes that an account is not locked, it immediately treats a follow attempt as completed. For the server on the other end it looks like a normal follow request. It could be rejected, and pixelfed would still be convinced that a follow relation exists.
Abolutely necessarily.
it works like this:
@privateuser@mastodon.example.comhas a "followers only account".@someuser@pixelfed.example.comis a friend of above account, requested access and was granted. This now causesmastodon.example.comto push all messages of@privateusertopixelfed.example.com.@anotheruser@pixelfed.example.comrequests access, but gets ignored. But the pixelfed instance marks the user as "follows@privateuser"- In the interface of
@someuser, the messages are shown as expected. - In the interface of
@anotheruser, they are also shown. Because PF basically does a database "select messages of users that the user follows", without checking if the access was ever granted.
Important to note, that this would not happen, if the messages weren't already pushed to the server due to the "allowed" user
Yes, necessarily.
Importantly, your Mastodon or GoToSocial instance isn’t handing your private posts to any random server, just because it asks. The problem only becomes apparent when you have at least one legit accepted follower from a Pixelfed server
Ah, good catch. Thanks!
load more comments
(18 replies)
Some more US war plans?
Whut. I mean, probably, but not in this thread?
well that's not good
Nope. It looks like crash testing security in production, or "fuck around and find out" with other people's privacy.
I didn't even know "private" posts were a thing on the fediverse but now I guess I know to watch out for that. Maybe I'll post some privates after losing about 30 lbs
does it only effect privates? what about officers, like, say, captains?
Its like email, if a server decided that it would expose everyones emails, everyones emails are exposed.
Give it a rest. A fork of Mastodon created a new abstraction for "private posts" and started sending to instances some posts that were marked in a new way as "private," and now they're trying to blame Pixelfed for not adopting their homemade standard for what posts their servers are sending out to everyone that they're not supposed to show, and what ones they are supposed to show. And, Pixelfed fixed it once they became aware of the issue.
It's fixed in 1.12.5. Why is this not titled "Mastodon instances claim to their users to offer 'private' posts but send them out exactly like normal posts, get surprised when software that hasn't magically adopted their new standard is showing them to people"?
Honestly pixelfed should have just not fixed it. It's a fediverse problem that can be fixed and mastodon is just misleading people.
Platforms should either make it clear that it means just that the post isn't advertised by default on all platforms but is always accessible to anyone that wants it or actually implement e2e encryption.
I'm not sure I would go that far. A lot of "trust and safety" type things are like this, just soft boundaries to try to shape the types of interactions people are going to get themselves into to be a little more on the pleasant side. There's nothing wrong with Pixelfed trying to show some honor to the same advisory boundary. The real problem comes into it when projects like Mastodon start giving people the impression that "private" posts that are federated out are going to be able to stay private. As long as the user expectation is clear that it's just an advisory setting that will tweak the algorithms for showing the post in non-assurable ways, it is fine.
load more comments
(4 replies)
view more: next ›