NovaNov 9
(💜 Marielle) Dear fellow admins, if your instance supports turning Authorized Fetch on or off, and you do not have Authorized Fetch disabled, please consider (re-)enabling it. AuthFetch prevents instances that you have defederated from seeing and interacting with your instance's posts by preventing unauthorized AP lookups, which is crucial to prevent your users or yourself from being doxxed.

If nobody believes me, I happened to see someone's post getting unwanted interaction from instances her instance defederated. I will not go into any detail because it was when she was dealing with a tough time, and I do not want to out her for it. I informed her privately, and she took care of it on her end, but yes, not having Authorized Fetch enabled can lead to incidents like this.

#FediAdmin #MastoAdmin #Moderation #ActivityPub #AuthorizedFetch
JL Johnson Dec 2, 2024

Interesting! I have threads.net blocked as an instance. @vmstan says that since we have #authorizedfetch that takes away Zucky’s easy button for gobbling up my data.

There are a few threads accounts I want to follow. I have a burner account just for those where, like a bad lover, I take but don’t give.

Interestingly enough, I can use @ivory to boost threads posts -on this account- from my burner.

Huzzah! I believe I have my cake, and am eating it too. Yay.

User47's Alter EgoJun 26, 2024

This server has "authorized fetch" enabled. It has been on since shortly after it became an option. Having authorized fetch enabled means many things, but perhaps most importantly, that you may block threads.net instance and they won't have access to your data. While others on the server who do want to interact with Threads users, can.

Those on instances without authorized fetch enabled don't have a choice unless the instance itself blocks threads. #TMYK #Threads #AuthorizedFetch #fediblock

洪 民憙 (Hong Minhee) 🤏🏼Apr 23, 2024

#Fedify, an #ActivityPub server framework, has released version 0.7.0! Here are the key changes in this version:

• Access control for actors, collections, and more via authorized fetch (i.e., secure mode)
• Generalized object dispatcher
• Logging with #LogTape for easier debugging

https://github.com/dahlia/fedify/releases/tag/0.7.0

#fedidev #authorizedfetch

Release Fedify 0.7.0 · dahlia/fedify

Released on April 23, 2024. Added PUBLIC_COLLECTION constant for public addressing. Federation now supports authorized fetch for actor dispatcher and collection dispatchers. Added ActorCallbac...

GitHub
Show thread Mima-samaApr 19, 2024
@tyil Signing fetches (different from #AuthorizedFetch) actually has been enabled by default for new #Misskey installations for a while, it was done in some 2023 version despite the performance impact due to compatibility with the rest of the #fediverse where AF is becoming more and more enabled (not helped by the fact that #GoToSocial which @fbievan uses forces it to be on permanently).
Show thread洪 民憙 (Hong Minhee) 🤏🏼Apr 12, 2024

#Fedify 0.7.0 will have access controls. You can test it in the unstable release, 0.7.0-dev.120+4c00fc5e.

https://unstable.fedify.dev/manual/access-control

#fedidev #ActivityPub #authorizedfetch

Access control | Fedify

Fedify provides a flexible access control system that allows you to control who can access your resources. This section explains how to use the access control system.

 Mima-samaApr 12, 2024
Welp I wrote all of this shit only to see it not get federated to the OP's instance. I think they're blocking us lol ​​

Well at least I have something to #quotepost if I need to explain (my understanding) of #AuthorizedFetch ​​

RE: https://makai.chaotic.ninja/notes/9rzkf0zr1s
:mima_rule: Mima-sama (@mima)

@[email protected] Uhh I think you've gotten it fundamentally wrong here :thinking_cirno: Whether your instance's posts appear on the blocked instance or not doesn't depend on the blocked having #AuthorizedFetch, but rather your instance having AF. That instance can still *fetch* your posts because your instance doesn't check if the request is signed (so an instance can sign all their fetching but still not enable AF, which is what vanilla #Misskey currently does) and from which instance the fetch request is coming from (hence the "authorized"). Threads already defederates from instances that don't sign their fetching (by design because they've enabled AF), but they don't care if an instance has enabled AF (it's that instance's problem to deal with posts still appearing in Threads). The problem (I have) with AF is that it's pretty much just #securitytheater. The documentation doesn't seem to account for this possibility, but if your adversary has enough money for some cheap domains and is well-versed in how #ActivityPub works nowadays, then it's trivial for them to forge signatures to look like their fetches come from an innocent server, therefore effectively bypassing the check and allowing the blocked to get your posts into their instance. This is already being done in the wild (with the #Soapbox developer doing this to bypass Threads' fediblock being the most infamous recently). It also complicates AP implementations because now you have to deal with more cryptography with all that signing and verifying of requests. And signing alone does have a significant impact on performance. It's impossible to create a 100% compatible AP implementation from the spec alone without looking at Mastodon's implementation. That's where the #EmbraceExtendExtinguish or #EEE comes to play. So overall it's the overeagerness of #MastoAdmins in adopting AF or #SecureMode without understanding the compatibility and performance implications that brought us to this mess today. RE: It's completely asinine that an instance I've defederated from that doesn't use "authorized fetch" (proprietary mastodon implementation) can see my posts and interact with them as if I can see them. I'm basically giving promotions to asshats in my replies from gross instances because blocks don't work like they should... This is why I don't see Threads federating with these platforms for very long. Every Fedi software that doesn't adopt Authorized Fetch, will be breaking their terms. There IS a few proposals on how AP could officially implement a similar feature, but as of right now, it's the wild west here. #Fediverse #Fedi #Mastodon #Threads #Meta #Pleroma #Akkoma #Sharkey #IceShrimp #ActivityPub #FireFish #Pixelfed

Makai
 Mima-samaApr 12, 2024
@BeAware Uhh I think you've gotten it fundamentally wrong here ​​

Whether your instance's posts appear on the blocked instance or not doesn't depend on the blocked having #AuthorizedFetch, but rather your instance having AF. That instance can still fetch your posts because your instance doesn't check if the request is signed (so an instance can sign all their fetching but still not enable AF, which is what vanilla #Misskey currently does) and from which instance the fetch request is coming from (hence the "authorized").

Threads already defederates from instances that don't sign their fetching (by design because they've enabled AF), but they don't care if an instance has enabled AF (it's that instance's problem to deal with posts still appearing in Threads).

The problem (I have) with AF is that it's pretty much just #securitytheater. The documentation doesn't seem to account for this possibility, but if your adversary has enough money for some cheap domains and is well-versed in how #ActivityPub works nowadays, then it's trivial for them to forge signatures to look like their fetches come from an innocent server, therefore effectively bypassing the check and allowing the blocked to get your posts into their instance. This is already being done in the wild (with the #Soapbox developer doing this to bypass Threads' fediblock being the most infamous recently).

It also complicates AP implementations because now you have to deal with more cryptography with all that signing and verifying of requests. And signing alone does have a significant impact on performance. It's impossible to create a 100% compatible AP implementation from the spec alone without looking at Mastodon's implementation. That's where the #EmbraceExtendExtinguish or #EEE comes to play.

So overall it's the overeagerness of #MastoAdmins in adopting AF or #SecureMode without understanding the compatibility and performance implications that brought us to this mess today.
洪 民憙 (Hong Minhee) 🤏🏼Apr 11, 2024

Today I'm working on putting authorized fetch (aka secure mode) into #Fedify. The protocol implementation is complete, it's just a matter of polishing the API and docs. It appears that it will be finalized sometime tomorrow. Authorized fetch will be one of the major improvements in Fedify 0.7.0.

#authorizedfetch #fedidev #ActivityPub

洪 民憙 (Hong Minhee) 🤏🏼Apr 11, 2024

When an #ActivityPub server implements authorized fetch (aka secure mode), how does it associate the keyId in an HTTP request with the actual actor? I know major implementations (like Mastodon) use a fragment appended to the actor IRI as a keyId, but in theory a keyId could be any IRI that seems unrelated to the actor IRI, right? Should I maintain a table of actor–keyIds somewhere in the server?

#fedidev #httpsignatures #authorizedfetch