How to block Threads on Mastodon - and a reminder that blocking on the fediverse only provides limited protections (NEW VERSION)
With screenshots!
"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.
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 using the Threads app won't be able to any new posts you've made after you blocked Threads, and you won't get notifications if people on Threads tag you. In practice, as I'll discuss near the end of the article, it's a lot more complicated than that. For one thing, if your instance hasn't turned on "authorized fetch" then blocking in general isn't particularly effective. Even if authorize fetch is on, the protections are imperfect; in some circumstances, bad actors may on Threads still be able to see to your posts and interact with them. Still, while domain blocking's not even close to bulletproof protection, it's a good first step.
Important: Blocking on the fediverse only provides limited protections. 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.
Being on an instance that's blocked Threads provides somewhat stronger protection than doing it yourself. 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 of instances haven't blocked Threads. That's good for people on those instances who aren't concerned about the hate groups on Threads, and are willing 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 you can block threads.net, the domain that Meta's currently using to host Threads.
- Viewing the profile of anybody on Threads through your Mastodon account gives you the option of blocking threads.net
- The Data Import functionality in your Preferences lets you upload a "domain blocking list"
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 the limitations of domain blocking on the fediverse, spreading the word and supporting FediPact creator Vanta Black.
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).
Type @zuck@threads.net (Mark F***ing Zuckerberg's Threads account) into the box.4
Hit return, and it should bring you to the search results.
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.
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
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.
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
Yay!
On the Mastodon mobile app, the menu's slightly different:
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.
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.)
That will bring you to a page something like this ...
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.
Once you're done, the page should look like this.
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:
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.
If it saying In progress, wait a bit and hit refresh. At some point, it'll hopefully show that the import has finished.
Yay!
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 bugs in the software make can 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!
- 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.
- Some apps access data in a way that ignores or evades blocks. Threads would probably get into trouble with EU regulators if they did this in their official app, so my guess is they won't (the risk/reward tradeoff doesn't seem right) – and if they do, I'm sure we'll hear about it in a hurry. Still, people with accounts on Threads could potentially use these apps to get at your content And if you're using one of those apps, there are situations where you might see posts from Threads in your feed even though you've blocked it.
- 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, or the same test showing different results. Open Mastodon bugs include User domain blocks do not prevent viewing updated profile information and Blocked or muted accounts still appear when boosted, and there may well be others that haven't been reported.
Also, keep in mind that on most instances (servers), anybody can see your profile and your public and unlisted posts from a web browsesr 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 using the Threads app shouldn't be able to see any new posts you make, and the only posts and notifications you'll see from Threads are due to bugs in the software.
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
If you get an error about something related to the "Content-Security-Policy", the site's security settings mean the test hasn't given any useful information about authorized fetch. This can also happen if you've the test from the developer tools for a tab that's logged in to a different server; double-check to make sure you were doing it from a new tab that's not logged in.
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.
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 15: shift detailed discussion of limitations to later, tighten up intro
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