Post B7mVpFe9tCd6W62ozY by ariadne@social.treehouse.systems
(DIR) More posts by ariadne@social.treehouse.systems
(DIR) Post #B7mSfuhy4MX56lgM08 by ariadne@social.treehouse.systems
1 likes, 1 repeats
risks with relays on the fediverse, a thread
(DIR) Post #B7mT38Q1GBnYI6MLwm by ariadne@social.treehouse.systems
1 likes, 0 repeats
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.
(DIR) Post #B7mTZnIEpDnGKNIESW by ariadne@social.treehouse.systems
0 likes, 0 repeats
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.
(DIR) Post #B7mU3PvOH01yXTjQO0 by ariadne@social.treehouse.systems
0 likes, 0 repeats
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.
(DIR) Post #B7mURBtE6e7nxc3Vei by ariadne@social.treehouse.systems
0 likes, 0 repeats
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?
(DIR) Post #B7mUsBtoBBFfoBCbyK by teohhanhui@mastodon.social
0 likes, 0 repeats
@ariadne server-to-server is just the wrong model altogether...
(DIR) Post #B7mUv1MvmrWs1BAqA4 by ariadne@social.treehouse.systems
0 likes, 0 repeats
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?
(DIR) Post #B7mVCeBiiB0FKvKovw by ariadne@social.treehouse.systems
0 likes, 0 repeats
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
(DIR) Post #B7mVR144SBIiLDbnDE by ariadne@social.treehouse.systems
0 likes, 0 repeats
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.
(DIR) Post #B7mVefo4HslySrdTMW by ska@social.treehouse.systems
0 likes, 0 repeats
@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.
(DIR) Post #B7mVpFe9tCd6W62ozY by ariadne@social.treehouse.systems
0 likes, 0 repeats
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.
(DIR) Post #B7mW2EI0FODy4Urzii by ariadne@social.treehouse.systems
0 likes, 0 repeats
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.
(DIR) Post #B7mWJ6A1irMJmfBOVc by ariadne@social.treehouse.systems
0 likes, 0 repeats
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.
(DIR) Post #B7mWjyX0CFe3wMkGcS by ariadne@social.treehouse.systems
0 likes, 0 repeats
@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 isif 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.
(DIR) Post #B7mWqorCYzjhxnSNyC by ariadne@social.treehouse.systems
0 likes, 0 repeats
@ska (malicious servers aside, that is)
(DIR) Post #B7mXD7pwg5UBCOVPWK by ariadne@social.treehouse.systems
0 likes, 0 repeats
@stag it is possible to have an open ecosystem that has good metadata hygeine. we are talking largely about metadata here.
(DIR) Post #B7mXVSy4qqZlws3SYC by ariadne@social.treehouse.systems
0 likes, 0 repeats
anyway this is what evanp is getting at when he says that at least his tags.pub relay bots make themselves known to you.
(DIR) Post #B7mXq2FtMbPPBLCBpg by oemb1905@gnulinux.social
0 likes, 0 repeats
@ariadne are you still traveling with the starlinks?
(DIR) Post #B7mYA4ovXJPMvf8hsG by ariadne@social.treehouse.systems
0 likes, 0 repeats
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.
(DIR) Post #B7mYKIHAMd79YYDhGy by ariadne@social.treehouse.systems
0 likes, 0 repeats
but it is also important to note that authorized_fetch is imperfect. some adversarial nodes use an alternative AP identity to fetch remote content.
(DIR) Post #B7mYw4OwOiuPWrryXg by ariadne@social.treehouse.systems
0 likes, 0 repeats
@oemb1905 no, but I don't really understand what that has to do with this thread
(DIR) Post #B7mcamlz8zAgaikqvI by ariadne@social.treehouse.systems
0 likes, 0 repeats
@teohhanhui i mostly agree, but that's basically what we have right now.
(DIR) Post #B7mwvLHSYM5SUQYXTc by ariadne@social.treehouse.systems
0 likes, 0 repeats
@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.
(DIR) Post #B7nGwtkNtJ14l66YVc by oemb1905@gnulinux.social
0 likes, 0 repeats
@ariadne The thread just had a post-travel reflection vibe to it I thought, must have read your earlier post into it. Hope you are well ;)
(DIR) Post #B7oHrX7yr9OQGo6iSO by argv_minus_one@mastodon.sdf.org
0 likes, 0 repeats
@teohhanhui What would be better? Peer-to-peer with no servers?@ariadne
(DIR) Post #B7oHrXK28L2AsBkLFA by ariadne@social.treehouse.systems
0 likes, 0 repeats
@teohhanhui @argv_minus_one something like secure scuttlebutt but with end to end encryption
(DIR) Post #B7oOqGDyuqW1EeFq6q by xarvos@outerheaven.club
0 likes, 0 repeats
isn’t P2P make it rather hard for discoverability tho?@ariadne @teohhanhui @argv_minus_one
(DIR) Post #B7oOqGVhqwh47cXzjk by ariadne@social.treehouse.systems
0 likes, 0 repeats
@xarvos @argv_minus_one @teohhanhui SSB and NOSTR use relay servers despite the messaging itself being P2P