risks with relays on the fediverse, a thread

there are two main protocols used for relaying in the fediverse. both have overlapping areas of risk, though I tried to make mine as safe as I reasonably could.

the area where there is overlap is with metadata leakage: if you connect a relay, in all cases, you are advertising the existence of an activitypub object as a specific URI. this is how relays relay: they induce ingestion of external posts as a side effect.

first, let's talk about my protocol for this, the litepub relay extension.

the way that it works is that a server wishing to connect to a relay simply follows an actor on the relay service. the actor then redistributes incoming Announce activities (mastodon calls these boosts) to those following it.

this causes posts to be ingested by resolving the URI in the Announce activity.

the only thing that is signed is the Announce activity, by way of an HTTP signature header covering the body's digest.

this is, in my opinion the right way to implement relaying: you are advertising content at a given location, and then interested servers can go import the posts if they want to.

by comparison, let's talk about the Mastodon relay protocol.

this protocol is basically the opposite of mine: instead of subscribing to an *actor*, you subscribe to an inbox.

Mastodon then sends raw Create and Announce activities to that remote inbox, and the relay server forwards the raw activities along.

instead of HTTP signatures, the raw activities are signed with LDSigs, and Mastodon has no key rotation or expiry model. in other words, it sends activities that are signed by a unique key belonging to your account to these relays, and the signatures are forever.

myself and many other security engineers, as well as actual cryptographers criticized this model for years, and still sometimes do, like now.

the question we should be asking is: how well do these relay protocols resist disclosure to adversarial parties (e.g. Palantir, harassment instances like poast, etc.)?

and to make things interesting, let's make it a poll: which protocol do you think is safer?

alright. threat modeling time.

let's say that you are having a bad day, and you post something that could be considered a threat towards somebody more powerful than you: it could be a boss, it could be a politician, it could be the cop that wrote you a ticket earlier, whatever.

what happens with each approach to relaying?

in litepub relaying, you post your post, and then your instance forwards it to relays.

the only thing forwarded was a URI to a post object.

if you delete the post object, then it's replaced with a tombstone*.

* this isn't perfect because deletes do not federate with perfect reach

this quality is called deniability: if you can make the argument that the post never existed, or wasn't signed by you, or whatever, then they have to work to prove otherwise.

well... in the mastodon scheme, your instance just gave the relays a signed copy of the post object itself. in other words, forensic confirmation that you made the post you are trying to deny.

@ariadne This deniability guarantee is at odds with the principle of replication of data in a federation. With your model, can you ever copy/cache data? If your server dies, are all the posts it hosts inaccessible?

This isn't necessarily a bad choice, but it is a choice and the behaviour needs to be clear.

a lot of people talk about authorized_fetch. for whatever reason, mastodon disables relaying when authorized_fetch is enabled, which is largely pointless.

what does authorized_fetch do? it is a mitigation for the broken security model of activitypub: it forces all requests to be signed by the signing keys of whatever actor is requesting remote content. if the actor is unauthorized to request the content, the fetch is denied.

this works to protect your posts from being relayed to adversaries, either through relaying itself or through adversarial accounts manually boosting the post.

it is vitally important to make clear that authorized_fetch is a mitigation. it is not perfect, and there are other methods, like screenshotting, that authorized_fetch won't protect from. but it does pretty well.

mastodon default-disables this mitigation while other servers largely have it enabled by default.

@ska @ariadne you can still copy and save the post data, verification just needs to happen online potentially with a requirement to sign the fetch with your instance actor key

if I were Palantir, I would set up an activitypub relay and then convince as many instances as possible to sign up for it.

I would then scrape all the posts, and all the signatures.

thankfully, I'm not Palantir.

@ska the instance you are on has been configured this way from the beginning. yes, we cache remote content, but the thing about authorized fetch is

if you exist in a world where all activities have to be fetched with signature, then you can work out exactly which peers have a copy of any given post.

in other words, it opens the door to perfect deletes.

@ska (malicious servers aside, that is)

@ariadne i’m not sure i quite understand. isn’t activitypub an open ecosystem? doesn’t really make much sense to try super hard to limit who can see your public content

i mean if it’s something like a ai scraper thats super aggressive thats one thing but if its just like once per post i dont think much can be done in general about that

@stag it is possible to have an open ecosystem that has good metadata hygeine. we are talking largely about metadata here.

anyway this is what evanp is getting at when he says that at least his tags.pub relay bots make themselves known to you.

in conclusion from the admin pov:

1. don't use relays if your instance uses the Mastodon relay protocol.

2. *do* use authorized_fetch.

3. use relays at your own risk, even with the litepub protocol. while authorized_fetch will prevent posts successfully federating to adversarial nodes that have been blocked, it will not prevent those nodes from discovering metadata about your posts.

but it is also important to note that authorized_fetch is imperfect. some adversarial nodes use an alternative AP identity to fetch remote content.

@ariadne are you still traveling with the starlinks?

@oemb1905 no, but I don't really understand what that has to do with this thread

@ariadne server-to-server is just the wrong model altogether...

@teohhanhui i mostly agree, but that's basically what we have right now.

@ariadne metadata, actual content, does it matter? once you release something on public internet in an open ecosystem you don’t control it anymore. you no longer have control where it goes.

if you don’t like that, don’t make it public

@stag again this is not about the typical use case, but rather about edge cases that well-behaved social platforms are expected to solve for, like stalking mitigation.

I'm not interested in debating this.

@teohhanhui

What would be better? Peer-to-peer with no servers?

@ariadne

@teohhanhui @argv_minus_one something like secure scuttlebutt but with end to end encryption

isn’t P2P make it rather hard for discoverability tho?

@ariadne @teohhanhui @argv_minus_one

@xarvos @argv_minus_one @teohhanhui SSB and NOSTR use relay servers despite the messaging itself being P2P