Found this via Aurynn Shaw:
When following someone on a different server on the Fediverse, the remote server decides whether you are allowed to do so. This enables features like private accounts. Due to an implementation mistake, Pixelfed ignores this and allows anyone to follow even private accounts on other servers. When a legitimate user from a Pixelfed instance follows you on your locked fediverse account, anyone on that Pixelfed instance can read your private posts. You don’t need to be a Pixelfed user to be affected.
Pixelfed admins should update to v1.12.5 ASAP, but upgrading can be a major hurdle.
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. Now that server is allowed to fetch all your private posts. And when it knows the posts, it has to decide who to show them. When you accept a follower, you not only place your trust to keep a secret on them, but also on their admin and the software they are running.
Edited to add the last block quote.
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.
audience targeting is NOT a new abstraction by mastodon, it’s part of ActivitySTREAMS, not even ActivityPUB
rtfm and do NOT give a rest to bad behaving software
I did a whole analysis of what the spec actually says, how it relates to “private” posts, and Mastodon’s implementation details. TL;DR they just made things up and it’s a huge disservice to Mastodon users to give people the impression that these posts are private.
linking barely relevant threads is a bit annoying
your complaints on “unlisted vs public” are completely unrelated to the issue at hand
your analysis that relates to this pixelfed flaw is just:
these aren’t good analyses: content should be private by default, nowhere is stated otherwise. if you feel like this common sense practice is somewhat arbitrary, it’s actually mandated by GDPR and more data protection laws.
if you want to rule lawyer that “acktually spec doesnt EXPLICITLY say that you cant show stuff meant for alice to bob if bob asks” and ignore this web good practice (probably implied by the many privacy remarks in the spec but let’s ignore those) which is actually mandated by governments, feel free to still ignore the incompetence displayed by dansup in implementing something that every other fedi software managed, go for it
even if you were right, even if the spec was really that vague, even if it wasn’t a good practice and requirement, in a federation parties cooperate. pixelfed breaking a common agreement is defederation worthy, and dansup remains either incompetent for implementing badly something easy or toxic for federating ignoring what the federation requires
you’re still not addressing the point, just linking other posts back and forth and moving the goalpost
This is completely false. Read section 7.1, “Note: Silent and private activities”. It specifically says that privacy behavior, for activities with no recipients at all, is undefined. It recommends not showing them to anyone, obviously, but that “behavior is not defined” has a very specific meaning in a specification document. It means, if you sent an activity of that type to someone, trusting that they would then keep it private, then you fucked up, because behavior in that area is undefined and cannot be relied upon.
That’s not “rules lawyering.” That is how specification documents work. That’s an important note, which I suspect is why it is highlighted and in its own separate box. There are some similar parts of the document, involving the big word “MAY” in all caps where they had the option of writing “SHALL” or even “SHOULD”, to indicate that a server had to keep certain things private, that follow the same philosophy.
None of that means you can’t use some common sense. It’s obviously not good to be handling intended-to-be-private information in some way that the sender doesn’t expect, and that’s why Dansup fixed it quickly when it was brought to his attention (particularly since the issue wasn’t even directly related to access control on private posts, just in a subtle interaction involving approved-followers-only users and a setting that was failing to federate). My point was just on the broader issue, that if Mastodon is sending out “private” statuses to random servers, then this is at the root a Mastodon issue. The quick fix (regardless of whatever it was about that made the blog poster even more upset when Dansup took it seriously and fixed it quickly) puts the lie to your assertion that Dansup is “toxic” “ignoring what the federation requires” and so on.
I suspect that we’re going to keep going around in circles on this forever. I have a new strategy when someone is just endlessly arguing with me about some weird minor issue. I just make a new post dealing with the issue in more depth, so that it’s not just you and me endlessly going in circles deep in the comments at each other. You’re welcome to come to that post, and continue the conversation there, if you’d like to:
https://sh.itjust.works/post/35210537