Comment on Pixelfed leaks private posts from other Fediverse instances

Vendetta9076@sh.itjust.works ⁨2⁩ ⁨weeks⁩ ago

• LWD@lemm.ee ⁨2⁩ ⁨weeks⁩ ago

  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.

  source

  • PhilipTheBucket@ponder.cat ⁨2⁩ ⁨weeks⁩ ago

    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: www.w3.org/TR/activitypub/#delivery

    Mastodon code where you can verify that this is how they are handled: github.com/mastodon/mastodon/…/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: [“www.w3.org/ns/activitystreams#Public”]
         • cc: [“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: [“example.com/users/username/followers”]
         • cc: [“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: [“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.

    source
• MangoPenguin@lemmy.blahaj.zone ⁨2⁩ ⁨weeks⁩ ago

  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.

  source

  • Vendetta9076@sh.itjust.works ⁨2⁩ ⁨weeks⁩ ago

    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.

    source