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 of 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 the 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 now also be enabled 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.

User Level Domain Blocks

In addition to server level suspensions, individual users are also able to place their own blocks on remote servers by clicking on the […] profile menu of a user on that server, and selecting Block domain bad.example.

Blocks placed this way are affected by Authorized Fetch in the same way as server level suspensions described above.2

Similar limitations also apply. In particular, the blocked server will still have access to its own cached copies of posts made before the block was placed.

When testing Authorized Fetch between servers running Mastodon v4.2.3, user level domain blocks successfully prevented viewing new posts, but did not prevent viewing updated profile information.

Disallow Unauthenticated API Access

I would not recommend turning this setting on, unless you are ok with breaking your website for anyone who isn’t logged in.

Fediverse servers use ActivityPub to communicate with each other, but there’s a second protocol, the Mastodon API that Mastodon clients use to communicate with a Mastodon server.

As with ActivityPub, anonymous access is allowed to public posts and profile information by default.

Turning on the DISALLOW_UNAUTHENTICATED_API_ACCESS setting prevents anonymous access to the Mastodon 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, visitors will no longer have access to the Local and Federated timelines (now labelled This Server and Other Server under Live Feeds) on the website or through the API, but the rest of the site will still work. Visitors will still have access to profiles, public posts, and the About page.

Drawbacks and Limitations

Authorized Fetch can reduce some unwanted access, but it is not a magic bullet. There are limitations to its effectiveness, and there are technical drawbacks to enabling it.

Block Evasion

Ultimately, if you want to post publicly on the fediverse, somebody willing to go through some extra effort to see those posts will be able to do so.

Mastodon provides RSS feeds for each user’s public posts which can be found by adding .rss to the end of a user’s profile URL (eg. http://mastodon.social/@gargron.rss). Mastodon does not currently provide settings to allow a user or admin to opt out of providing RSS feeds.

Other simple ways include:

Some more technically involved, but still practical ways include:

Server Incompatibility

Not all fediverse software implements Authorized Fetch support (which they might call something else).

Higher Server Load

Since every request for a post must now be checked individually for authorization, it’s no longer possible to benefit from HTTP request caching.

One situation where this might make a difference is a post going viral on a server with limited computing power, such as a Raspberry Pi.

i had posts trend earlier and this resulted in 100% nginx CPU for hours on my potato [Raspberry Pi]

However, I have yet to encounter anyone having issues on more robust server hardware with multiple CPUs, beyond the conclusion that it must increase load to some degree.

After enabling Authorized Fetch on a server with ~500 active users, 4 CPU cores, and 8 GB of RAM, I wasn’t able to discern any change in performance after several weeks.

Missing Replies

One of the more confusing aspects of the fediverse is that not every server knows about every post, or every reply.

There is an ActivityPub feature called inbox forwarding, which allows servers to forward replies to other servers, so that users on those servers can see the whole thread of conversation.

Authorized Fetch disables inbox forwarding because it doesn’t have control over the servers the messages get forwarded to (which may include blocked servers). This increases the likelihood that a remote user viewing a thread may not see your replies unless they are mentioned or following you.

Cached Data

As part of normal operation, servers keep cached 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-12-27
  • Expand and update Drawbacks and Limitations
2023-12-16
  • Add info on user level domain blocks
2023-12-14
  • Update server compatibility notes
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 ↩︎

  2. Per Mastodon dev team on Discord, and confirmed by testing, v4.2.3 ↩︎

  3. https://haqueers.com/@Rairii/111641757827318245 ↩︎

  4. https://docs.gotosocial.org/en/latest/federation/federating_with_gotosocial/ ↩︎

  5. https://mastodon.social/@dansup/110612997798718029 ↩︎

  6. https://tech.lgbt/@luana/111578348048394873 ↩︎