![[0x0v1]](https://www.0x0v1.com/content/images/2023/09/0x0v1-1.png)
The great migration was a poignant part of internet history. When Elon took over Twitter, now X, many people migrated over to Mastodon. It was beautiful to see the mass adoption of a decentralized technology. A form of protest that echoed "power to the people" over big tech.
Decentralized models of technology are they way in which we can reclaim control of our privacy and security on the internet. Critical analysis of possible issues that may arise in decentralized models is also necessary. Mastodon, can be a brilliant place for us, but we need to do it right.
One of the key features of a fediverse is interoperability through the ActivityPub protocol. Interoperability, something I talk about a lot, it critical to building a open, fair and free internet. The ActivityPub protocol supports a federated network, allowing instances to share data between them whilst still being independent of themselves. These instances can be hosted by anybody and the connection between instances allows for a federated network. Since every instance is independent, the instance you use has its own set of rules, expectations and administration – all of which are overseen by the instance owner. A user can move between instances easily whilst keeping their following. This reclaims power back to the user if they aren't happy with an instance. As an administrator of an instance is required there is still a central power. The federated model makes it so that an instance owner has less authoritarian control than a centralized social media model, but nonetheless, it is still a central power. For that matter alone, we have to consider the risks to the sustainability of a Mastodon instance & also consider the privacy & security implications that may arise due to this.
There are many articles talking about the privacy concerns of a fediverse network. Many issues have been discussed, such as how an instance owner can see potentially private information. This includes data such as direct messages & IP addresses. EFF have covered many of these issues in their article on Mastodon. With the consideration of these privacy issues, we must also consider issues relating to freedom of speech, government regulations and anonymity. Centralized administrator owned instances brings about further potential issues relating to these, particularly when discussing server location & government intervention.
When picking a Mastodon server, you should consider where the instance is hosted and where the instance owner resides (if possible). If a Mastodon instance is hosted in a country where Government intervention is common, like the United States, matters of sustainability and privacy for that server are questioned. Furthermore, if the instance is hosted in a data-center where government intervention is frequently honored, this is also a critical factor.
To make this point more clear, I will talk about where my Mastodon account exists, on an instance called Infosec.exchange. The administrator of this server has been very receptive & clear about how they are operating the instance and has documented much of it on a wiki site. The admin, details that the servers are located in Germany & hosted by Hetzner.
The server being hosted in Germany gives me clear understanding of the legislation that I must consider when operating on this server. Let's consider, for an example, copyright law. Whilst DMCA is a US legal provision and not enforceable in Germany, there are similar mechanisms such as the European Union Copyright Directive that apply. If a users content on an instance is impacted by a DMCA or copyright law take-down request, the instance owner is not held to account so long as the they act in good faith. The DMCA and section 230 of the CDA shields operators from prosecution providing they honor the complainant request. If the instance owner does not honor the complainants requests by removing the copyrighted content, they can go to the instance provider, i.e the server host. In this example, if the administrator of my instance got a DMCA take-down request for content and didn't honor it, the administrator would likely face issues since they are the only person in legal reach. The likely outcome of this, would be the complainants reaching out to the server host, in this example Hetzner. If we look at Hetzner's comments on DMCA take-down requests they state:
We handle all of our abuse cases on a case-by-case basis. However, as a general rule of thumb, we will give you a short time to fix the problem and respond to our Abuse Team's message. If you fix the problem and communicate clearly with our team, that will help. If problems re-occur, our team will take stronger steps (locking your server, cancelling your account). If you have questions, respond to the ticket as soon as you can to prevent possible downtime.
If an administrator does not correct the complaint, the instance's server host could take the server down. This raises a case for concern regarding sustainability.
In more serious cases, if an Mastodon user or even an administrator is under threat or investigation by a Government entity, the server location can dictate that entities ability to seize the server for criminal investigation. Germany, for instance, will honor warrant requests by cooperative nations, such as the US. If an investigation involves a user on an instance, the data-center provider may end up turning over data from a server without the need for the instance owners permission. If the server is hosted locally by the administrator, authorities may end up being able to seize the server physically.
This can have massive privacy implications for all users of a Mastodon instance. One real life example of this is discussed by EFF where the fediverse instance Kolektiva had it's database seized by the FBI. The seizure exposed personal information, hashed passwords, IP addesses & direct messages to the FBI. This raises many questions as to the administration of the server. EFF detail that the server administrator was targeted in a raid during maintenance work which left the "would-be-encrypted material on the server available in unencrypted form at the time of seizure". Two important factors should be considered here:
- Server location & hosting provider
- Administrators protection of the server
The server location and hosting provider is critical. In the Kolektiva example, according to the statement by the admin, they had their home raided and all electronics seized due to alleged participation in a protest. The Kolektiva instance was clearly hosted in a country where the FBI had authority to seize the database. If it was hosted in a cloud data-center and had been a provider that honored the FBI's seizure requests, it would have still been impacted. This may not have been the case if it were hosted by a bulletproof off-shore provider.
Moreover, the administrators protection of the server is something we cannot guarantee. We would like to assume all instance administrators have correctly ensured the encryption of our data on a server, but we cannot guarantee that. Kolektiva is a case and point, the administrator stated:
In mid-May 2023, the home of one of Kolektiva.social's admins was raided, and all their electronics were seized by the FBI. The raid was part of an investigation into a local protest. Kolektiva was neither a subject nor target of this investigation. Today, that admin was charged in relation to their alleged participation in this protest. Unfortunately, at the time of the raid, our admin was troubleshooting an issue and working with a backup copy of the Kolektiva.social database. This backup, dated from the first week of May 2023, was in an *unencrypted* state when the raid occurred and it was seized, along with everything else.
Unfortunately, we cannot of course determine if this is true. But non-the-less, I'd like to think precautions could have been made to ensure this didn't happen. Personally, there are some failures I see here:
- Local unencrypted copies of the data
- No staged canary deployments
- No safeguards to lock down local machines (particularly when the administrator was involved in legally risky ventures)
- The administrator took two months to notify users of the seizure
By no means am I suggesting Kolektiva shouldn't continue to run, but there's a lot we can learn from this.
Mastodon's design is in many cases an issue, since it's federated, centralization still exists in the model – it's not truly decentralized. A instance can be shut down or seized by an authority. That authority can be a hosting provider or a government entity. This is an issue that is the sole responsibility of the instance owner. An instance owner must consider where they are hosting the server and how they are ensuring the encryption of the data. Further implementations, such as end-to-end encryption in direct messages have been mentioned tirelessly to Mastodon developers. It does look like this is being worked on and once implemented will support administrators in safeguarding users in light of a government intervention.
What I would like to see more of, is users of instances demanding clear documentation from administrators on where servers are hosted. As a user, you must ensure you are aware of where the instance you are using hosted. You may wish to look for an instance that is using bulletproof hosting or the likes to safeguard yourself against any government or host intervention that may impact your privacy. Finally, you must ensure that you are aware of what the administrators are doing to protect your data from host or government intervention.
About this website
I am Ovi, I am an independent researcher. My work is solely related to human & digital rights activism focusing on reverse engineering, data privacy violations & surveillance from hostile government and private organizations that threaten humanity. I work with non-profit groups and directly with those at risk. As an independent researcher, getting my research, work and writings out can be hard, which is why I created this website. You can read more about this here. If you feel that you value this work, please consider subscribing, which will allow me to share my work directly with those who appreciate it without having to work with media organizations. Your subscription helps support me and my work, and also develops the space for independent researchers to truly be independent. If you do value my work and wish to support me financially, you can do so here through Ko-Fi.