Comment on Pixelfed leaks private posts from other Fediverse instances - fiona fokus
iltg@sh.itjust.works 4 weeks agolinking 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:
Privacy Enforcement:
- No explicit requirements for how receiving servers should restrict visibility based on audience fields
- No requirements that servers must hide content from non-addressed users
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
PhilipTheBucket@ponder.cat 4 weeks ago
This is completely false. Read section 7.1, “Note: Silent and private activities”. It specifically says that privacy behavior, even 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:
sh.itjust.works/post/35210537