Pixelfed leaks private posts from other Fediverse instances
Pixelfed leaks private posts from other Fediverse instances
Pixelfed leaks private posts from other Fediverse instances - fiona fokus
Pixelfed leaks private posts from other Fediverse instances
Pixelfed leaks private posts from other Fediverse instances - fiona fokus
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"?
I looked at your comment before reading this article, and you make several bold statements that the article dispels
A fork of Mastodon created a new abstraction for "private posts"
The author of the article links to the official specification which was made for ActivityPub. This does not appear to simply be "some fork of Mastodon", but if it is, please provide a citation.
they're trying to blame Pixelfed for not adopting their homemade standard
See previous comment
It's fixed in 1.12.5
The article also goes into great lengths about how the security update was handled poorly, with inappropriate communication along the way. It contrasts this with a correct update.
The author of the article links to the official specification which was made for ActivityPub.
Yes. Search that specification for "private." You'll find precisely one reference to it, which doesn't deal in any respect with how post privacy needs to work. It just briefly mentions the concept of follower-only profiles.
I also looked over the ActivityPub spec and didn't find anything. Where are you saying it is mandated by ActivityPub that you need to treat some particular posts special?
I thought it was a fork of Mastodon where this private functionality was first implemented, because the official developers were reluctant to do it (and because often big steps forward come in the forks for whatever reason). I could be wrong about that. Regardless, my point is that they're doing something somewhat nonstandard and unsafe by federating out "private" posts in this fashion, and it's not even slightly surprising that it managed to fuck up in this particular predictable way. Pixelfed is far from the least careful or responsible of the microblogging forks out there.
Mastodon, in general, is regarded as careless with safety. There was some discussion way back when about the implications as far as federating out private content to untrusted servers and some remedies that might strike a good balance. I actually think this article summarized things extremely well:
Something you may not know about Mastodon's privacy settings is that they are recommendations, not demands. This means that it is up to each individual server whether or not it chooses to enforce them. For example, you may mark your post with unlisted, which indicates that servers shouldn't display the post on their global timelines, but servers which don't implement the unlisted privacy setting still can (and do).
Servers don't necessarily disregard Mastodon's privacy settings for malicious reasons. Mastodon's privacy settings aren't a part of the original OStatus protocol, and servers which don't run a recent version of the Mastodon software simply aren't configured to recognize them. This means that unlisted, private, or even direct posts may end up in places you didn't expect on one of these servers—like in the public timeline, or a user's reblogs.
See, that's fine as long as that's the user expectation. There are a lot of visibility settings that are kind of fine as long as a big horde of people doesn't unexpectedly show up. But if, like in the OP article, someone's posting private content and genuinely expecting it to be private, they need to be educated about how Mastodon does post privacy, before they keep doing it and keep getting shocked that it isn't private.
The article also goes into great lengths about how the security update was handled poorly, with inappropriate communication along the way. It contrasts this with a correct update.
Yes, I read it. His opinion that it was handled poorly is wrong. The "security issue" is created on Mastodon's side, and the proper remedy is for it to be widely known among the users that visibility settings are recommendations, not demands. Keeping the idea that this is happening a secret is very bad security policy. I suspect that he's having a performative freakout about the way Dansup committed the change, for whatever reason, but regardless of the motivation, this was exactly the right thing to do: Fix the issue and be open about what version has the fix. The article's demands for secrecy surrounding it, when the underlying issue in Mastodon's federation is still right there ready for any other server software to mishandle, is wrong and creating a bad privacy situation for the users.
I don't understand why people don't understand that AcitivityPub is not a private protocol. Like at all. Its not meant to be and was never meant to be. Any "privacy" improvements from random instances are not part of the core code structure and do not work outside of them 99% of the time.
It's good to be aware of and in general treat anything uploaded to the internet as public, but it also is a bug that the software isn't working right.
It was a poorly implemented feature that was never communicated and when said feature failed to function outside of the specific instance it was designed for, people threw shit. That's not a bug. If anything its an integration failure. A failure that is entirely the fault of the mastodon instance team. Calling it a vulnerability is fuckin wild.
It seems
Any "privacy" improvements from random instances are not part of the core code structure
The privacy improvements are from the ActivityPub protocol. The author cites them.
Edit: ...and the spammer who keeps copy-pasting the same irrelevant spam from thread to thread is back
They're really not.
Here's the relevant docs, and a little summary of how they relate to private posts and Mastodon's specific implementation of them.
Specs: https://www.w3.org/TR/activitypub/#delivery
Mastodon code where you can verify that this is how they are handled: https://github.com/mastodon/mastodon/blob/main/app/lib/activitypub/tag_manager.rb (look at the cc() and to() functions)
Overall summary in detail:
to
, cc
, etc.)sharedInbox
endpointsMastodon implements four primary visibility levels:
to
: ["https://example.com/users/username/followers"]cc
: [] (empty)to
: [array of mentioned user URLs]cc
: [] (empty)to
and cc
fields to indicate intended visibilityto
(public) or cc
(unlisted)I also sent a user-targeted explanation of how Mastodon's privacy settings work, that might be helpful for you to read. You can probably find it in my profile.