Skip to content

How to block Threads on Mastodon - and why blocking doesn't fully protect you (NEW VERSION)

With screenshots!

A menu, with red text.  The third entry, with a big red circle around it, is "Block domain threads.net"
"Threads is rolling out a beta of its fediverse integration in the US, Canada, and Japan. In a post on Thursday, Meta CEO Mark Zuckerberg announced that toggling on the feature will let you cross-post and view likes from other federated platforms, like Mastodon."

Threads’ fediverse beta opens to share your posts on Mastodon, too, Emma Roth, TechCrunch, March 21
"Depending on how the question is framed, some fediverse polls show overwhelming opposition to Meta."

Should the Fediverse welcome its new surveillance-capitalism overlords? Opinions differ!

Opinions really do differ, so if you're one of the fediverse influencers who sees Threads' entering the fediverse as "historic" and "a glimpse of the future" ... well, you might want to skip this post; instead, check out Embrace, Extend, and Exploit: Meta’s plan for ActivityPub, Mastodon and the fediverse.  And if you're still trying to make up your mind about Threads – or just want to learn more about various perspectives – Erin Kissane's Untangling Threads is really excellent.

But if you're one of the many many people on the fediverse who doesn't want to deal with Threads, read on!

Mastodon has a feature called "domain blocking" that lets instances (servers) and individual users block everybody on another instance – in this case, threads.net. Domain blocking's got some major limitations, and probably some bugs.  Still, it's useful.  

When domain blocking works the way it's supposed to, if you or your instance has blocked Threads, you won't see any posts from Threads, people on Threads can't see any new posts you've made after you blocked them, and you won't get notifications if people on Threads tag you. In practice, as I'll discuss in the next section, it's a lot more complicated than that. Still, while domain blocking's not even close to bulletproof protection, it's a good first step.

Important: if you're at risk from being targeted by stalkers or hate groups on Threads, you may want even stronger protection than just blocking them. In Untangling Threads, Erin Kissane suggests two options for people who "have good reason to worry about the risk surface Threads federation opens up": block Threads and post followers-only or local-only; or operate from a server that federates only with servers that also refuse to federate with Threads.

If you're on a Mastodon instance that's already blocked Threads, then you don't have to block them individually.  fedipact.veganism.social lists which instances are and aren't currently blocking threads.net – including over 700 instances who have signed the Anti-Meta FediPact. Like I said, though, opinions differ, and a lot instances haven't blocked Threads.  That's good for people on those instances who want to share their data with Meta to use for training AIs and targeting ads0 in return for being able to follow accounts on Threads and like their posts. But it means that people on those instances who don't want to deal with Threads have to do a bit of work.

There are at least two ways to block threads.net, the domain that Meta's currently using to host Threads.

Personally I find the first approach somewhat easier – and as a bonus, you can mute and/or block Zuck's account if you want, which at least for me was surprisingly enjoyable! However, there's a potential privacy issue doing it this way (described in more detail below), especially if you're running your own instance. So the second approach is more privacy-friendly.

Then again, most people on the fediverse today don't run their own instances.  So I'm including the instructions for both approaches, choose whichever you prefer! And whichever way you choose, there are sections at the bottom of the article on spreading the word and supporting FediPact creator Vanta Black.

First, though, I'll go into more detail about the limitations of domain blocking on the fediverse.  If you don't care about this, feel free to skip ahead to those sections, and just keep in mind that domain blocking isn't complete protection.

The limitations of domain blocking on the fediverse

The ActivityPub protocol that powers Mastodon and other software fediverse wasn't designed with safety and in mind, so blocking on the fediverse is very imperfect. One reason is because of the inherent challenges of the fediverse's architecture, with thousands of independent instances (servers) all potentially running different software; once your posts get federated (copied) to another instance, you no longer have control over them.  Not only that, design decisions (and potentially bugs) in the software make some kinds of blocking less effective. And while I'm focusing on Threads in this article, these weaknesses are also a problem when dealing with other threats as well!

For example:

  • Blocking doesn't protect your existing posts or profile if they've already federated to the instance that you're blocking. Since Threads hasn't enabled two-way communication yet, nothing's federated there yet, so that's an argument for blocking now!
  • Multiple people have reported unexpected results from blocking – people from instances they've blocked showing up in their feed or unexpectedly still able to interact with their posts unexpected, the same test showing different results.
  • Blocking is a lot less effective if your instance admin hasn't turned on "authorized fetch" – and while more privacy-friendly fediverse software like GoToSocial always turns this on, it's off by default in Mastodon.1 Unfortunately there's no easy way to check if authorized fetch is enabled on your instance, but see the appendix on Checking to see if authorized fetch is enabled for instructions on how to use the web browser's development tools to find out.  
  • Malicious software can get evade blocks and get access to public and unlisted posts. If Threads tries to do this, it might well lead to problems with EU regulators ... but then again, Meta's got a pattern of breaking the law, harvesting data without consent, and paying fines as a cost of doing business. I don't think they'll do that in this situation – the risk/reward tradeoff doesn't seem right – but you never know.

Also, keep in mind that on most instances (servers), anybody can see your profile and your public and unlisted posts if they have a link to it.  So even if you or your instance has blocked Threads, Threads users will be able to see profile or any post they have a link to by using a web browser.

So like I say, domain blocking's far from perfect – but it's better than nothing.  In practice, if you or your instance has blocked Threads, and your instance is running authorized fetch, people on Threads can't see any new posts you make, and the only posts and notifications you'll see from Threads are due to bugs in the software.  

Now let's look at the two ways for individual users to block Threads

Blocking threads.net from a Threads user's profile

As I mentioned above, there's a potential privacy issue with this approach: it starts with viewing a Threads profile, which could potentially lead to some of your information getting shared with Meta.2  According to Mastodon CTO Renaud Chaput, the only information transferred to Threads when you view a Threads profile is what instance you're using.3 If you've got your own instance, that's potentially identifying information, although if you're on an instance with hundreds or thousands of other people then there's no obvious way for them to know who you are.  

Personally, I decided I was okay doing it this way: my accounts are on larger instances.  But your mileage may vary!  If you're not comfortable with this, check out the instructions below for the alternate approach of uploading a domain blocking list.

1. Search for @zuck@threads.net

On the web interface, the search box is in the top left of most instances (although sometimes it's on the top right); it's also on the Explore page. If you're using the Mastodon app, you'll need to go to the Explore tab (by clicking the magnifying glass icon).  

A text box with a small icon of a magnifying glass and the words "Search or paste URL"

Type @zuck@threads.net (Mark F***ing Zuckerberg's Threads account) into the box.4

A text box with a small x in a circle at the left followed by the text "@zuck@threads.net"

Hit return, and it should bring you to the search results.

Search results: Mark Zuckerberg @zuck.threads.net, with the Meta Fediverse logo at the left and a follow button on the right

There might be other profiles claiming to be Mark Zuckerberg on the list, so you'll want to double-check the address to make sure you've got the right Mark F***ing Zuckerberg.

2. Click on the name to get to the profile

You may get a warning that the profile has been hidden by your admins.  This means that your admins have limited threads.net, which is kind of like muting everybody on threads.net by default.  

This profile has been hidden by the moderators of infosec.exchange.  Below, a button: Show profile anyway

If you get that warning, click on Show Profile Anyway.

3. Click on the three dots next to the follow button on the top right of the profile

Depending on the version your site is running, and any custom theming your admin has installed, it may look somewhat different than this ... but there should be three dots somewhare in the general vicinity of the follow button.  Here's how it looks on indieweb.social

On the left, the Meta Fediverse logo, Mark Zuckerberg, @zuck@threads.net.  On the right, a Follow Button and a button with three dots on it.  A red arrow points to the button with the three dots on it

4. "Block domain threads.net" to block everybody on Threads

Clicking on the three dots shold bring up a menu.  Here's how it looks on the web.  It's slightly different on the Mastodon mobile app; I've got a screenshot below.

A menu with seven items.  At the top, "Mention @zuck" in white. The seventh item on the menu, at the very bottom,  is "Block domain threads.net" in red., with a red circle around it

Click on Block domain threads.net, and you'll get a confirmation dialog.  Click on Block Server.  Now, if you look at the top left of Mark F***ing Zuckerberg's profile, you'll see something like

Domain blocked

Yay!

On the Mastodon mobile app, the menu's slightly different:

A menu with five items.  At the top, "Mute Mark Zuckerberg". The third item on the menu is "Block threads.net", with a red circle around it

Click on Block threads.net, click on Confirm, and you're good to go.

Bonus step: you can block and/or mute Zuck from this menu!

As you can see, you can also use these menu to block and mute Zuck individually. Feel free!  Of course if the entire domain is blocked, you don't need to ... but I personally found it quite satisfying.  Here's what his profile looked like after I also blocked him.  

Blocked.  Domain Blocked

Blocking threads.net by uploading a "domain blocking list"

This technique feels somewhat clunkier to me, but it has the advantage that you never view a Threads profile so it's more privacy-friendly.  JD Everhard's How to Block Server Domains in Mastodon also describes how to do this, and also has some good screenshots, so check it out if you find the description here confusing.

1. Download a "domain blocking list" file

A  domain blocking file can be as simple as a single line, with the domain to block:

threads.net

Here's a  file you can download, or you can use a text editor and create you're own. You can call it whatever you want – I used threads-block.csv, because Mastodon's documentation calls it a CSV (for comma-separated value).

2. Navigate to the import page

Here's where the clunkiness comes in, because this is much easier said than done ... and it's different on the web interface and mobile apps.

  • On the web interface, start by clicking Preferences (on the bottom right of the screen).  That will bring you to the Appearance page, which isn't want you want, but which has a looooong list of different kinds of preferences on the left.  
  • On the Mastodon mobile app, you need to click on the little gear icon (⛭) in the top right, scroll down and click on Account Settings, and potentially sign in to your Mastodon account (if you're not already signed in).  That brings you to the Account Settings page, which isn't what you want, but you can click on the three bars in the top right to get a menu with a long list of different kinds of settings.

Once you've gotten to the long list, click on Import/Export.  That will bring you to the Data Export page, which also isn't what you want, but now the list on the left on the web app also has Import – which is what you want, so click on it!  (If you're on the mobile app, you'll need to click on the three bars at the top right to get the menu again.)

A menu with three lines of text.  The second line, Import, has a red circle around it.

That will bring you to a page something like this ...

A complicated dialog.  At the top: Import, with the Import Type currently set to Following list and an indication that you can make a choice of import type

3. Upload the domain blocking list

First, you have to change the import type.  Click on Following List and you'll get a menu.  Choose Domain blocking list.  

A menu of eight items. Domain blockling list, highlighted in blue, is the last.

Once you're done, the page should look like this.

A dialog like the previous one but the Import type is now Domain blocking list.  Below, a button to Browse the CSV data file, and radio buttons offering a choice between Merge and Overwrite, with  merge currently selected

Now, click on Browse and select the domain blocking list file you created in step 1 (if you're on a computer and downloaded the one I linked to, it should be in your downloads with the name thread-blocks.csv).  Here's what that section of the dialog looks like once I've selected the file:

Data: CSV file exported from anothe Mastodon server.  A Browse button, and to the right threads-block.csv

Now click Upload, and you'll get a Confirmation dialog.  Click on Confirm.  The bottom of the import log page should now show your import's status as In progress – or, depending on how fast the server is, might already show it as Finished.

Recent imports: domain blocking list, in progress.

If  it saying In progress, wait a bit and hit refresh.  At some point, it'll hopefully show that the import has finished.

Yay!

Spread the word!

Polls consistently show that a lot of people in the fediverse want to block Threads, and Mark F—ing Zuckerberg in particular is widely loathed, so some of your followers might also be interested in blocking.  So let people know what you've done!  It doesn't have to be fancy – "I'm #BlockingThreads, you can too" is fine, and maybe include a link to this post or some other instructions.  

Or you can get more elaborate if you want!  If you're looking for reasons why others are blocking Threads, Why block Meta? has lots of perspectives.

Support FediPact creator Vanta Black!

The Anti-Meta FediPact helped galvanize resistance to Meta at a crucial time.  As I wrote in Why the Anti-Meta Fedi Pact is good strategy for people who want the fediverse to be an alternative to surveillance capitalism,

"Most importantly, it counters the gaslighting that resistance is futile. The segment of the fediverse that wants to reject Meta is clearly large enough that it will survive no matter what the big Mastodon instances and pundits do."

Alas, FediPact creator Vanta Black has been having a tough time – including recently being kicked out by her roomie.  So it's a great time to show appreciation by helping her out!  Even just boosting her post helps ... and if you've got a little money to spare, each donation makes a difference.

Appendix: Checking to see if authorized fetch is enabled on an instance

As far as I know, the only way to check whether authorized fetch is enabled on a fediverse instance is to try to fetch something via the API and see if it works.

One way to do this is to bring up a new tab in a web browser,  then bring up the developer tools:

  • in Firefox: Tools / Browser Tools /Web developer tools, and then select the Console tab
  • in Chrome: View / Developer / Developer tools, and select the Console tab
  • in Vivaldi: Tools / Developer Tools, and select the Console tab
  • in Safari it's Develop / Show Javascript console

At the > prompt at the bottom of the console, do the following – make sure to substitute your instance and account name in the second line!

req = new XMLHttpRequest();
req.open("GET", 'https://infosec.exchange/@thenexusofprivacy', false) 
req.setRequestHeader("Accept", "application/activity+json") 
req.send() 
req.response 

If you get an error like 401 (Unauthorized) or request not signed, that means your instance has enabled authorized fetch.  Here's what it looks like in Firefox trying to fetch the Nexus of Privacy account on infosec.exchange

 GET https://infosec.exchange/@thenexusofprivacy.   '{"error":"Request not signed"}'

If instead of an error you get a big blob of JSON code, that means your instance hasn't enabled authorized fetch.  Here's the first few lines when I test the Nexus of Privacy account on mastodon.social

A bunch of code, starting with {"@context":["https://www.w3.org/ns/activitystreams" ...

If your instance hasn't enabled authorize fetch, ask your admin if they plan to change that.  If not, consider moving to an instance that takes user safety.

Notes

0 The Threads supplemental privacy policy says they can use any data federated to them to "to provide measurement, analytics and other business services (including ads)" and to "improve Threads and other Meta Products" – presumably including using it to train AI models. Of course, on most Mastodon instances your profile is public, so this is data that they could potentially get in other ways ... but why make it easy for them?  

1 Today, many of the largest Mastodon servers haven't enabled authorized fetch (meaning that blocking is a lot less effective by default); as the lengthy warning in Mastodon's documentation describes, turning it on has some significant drawbacks.  In the upcoming Mastodon release, authorized fetch will  be turned on for anybody who blocks an account, so that should deal with that problem.

2 See footnote 0.

3 An earlier version of this post suggested that Threads could get at more implementation in this situation if their implementation changed, but a Mastodon developer clarified to me that the server (and maybe the time you're accessing it) is only information that's ever shared when you just view a profile or a post on another instance.

4 Actually it doesn't have to be Zuck's account, this will work with any profile on threads.net. If you'd rather block a hate group or an anti-trans bigot there are plenty to choose from! But Mark F***ing Zuckerberg's enabling them, so he's a good place to start.

Image credits

Thanks @box464@mastodon.social for the screenshot of the menu on the mobile app!

Update log

April 10: updated with new title and more detailed discussion of limitations.

March 24: first update, with the domain blocking file method, and then a seond update with both methods and a discussion of the privacy tradeoffs.

March 23: original version, with the profile-based method