#authorizedfetch — Public Fediverse posts

If you're running a Mastodon server, you might want to activate the "authorized fetch" option (also known as "secure mode").

Having this switched on makes your server-level blocks work much more effectively, and helps to protect your server's members from abuse.

It's extremely easy to activate, step-by-step instructions and lots of questions answered at:

🌱 https://fedi.tips/authorized-fetch

#MastoAdmin #AuthorizedFetch #SecureMode #UserSafety #Mastodon

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.

@[email protected] 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 @[email protected] uses forces it to be on permanently).

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 ​:TenshMelt:​

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

RE: https://makai.chaotic.ninja/notes/9rzkf0zr1s

@[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.

Happy to report that Kolektiva has activated authorized fetch, which will help to protect our instance's posts from surveillance and "AI" ingestion by Meta. Thank you to @subMedia @admin @moderation for defending the zone!

#DefederateMeta #Meta #Facebook #Threads #AuthorizedFetch

Now, the #Fediverse has attracted many users with a desire for safety and data sovereignty (i.e. they should decide what happens with their data). So they get understandably upset when their data gets siphoned without their consent or knowledge. It's not always clear how to protect against this, barring buy-in to codes of conduct and concepts like the still-evolving #AuthorizedFetch. So far, security has been best obtained through obscurity, but this is shaky & hampers ease of use. So what do? 😕

No, fuck you for making "Public" a gray area when it shouldn't be.

These kind of #privacy freaks and #security freaks (different from privacy-aware and privacy-conscious) who don't understand the definition of #Public.. You know, the types who will put every damn mitigation and flick on every security feature in their computer even though it adversely affects their usability and doesn't really apply to their threat model (this part is especially ignored!), and yet will do an epic #OPSEC fail elsewhere anyway... These kind of people can do a favor for the #fediverse and stay the fuck out of #socialmedia. They can come back once they understand fully the phrase "think before you click".

Don't want people using their #RSS reader against your instance? Fine, then disable it in your instance's settings. But don't expect that you can prevent everyone from still trying to use RSS against your account without your knowledge. Because that's impossible and all you're really doing here is #securitytheater. Just like what #authorizedfetch is.

RE: https://sfba.social/users/FinchHaven/statuses/111868391652688742

While Authorized Fetch remains important to activate, it is clear that even it - which remember, provides better defense than that currently implemented on most of our home servers - is inadequate to the threats facing us as the Zuckerberg incursion progresses. If we're serious about protecting our communities and expressions from absorption into surveillance capitalism and the accelerating miseries of fascism, we need to talk about a stronger grade of defensive weaponry.

To this end, @are0h has fired a first volley: https://h-i.social/@are0h/111653850819592308 Every fedi community which serves as a refuge for those targeted and under siege should be thinking like this. True safety only awaits us in a transitive approach to defederation, and further on, in an intentional federation based on the allow-list.

2/7

#FreeFediverse #FediPact #DefederateMeta #Meta #Facebook #Threads #Instagram #Democracy #Community #Decentralization #Prefiguration #Fedifam #AuthorizedFetch #AllowList #IntentionalFederation

The Intentional Federation

We have recently been advocating the activation of a function which is present but usually off in Mastodon and other fedi services called Authorized Fetch. As we plead with the major development projects to take safety more seriously and make it a default, we have learned that Meta itself didn't think twice about it and has activated it in their own ActivityPub implementation against *us*.

We know this because of news that a fascist has devised a way to evade it and force federation with Threads. They promise to then turn their technique upon us and coerce unblockable federation with fascist and cryptospam instances: https://soapbox.pub/blog/threads-server-blocking/

1/7

#FreeFediverse #FediPact #DefederateMeta #Meta #Facebook #Threads #Instagram #Democracy #Community #Decentralization #Prefiguration #Fedifam #AuthorizedFetch #AllowList

A small update and expansion of Authorized Fetch: Drawbacks and Limitations

https://hub.sunny.garden/2023/06/28/what-does-authorized_fetch-actually-do/

#AuthorizedFetch

the only way to truly solve this is whitelisting instances instead of blacklisting. what #Mastodon calls "limited federation mode".
there's many ways to do this, including stuff like federating allowlists or using a semi-centralised trust source.

but in the end, it still comes down to whitelists.
that's something the vast majority of the Fediverse just doesn't do at the moment, but it may have to change at some point. we'll have to wait and see.

#AuthorizedFetch #federation #FediBlockMeta

okay but fr, I don't see why this is shocking news.
#mastodon, by default, works under the assumption that every instance is good unless proven otherwise. this is also true for many other Fediverse software.
the result is that anyone can get a new domain and mastodon will presume they're a new friendly neighborhood instance. most instances block both gab dot com and gabfed dot com for this exact reason.
(1/2)
https://wedistribute.org/2023/12/authorized-fetch-circumvented

#AuthorizedFetch #federation #ActivityPub #FediBlockMeta

Authorized Fetch will help keep our accounts safe from Meta data-mining. Participate in polls on the Authorized Fetch issue here:

by @tokyo_0: https://mas.to/@tokyo_0/111607524638174586

by @thenexusofprivacy: https://infosec.exchange/@thenexusofprivacy/111602607824043839

#FediPact #DefederateMeta #Meta #Facebook #Threads #Instagram #AuthorizedFetch

Did you know that, if you or your Mastodon instance is blocking Meta, your posts and account can still be data-mined by them? That is, unless your instance has Authorized Fetch activated. More info here: https://kolektiva.social/@ophiocephalic/111602259275182233

#FediPact #DefederateMeta #Meta #Facebook #Threads #Instagram #AuthorizedFetch

@smallpatatas

Here's the best Authorized_Fetch backgrounder I've found

My executive summary:

dot Social will send anything to anyone who asks for it, and will accept anything from anyone who sends it, although the details are complicated

"If Authorized Fetch is not enabled, requests to access public posts and profile information are anonymous. This is due to the current design of ActivityPub, the common protocol that all fediverse servers use to communicate with each other"

Here: https://hub.sunny.garden/2023/06/28/what-does-authorized_fetch-actually-do/

Bet Zuck is happy about this...

#AuthorizedFetch #Threads

With the Zuckerberg takeover impending, there's a lot of confusion circulating about the use of user-level and instance-level blocks, and how our online expressions can be secured against Meta. Everyone who objects to their accounts being mined by the Zuckerberg entity for data collection, AI ingestion, monetization, and possible ghost-profile building needs to understand this problem. Here's information to clarify.

Neither a user-level block, or an instance-level block, will protect our posts from Meta data-mining by default on a Mastodon instance. Posts won't be delivered directly, but can be ingested by other means; if, for example, users on Meta-federated instances boost them.

However, both user and instance blocks will totally prevent post delivery in all cases IF your host instance has enabled the functionality called Authorized Fetch.

By default, Authorized Fetch is off on Mastodon instances and most haven't turned it on. If this concern is important to you, you might want to respectfully reach out to your admins and let them know. Remember that they are working hard to provide and sustain online community at no charge. It's likely they won't be very familiar with it and will need time to look into it.

For more information on Authorized Fetch, check out this blog post by @brook : https://hub.sunny.garden/2023/06/28/what-does-authorized_fetch-actually-do/ Please untag Brook from replies unless you specifically intend to address him

#FediPact #DefederateMeta #Meta #Facebook #Threads #Instagram #AuthorizedFetch

@ex_06 @enverdemichelis Cioè dici un toot "privato"? Quelli hanno un URL ma richiedono autenticazione, quindi le persone non citate non dovrebbero mai ricevere il contenuto nemmeno se scoprono l'URL. Le altre istanze federate invece non dovrebbero mai riceverne una copia dalla tua istanza, dato che non ne hanno bisogno. Per ridurre il numero di "copie non autorizzate" aiuta attivare #AuthorizedFetch.
https://hub.sunny.garden/2023/06/28/what-does-authorized_fetch-actually-do/

#MastoDev

any other single-user instances who’ve enabled authorized fetch having any visible problems with interacting on the fedi? I have not noticed any but I fear I might not be able to tell.

#authorizedFetch #singleUser

any other single-user instances who’ve enabled authorized fetch having any visible problems with interacting on the fedi? I have not noticed any but I fear I might not be able to tell.

#authorizedFetch #singleUser

any other single-user instances who’ve enabled authorized fetch having any visible problems with interacting on the fedi? I have not noticed any but I fear I might not be able to tell.

#authorizedFetch #singleUser

any other single-user instances who’ve enabled authorized fetch having any visible problems with interacting on the fedi? I have not noticed any but I fear I might not be able to tell.

#authorizedFetch #singleUser

any other single-user instances who’ve enabled authorized fetch having any visible problems with interacting on the fedi? I have not noticed any but I fear I might not be able to tell.

#authorizedFetch #singleUser

Does suspending an instance prevent them from seeing public posts on your #Mastodon instance?

My understanding is it does not by default, based on this discussion about "secure mode", which is an option that does require instances to be authorized to fetch posts from your server: https://github.com/mastodon/mastodon/issues/18353

Does #suspension (without secure mode) do anything from the #suspended instance's perspective, or does it only prevent your users from seeing it?

#MastoAdmin #SecureMode #AuthorizedFetch