I was planning to just give it a rest, since we were going in circles, but you wandered into several additional comments sections and replied to me in all of them with a couple of new arguments, so I decided I would respond.

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:

ActivityPub Specification

What ActivityPub Explicitly Mandates

1. Audience Targeting (Section 5.1):

   • Activities must include audience targeting fields (to, cc, etc.)
   • Servers must deliver activities to the specified audiences

2. Public Posts (Section 7.1.2 and 7.1.3):

   • Activities addressed to the Public collection must be delivered to all followers
   • Servers MAY deliver Public activities to all known sharedInbox endpoints

3. Filtering (Sections 5.2 and 7.1.2):

   • Servers SHOULD filter inbox content according to the requester’s permissions
   • Servers MAY filter delivery targets according to implementation-specific rules

4. Privacy of Non-Addressed Content (Section 7.1 Note on “Silent and private activities”):

   • For activities with no recipients, it’s “recommended” (not required) that objects remain private
   • An activity sent only to the “public” collection should be viewable in the actor’s outbox but not delivered to any actors

What ActivityPub Leaves Undefined

1. Visibility Levels:

   • No explicit definitions for “public,” “unlisted,” “private,” or “direct” as formal visibility modes
   • No mandatory behavioral requirements for different audience targeting patterns

2. 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

3. Timeline Placement:

   • No specification about which posts should appear in public timelines vs. home timelines

Mastodon’s Implementation

Visibility Levels in Mastodon

Mastodon implements four primary visibility levels:

1. Public

   • UI Name: “Public”
   • ActivityPub Implementation:
     • to: [“https://www.w3.org/ns/activitystreams#Public”]
     • cc: [“https://example.com/users/username/followers”]
   • Behavior: Visible to everyone, appears in public timelines

2. Unlisted

   • UI Name: “Unlisted” or “Quiet public” (newer versions)
   • ActivityPub Implementation:
     • to: [“https://example.com/users/username/followers”]
     • cc: [“https://www.w3.org/ns/activitystreams#Public”]
   • Behavior: Visible to everyone but doesn’t appear in public timelines

3. Private

   • UI Name: “Followers-only”
   • ActivityPub Implementation:
     • to: [“https://example.com/users/username/followers”]
     • cc: [] (empty)
   • Behavior: Only visible to followers

4. Direct

   • UI Name: “Mentioned people only”
   • ActivityPub Implementation:
     • to: [array of mentioned user URLs]
     • cc: [] (empty)
   • Behavior: Only visible to mentioned users

Key Implementation Details

1. Visibility Through Addressing:

   • Mastodon uses the to and cc fields to indicate intended visibility
   • The presence and position of the Public collection determines visibility level
   • No explicit “visibility” property is included in ActivityPub messages

2. Convention-Based Visibility:

   • The difference between “public” and “unlisted” is determined by whether the Public collection is in to (public) or cc (unlisted)
   • This is a convention defined by Mastodon, not explicitly required by the spec

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.

Oh, you feel like repeated postings of exactly the same thing is unnecessary? Funny about that, I had a similar reaction.

Hey, that’s a really good point. It turns out I was able to dig up an important thing to read that addresses it, though. Here, check this out:

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

The “security issue” is created on Mastodon’s side

Are we reading the same article? I realize this isn’t the first time you implied this, but I thought I must have been mistaken.

Let me excerpt from this since you seem to have missed it:

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.

Keeping secret that private posts work this way in Mastodon is very bad security. Going past that, to say that someone else is committing a security sin if they make it clear to people that private posts work this way in Mastodon (not even as any kind of announcement, but just tangentially while fixing their own software’s handling of Mastodon’s “private” posts in a quick and complaint-free fashion) is even worse security, which I would say travels into the land of ludicrous counterproductive performative freakout.

Let me paint for you a picture of what might happen if you mislead Mastodon users into thinking that their “private” posts are private:

I created an account on pixelfed.social and clicked follow on my partner’s Mastodon account, and… I could see all of her private posts. Instead of telling me I’d have to wait to have my follow accepted, I was already following her.

“Oh no, not again”, I said, dreading the thought of spending the next few hours reading PHP code and writing a report.

Sort of implies it’s happened before. I would not be surprised, of course. Want me to quote the important part to understand again?

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.

That’s an important thing for you to read. I linked you to it, and then quoted it, but it didn’t seem to stick, so I’m sending it again.

I’ve said as much on this topic as I feel like saying.

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.

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”?

If you care about privacy, don’t use biometrics.

It is sad because it is less convenient, but that’s what’s up.

Yeah. At best, it is clueless.

I think it’s maybe possible that they have a thriving community on Reddit, and not much interaction with people on Mastodon, and they can’t afford to invest the time to pay someone to maintain both, and so some middle-manager who’s not exactly a tech and privacy expert decided to go with the more active one.

You’re completely right though. Even in that super-charitable fantasy scenario, it would have been better to shutter the Reddit community, explain to the thriving community why they would be better served by a different platform, and keep going on Mastodon even if it’s something like 5 people.

It’s not just the resources to mirror posts, it’s also the resources to keep up with communicating with the community, answer questions, maintain a positive presence. It’s not trivial.

I do sort of agree that it’s insane for any privacy company to be emphasizing Reddit over Mastodon. If anything, the limited resources should motivate them shutting down Reddit and keeping Mastodon. But it’s not as totally stupid an explanation as it might seem.

It’s also notable that Reddit’s features make it a lot easier to communicate with tons of people in a genuine way, with minimal effort (since it’s good at surfacing high-voted comments and letting you engage with those people). As well as making it easy to silence anyone who is saying anything you don’t want them to say, of course.