Pixelfed leaks private posts from other Fediverse instances
23 points by strugee
23 points by strugee
Also, if someone on a server follows you, that other server’s admin can also read everything because they are the admin.
I think the point here is that, while that’s technically true on all ActivityPub servers because the admin can just go look in the database, Pixelfed has a bug where those posts are displayed in feeds, search (if set up), etc.
That’s like, many orders of magnitude worse.
This seems systemic? What’s to stop me from reading “private” posts by deliberately writing a badly behaved server that does this? Moreover what’s the point of “provate” posts if I have to trust an unknown third party to behave nicely in order to keep them that way? It feels a little odd to call them that if my server is expected by protocol to send them to anyone who asks.
It feels less like a leak and more like a garden hose spigot on the side of the house that we only realized existed when a neighbor left it on, and we’ve reprimanded the neighbor and they said “sorry, I’ll be sure to turn it off when I’m done next time”
Email is the same: when I send an email to someone that uses some email server, in fact the receiving email server (or my own) could leak my email to anyone. But I generally trust email servers to not do that, to respect the privacy of my communication with that person. (For very sensitive information we would use encryption or some other approach, but for everyday communication humans tend to rely on more vague notions of privacy.)
If say gmail suddenly let everyone with a gmail account read the emails I sent to one specific group of gmail users, we would say that it’s a bad security flaw that gmail must fix immediately – and it would be a big deal in practice.
(Or: we wouldn’t appreciate our phone provider letting its other customers read the SMS messages we received.)
I don’t understand why the reaction here is so different – not just your post, but several comments. Maybe it’s because the author carefully explains the issue and the inner workings of ActivityPub in their post, so that the systemic issues are immediately visible, whereas we don’t typically think of other communication platforms this way.
Obviously for any insecure communication protocol a malicious server is a trivial threat, but i think the comparison to a malicious mail server isn’t quite right.
It’s more a mail server that allows random users to sign up to receive your mail as well, which would be much more overtly “this is wrong” to anyone who discovered it.
The badly behaved server needs at least one approved follower for the sending server to actually send. Not quite that simple to abuse, but still bad enough.
It seems misleading to call something ”private” when it works the way it does, especially today when the expectation is that anything private is end-to-end encrypted. They should at least call it something else.
Sorry to knee jerk react to this, but “followers” only activities/posts are not “private”. The actors in the followers list should be allowed to view that activity/post, which is what I understand from TFA as being the problem.
Could be that the issue is with the way the following flow works, or doesn’t really work, on Pixelfed. But for that case I think the title is misleading.
[edit] And I feel like holding one man projects to the full sec-ops and vulnerability disclosure standards is a bit of a fallacy. Furthermore to quote from the license file:
THERE IS NO WARRANTY FOR THE PROGRAM
[edit] And I feel like holding one man projects to the full sec-ops and vulnerability disclosure standards is a bit of a fallacy.
I don’t. If your project is handling a large amount of people’s personal information, you have a responsibility to take that seriously.
IMO you have two options: either participate in responsible disclosure, or clearly mark your project as not having the resources to do so. If you’re not going to do security right that’s fine, open source comes with no warranty, but you should inform your users of the risk they’re taking by using your software. And presumably some nontrivial portion of users will decide not to take that risk.
What’s particularly damning here is that the reporter specifically asked the maintainer to wait and coordinate disclosure timelines, and the maintainer ignored the request.
[edit] And I feel like holding one man projects to the full sec-ops and vulnerability disclosure standards is a bit of a fallacy. Furthermore to quote from the license file:
THERE IS NO WARRANTY FOR THE PROGRAM
This applies to pixelfed, the source code. But Dan also runs pixelfed.social, the service, where he actually accepts and handles personal data, participates in the fediverse by federating servers etc. There’s a legitimate expectation to admins to keep their instances secure, moderate them and remove spammers and such and such. Part of that is that federating parties can expect ActivityPub to be implemented properly.
This is particularly because while a user of the pixelfed source has the ability to patch the issue by themselves, users of the service do not.
Finally, Dansup finances his livelihood with those activities.
Dansup is also not a nobody and known for abrasive behaviour. I would not shield that due to a license.
Followers-only posts are private when your account is set to require approval for followers
I’m willing to believe you when it comes to the Mastodon/Pixelfed API, but from an ActivityPub point of view - which is the domain I’m knowledgeable about - if an Activity has been published to a followers list, theoretically all the people on that list should be able to access it at a later point, therefore making it not “private”. “Private” is only when all the recipients of an Activity are individually named.
Pixelfed was leaking followers-only posts to users not in the author’s followers collection.
I don’t read the article like that though, maybe I misunderstood. To me it seems like the activities that people have access to are the ones that were sent while they were following the person. Those end up in their inboxes and without a specific action on the part of the author (like a delete), they’re there to stay.
The core issue here is the different instances disagree on whether one account is following another.
Effectively:
alice@mastodon is an account set to require approval of new followers, and all its posts are set to followers-only visibilitybob@pixelfed has sent a follower request to alice@mastodon and alice@mastodon approved iteve@pixelfed has sent a follow request to alice@mastodon but alice@mastodon has not approved this follow request
pixelfed treats eve@pixelfed as a follower of alice@mastodon
So both instances think bob@pixelfed is a follower of alice@mastodon, and that is correct. But instance mastodon thinks eve@pixelfed is not (yet, anyway) a follower of alice@mastodon while instance pixelfed thinks eve@pixelfed is a follower of alice@mastodon. The contention here is that pixelfed is incorrect.
If there were no other approved followers (in mastodon’s opinion) of alice@mastodon on instance pixelfed, then instance mastodon would not allow alice@mastodon’s posts to be sent to pixelfed. But because there is one such approved follower – bob@pixelfed – mastodon does allow alice@mastodon’s posts to go to pixelfed. But then pixelfed, which incorrectly thinks both bob@pixelfed and eve@pixelfed are followers of alice@mastodon, delivers the posts to both of them instead of only to bob@pixelfed.
Oh so an instance won’t forward (or provide on request) any “private” (follower only? vs pseudo DM) messages to another instance if there are no followers from that instance, but once there is one those messages necessarily get forwarded and it’s up to the other instance to ensure those “private” messages only get shown to the correct people?
(Incidentally are DMs at least semi-private now? - eg do accounts include public key info that permit a message to be sent such that at least it’s only the receiving instance capable of decrypting?)
So, yeah, as I understand it, once a person on a given instance has at least one follower on another instance, their posts get sent to that other instance and it’s the other instance which decides who to deliver them to.
There is still no such thing as a real “DM” as far as I’m aware, still just the “only people mentioned” visibility setting which is of course full of footguns.
You’re misunderstanding. The problem is that if a followers-only e.g. Note gets delivered to pixelfed.example/inboxes/a, it is automatically visible (in search, explore feeds, etc.) to someone whose inbox is pixelfed.example/inboxes/b, regardless of whether that person is following the author of the Note.
Also, this makes me consider adding a mechanism of handling ACLs for individual posts in my ActivityPub library. So thank you Fiona. :)
Fundamentally ActivityPub just can’t provide meaningful privacy and shouldn’t even be trying.
I get that it’s probably a protocol efficiency thing to not fetch posts with user credentials, but that means that privacy doesn’t exist at all.
The only way I can see this actually working correctly in the future is if private post content is encrypted, and an approved follow request gets you the necessary key(s).
Sorry I’m unclear on this (because my understanding of mastodon means there is no actual real private communication).
Is this talking about “private mentions” (the pseudo DMs) or “only show my posts to people who follow me” setting?