https://hub.sunny.garden/2023/06/28/what-does-authorized_fetch-actually-do/ Sunny Garden Hub Home About Blog What does AUTHORIZED_FETCH actually do? 2023-06-28 Disclaimers * The behaviour of these settings has changed in the past and may change again in the future, the information in this post applies to versions 4.0.0 and up, as of the date it was published. There seems to be increased interest lately in the Mastodon configuration settings AUTHORIZED_FETCH and the newer and lesser known DISALLOW_UNAUTHENTICATED_API_ACCESS. This post should not be taken as a recommendation to enable either setting. My intent is to explain their function, not encourage you to enable them. I don't currently have either enabled. The official Mastodon documentation on these settings provides a very technical description, which may not be helpful to anyone that doesn't have a thorough understanding of the ActivityPub protocol. Both of these settings require command line access to the server's config file .env.production, and cannot be enabled through the server's administration interface. Authorized Fetch So what does enabling AUTHORIZED_FETCH actually do from a user or admin's point of view? The short answer, and the point that I think most people are interested in, is this: For server wide blocks, blocked servers are not told that they have been blocked. Blocked servers can still fetch posts unless AUTHORIZED_FETCH mode is enabled. ^1 If a server is suspended, why is it still able to fetch posts from the server blocking it? When one server suspends another, the server putting the block in place will: * Go through every follow relationship between the two servers, and remove it * Stop sending messages to the suspended server * Stop processing messages that it receives from the suspended server * However... By default, requests to fetch public posts and profile information are anonymous, which means a user on a suspended server can still view profiles and public posts of users on a server that is blocking theirs. Authorized Fetch requires servers to identify themselves when requesting post and profile information, and disables anonymous requests. This allows the blocking server to recognize and refuse access to suspended servers. Example: Boosting Take a situation where there are three servers, good.example, bad.example, and medium.example. good.example blocks bad.example, but doesn't block medium.example. A user on good.example posts something publicly, and since they have a follower on medium.example, the good.example server sends the post to medium.example, but doesn't send it to bad.example. A user on medium.example sees the post and boosts it, since that user has a follower on bad.example, the medium.example server sends the boost to bad.example, and tells the server about the original post from good.example. bad.example receives the boost, and downloads the content of the post from good.example. good.example allows bad.example to download the post because it doesn't know who is asking. Beyond the fact that bad.example was able to see posts from good.example even though they are suspended, there's another potential problem... Second Hand Smoke ^2 Now that medium.example and bad.example have both seen the post, they start to have a discussion about it in the replies to that post. Since good.example blocks bad.example, all of the messages posted by bad.example are discarded, but all of the messages posted by medium.example are still accepted. Even if they can't see the content of bad.example messages directly, the users on good.example are still made aware the discussion is happening, and it might be obvious what the content of those messages is, based on the replies. Additionally, other users on medium.example or other servers which don't block bad.example may still be exposed to potentially harmful replies from bad.example, even if the original poster themselves can't see them. These are the problems Authorized Fetch aims to solve, by letting good.example stop bad.example from receiving the original post. Disallow Unauthenticated API Access Enabling Authorized Fetch doesn't entirely prevent blocked users from accessing your server's public content if they want to, although it does make it a little more effort. For one thing, they can still click links to view posts on your server's website, and browse around whatever public information is available there. But there's a second protocol, the Mastodon API that clients and apps use to communicate with Mastodon's server backend. Again, by default, anonymous access is allowed to public posts and profile information. Somebody wanting to circumvent a server suspension can still access public information anonymously through the Mastodon API. Turning on the DISALLOW_UNAUTHENTICATED_API_ACCESS setting turns off anonymous access to the API, and requires that a user be logged into your server in order to access the API. However, this will also break your server's website for anyone that doesn't have an account on your server. the About page of a Mastodon server with unauthenticated API access disabled. there are multiple messages in the corner reading “ 401 This method requries an authenticated user”, a message in the middle says “Oh no! The requested page could not be rendered.”, the Administered By label is blank, and the number of active users reads “NaN” The Mastodon web interface also uses the Mastodon API, so disabling anonymous API access breaks the public web interface as well. If somebody clicks a link to a post on your server, they will be met with a broken web page. Even the About page won't load correctly. Disabling Public Timelines Only There is a similar setting that is available in Mastodon's administration interface, called Allow unauthenticated access to public timelines, which can be found under Preferences / Administration / Server Settings / Discovery. If you turn this setting Off, anonymous users will no longer have access to the Local and Federated timelines on the website or through the API, but will still have access to the rest of the website, profiles, public posts, etc. Potential Problems Enabling Authorized Fetch also has some possible drawbacks, which I am too tired to expand on at the moment. I'll try to add some further explanation later. 1. Increased chance of conversation threads appearing to be missing replies if you aren't included in the thread yourself. + Authorized Fetch disables a feature called inbox forwarding meant to address ghost replies 2. Compatibility issues with non-Mastodon server software + pixelfed gained the ability to handle Authorized Fetch as recently as yesterday + very old Mastodon versions (pre-3.0.0) 3. Potential for an increase in server load, or decrease in performance. + Since every request for a post must now be checked individually for authorization, it's no longer possible to cache a single anonymous result that can be quickly provided to anyone requesting it. + This is more likely to be a problem for large servers with heavy traffic that rely on caching to improve performance, handle load, and reduce cost. That said, out of the server admins I've seen enable Authorized Fetch, I don't recall seeing any particular complaints about any of these issues coming up in practice. --------------------------------------------------------------------- 1. paraphrasing comments by Mastodon developer Claire from the joinmastodon.org Discord -[?] 2. https://wirebird.com/artiblocks/defining-secondhand-smoke -[?]