Egregoros

Trusting Trust in the Fediverse

A very long blog post about the various "safety and privacy" features that got added over the years to ActivityPub and how useless they can be in the eyes of users unaware of the inner workings.

There's nothing really new I talk about, but it is a long explanation of my reasoning behind why I don't take "features" such as signed fetches and interaction consent seriously. What can be considered "new" to most, is the last section of bypassing signed fetch enforcement without impersonation, which I talked about probably twice over the years.

https://evilmaid.net/blog/trusting-trust-fediverse/index.html

(If there are styling issue, tell me. I've written the CSS from scratch, and I suck at it.)

Trusting Trust in the Fediverse

A very long blog post about the various "safety and privacy" features that got added over the years to ActivityPub and how useless they can be in the eyes of users unaware of the inner workings.

There's nothing really new I talk about, but it is a long explanation of my reasoning behind why I don't take "features" such as signed fetches and interaction consent seriously. What can be considered "new" to most, is the last section of bypassing signed fetch enforcement without impersonation, which I talked about probably twice over the years.

https://evilmaid.net/blog/trusting-trust-fediverse/index.html

(If there are styling issue, tell me. I've written the CSS from scratch, and I suck at it.)

@phnt Great post, thanks. I'm in the process of drafting a FEP for GTS interaction policies (collaborating with the team, since they said they weren't going to submit one), so the criticism is useful.

I can't say it's shifted my thinking on the feature much, but then I am in the technical weeds. I think of interaction policies as a way to declare & federate filters, so benevolent and willing servers can play along with them.

This is my current draft for the FEP summary, does it sound sensible?

@julian I think it accurately describes what it does, or at least tries to do. So in that way, I think it is very sensible.

My main issue with the extension besides it being rather complicated, is that I think users aren't aware of what it can't do. It's not apparent to users that it effectively hides interactions that happened from them in GTS, nor that it may not work as advertised. For the latter, a user has to click on the link in GTS settings, and only at the end of the section does it mention, that it is done solely on best-effort basis. You summary is upfront about it, which I think is a good thing.

@phnt I think I follow, yeah.

The flipside to that is it arguably takes two to have an interaction. If I write a post replying to yours, and you don't see it (whether because of an interaction policy or an account mute), the only meaningful difference between “hiding” and preventing interactions is that I don't get to know that I'm invisible to you.

But since current fedi platforms assume reply delivered = reply accepted, if we want reply controls, we need to break that assumption eventually.

@phnt Of course the difference between a mute and an interaction policy is that others can use the latter to replicate the effects. So people on servers that honor them might have a different view of a thread compared to servers that don't.

However, as best as I can tell, that isn't a weakness of the GTS approach, but applicable to any attempt to introduce reply controls into a network without them. So we're either coping with that or giving up.

Agreed that it needs good UI and explanation.

@julian It isn't a weakness of GTS that the network is the wild west and might not honor their extension, they can't really do much about it. Same with any extension in ActivityPub really. I find it kinda sad that we are implementing extensions to reduce the social aspect of a social media protocol though.

That said, if projects like NodeBB gain more traction, reply controls might be a good way to control things like thread locks, or thread reply controls in a federated way. In that way, I think this is a good extension in that specific context.

@a

this is backwards -- to:Public = "public", cc:Public = "unlisted"

Will fix, thanks.

generally it doesn't matter if to/cc is used for the followers collection. what actually matters is that to/cc does not contain Public again to/cc doesn't matter here, a "direct" post is simply one where every audience member can be mapped to an account instead of a collection or unknown

Technically that is true. That would be a more lenient case of what I wrote. But I think Mastodon uses the more rigid way of addressing where FO is using to for both mentions and Collections. And DMs are the same except the follower Collection is gone. It also makes more sense that way, you aren't carbon-copying your post to your followers, you are actively addressing it to them via the Collection. If the Collection didn't exist, cc would be the appropriate place for all the Actors in that case I think.

I'll think about it, if I can reword it a little bit to be more open, but I don't really agree that addressing should be inferred the way you are describing. Another reason for being more strict in the addressing inference is because you cannot add more scopes as easily. At least not by inventing new URI similar to as:Public, like ak:Bubble for addressing Akkoma's bubble thing. The URI would have to be specific to that instance for it to work, but point stands. (I don't think bubble addressing should exist either btw.)

@a

>i think this is a consequence of the federation model and not the software per se -- nothing new here, it's all ancient history for irc.

It is a consequence of decentralized networks. You cannot blame the software for doing something the protocol it is using never guarded against, nor can it really guard against it properly. My point was that when a user from a centralized social media comes to Fedi, they expect it to work that same, ie. You cannot reply to a post that has replies disabled, you cannot ignore blocks etc. But that is simply not possible here. When you see Mastodon giving you an FO scope option, a user thinks that only the followers will be able to see, but the reality is simply not that, anybody can view the post if they know where to look at.

It's this creation of a false sense of safety that I don't like. I get that if you put a warning next to the FO scope, that it in certain cases it can leak to the public, it isn't a great look, but it's the reality. And you cannot hide from that. You are effectively gaslighting your own users by ignoring it.

>...similar, i guess? not exactly the same.

Last time I read the FEP, they were using the same thing as GTS I think. A Quote Activity instead of Create(Object(Note)) and QuoteApproval as the validation. Except that difference it works the same way, doesn't it?

>i don't think you talk about Block activities and how they shouldn't be federated but often are, but this problem already occurs.

No I don't talk about that, neither do I really know what the issue is. I guess that if you block someone, they learn about it? But that is the whole point of it when compared to mutes. On Xitter/Bluesky, if you block someone, they cannot view your posts, or reply. Mastodon does the post hiding, not sure about the reply. For that to work, you have to federate it. And of course if you block someone, you expect the possibly existing follow relationship to also be severed. For that to work, you also have to federate it. Another issue can be blockbots I guess. But I think that's the same issue, but in a different gift wrap. Instead of learning about the block by looking at someone's profile, you get a notification.

Muting simply hides the user for you and both have vastly different use cases at least for me.

>interactionPolicy

That is not the way I see it marketed. I don't see it marketed as a way to mute harassers, I see it marketed as a way to stop "replyguys" from talking to you, or attempt to stop harassment. Similar to how you can lock your threads on Twitter where only your followers can reply. I see it as a GTS attempt on that feature. That is what the first sentence in the "Danger" box means to me at least. If it was advertised as a mute, I wouldn't have much problems with it.

Speaking of Collections and reconstructing threads based on that, it could work for missing parts of a thread your instance does not know about, but you would also have to eliminate the usual way of federation for that. Another instance would still learn of an unwanted reply when it gets pushed to it. In that sense, it's not a good solution I think. What would work though is a simple "replies" Collection of approved replies to the parent. That would also eliminate the need for the dumb validation dance, since if you request the parent once after receiving a reply to it, without knowing about the parent, you would have the validation right there and included. Approval revocation would be federated the same way as other updates to a Collection get federated, namely the "featured" one.

>this is called a proxy

That is true, but proxy has a wide meaning. nginx is a proxy, squid is a proxy. That's why I gave it a name, although a kinda stupid one. To differentiate between the meaning of everything else.

@a
>It's this creation of a false sense of safety that I don't like. I get that if you put a warning next to the FO scope, that it in certain cases it can leak to the public, it isn't a great look, but it's the reality. And you cannot hide from that. You are effectively gaslighting your own users by ignoring it.

This is also btw the reason why I don't think scopes like this should even exist. FO is badly designed and nothing can improve it. And FO scope using Conversation Containers fixes issues with this, but also much more limits the visibility of a post. Depending on how you look at it, the latter can be better or worse.

@a Decided to instead do what Mastodon does, since that's what most of the network is. And since it's always Mastodon. That section now is as follows.

Differentiating between scopes can then be done like this:

• Public - to has as:Public
• Unlisted - cc has as:Public
• Followers Only/Locked - Followers Only/Locked - Actor's followers Collection is either in cc, to, or both, and as:Public is in neither
• Direct - Actor's followers Collection is neither in cc or to, cc and to have only Actors, and as:Public is in neither

It can be more complicated since different scopes than that are being used, but this is the gist.

As a side-effect I think it is also more readable.

>if you wanted to, the bubble thing could be done with collections

That would be ideal and that was also my intention. Issue is how you indicate it properly as a new scope without doing dumb things. You introduce a new special URI (ak:Bubble) that when dereferenced gets you a Collection. The jank would be, that cc/to would have something like https://ak.example.com/ns/extensions#Bubble, and GETing that URI would give you an AP collection. Not really a fan of how that would work, but you don't have much options. Doing it the Misskey way of inserting _akkoma_audience: "Bubble" to the Object is even dumber.

There is probably a better way, but I can't think of one right now.

@a

>and they only do this for canQuote (no support for canReply, canLike, canAnnounce, whatever)

That makes mostly sense. Guarding who can Like and Announce is kinda dumb imo. Especially on a network that tries to be social. I understand why it exists, but I don't think the reason justifies its existence.

>it's why i think a block is better off as a local policy like a firewall, where you just drop incoming activities

It already is mostly that outside the Mastodon™ world. And I agree that it should be something like a firewall, mostly because you cannot dictate how others see their own view of the network. You can only do it on a best-effort basis and hope everybody abides by your rules, which creates these issues.

>right, the way it's being presented and "advertised" is the issue that prompted you to write the post i would surmise

There were two motivations. One was the signed fetch one, which I had in mind for over a year now, including the hidden fetching proxy. The second one was the GTS interaction policies, the discourse around Mastodon implementing it and how they basically disregarded most valid criticisms of how it works. I think that having an "approved Like/Announce/Reply" collection in your Objects would be much better than the current *Approval Activity dance and the dumb "result" -> "approvedBy" URI. When you don't know about the referenced Object, you simply fetch it and the correct approvals are already there. And if you know about it already and receive a new Activity referencing it, you refetch the Collection. Approval recovation would then simply be a "Remove" Activity like when you update pinned posts. I think that is much simpler than what GTS/Mastodon do.

>personally i keep thinking about the cwebber quote "we must not claim to prevent what we cannot prevent" -- the ideal language here is something that makes it clear it's just "observers will ignore you" instead of "your interaction will not exist"

Absolutely agreed.

>but this again goes back to people wanting to dumb it down for users expecting it to all work like centralized services

I don't think putting a warning somewhere above the compose text area after selecting a limited scope that says something like "Due to the nature of federated networks, it is possible that unintended users might see this post. For more information see <link>." looks that bad and it accurately represents reality. Or a simple modal when first blocking someone that says something similar about replies with a "never show again" checkbox.

Pleroma already gives you such a warning when you are composing an FO post with your account not set to approve followers first.