Sunny Garden Hub

What does AUTHORIZED_FETCH actually do?

[Updated: ]

Disclaimers

There seems to be increased interest lately in the Mastodon configuration settings AUTHORIZED_FETCH and the newer and lesser known DISALLOW_UNAUTHENTICATED_API_ACCESS.

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 can be enabled with command line access to the server’s config file .env.production. As of Mastodon v4.2.0, Authorized Fetch can also be controlled from the server administration interface with the setting Require authentication from federated servers, under Administration / Server Settings / Discovery.

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:

When a server is suspended it continues to have access to public posts and profiles, because this information is accessed anonymously. Authorized Fetch prevents this by requiring remote servers to identify themselves for each request, allowing your server to recognize and refuse access to suspended servers.

When one server suspends another, the server putting the suspension in place will:

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.

A server that has been suspended does not know it has been suspended, and may continue to request public information from the server doing the suspending. Because the requests are anonymous, the suspending server does not know who is requesting the information, and so does not deny access to it.

Enabling Authorized Fetch requires remote servers to identify themselves for each request, allowing your server to identify and deny access from suspended servers.

In the simplest example, take two servers good.example and bad.example, where good.example has suspended bad.example.

A user on bad.example hears about an interesting user on good.example and types @coolperson@good.example into the search box of their own server.

bad.example which doesn’t know it has been suspended, makes an anonymous request to good.example to read the user’s profile information. good.example allows bad.example to download the profile because it doesn’t know who is asking. The user doing the search (and indeed, all of the users on bad.example) can now find and view the profile of @coolperson@good.example.

The same thing can happen using a full URL to a post…

If a user on bad.example finds a link to a specific post on good.example mentioned on some other website, they can paste it into the search box of their own server. Once again, the information is requested anonymously, and the post from good.example is now visible, browsable, and searchable on bad.example.

Example: Boosting

Take a situation where there are three servers, good.example, bad.example, and medium.example.

good.example has suspended bad.example, but has no limits on 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 1

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 suspends 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 suspend 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 users on suspended servers from accessing your server’s public content if they want to see it, although it does take 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 who is determined 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, DISALLOW_UNAUTHENTICATED_API_ACCESS 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 related 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.

Problems and Limitations

Enabling Authorized Fetch should mostly go unnoticed by your users, but it does have some drawbacks and limitations:

  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
  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 (or small servers hosting very popular accounts) that rely on caching to improve performance, handle load, and reduce cost.
  4. Cached data is not removed
    • As part of normal operation, servers keep copies of all of the profiles and posts that they know about. Neither a suspension nor enabling Authorized Fetch will remove any cached data that a suspended server already had prior to being suspended, and it may keep that data indefinitely.

Edit History

2023-09-25
  • Mastodon v4.2.0 supports enabling Authorized Fetch from the adminstration UI
2023-07-30
  • Improved the “short answer” for accuracy and clarity (I hope)
  • Replaced use of the word “block” with “suspend” where appropriate.
  • Add Direct Search example, and a note about caching

If any of the information on this page is incorrect, please let me know.

  1. https://wirebird.com/artiblocks/defining-secondhand-smoke ↩︎