“Digital Self-Reliance” is a topic that, if you’ve followed me on Twitter or had the misfortune to pick me out of a crowd at a bar, I talk about a lot. The impact that digital monoliths have on our day-to-day lives as internet users is frankly jarring. When a monolith goes down or has service disruption, as happened to google several times in 2020 alone, the internet gets sent into a frenzy. In the case of major service providers like Google, AWS, or Azure, those outages can cause significant financial and organizational disruption. As a backend systems engineer I’ve had to deal with the runoff effects of outages like these many times over. Companies typically have disaster recovery plans, but do you? Does your organizing group have the means to continue to organize and collaborate without the presence of digital monoliths?
The Problem, Briefly
This is where digital self-reliance starts to come into the picture. However, while the above example of a “disaster-recovery” scenario is certainly one to consider, it is not the only argument for digital self-reliance. The fact of the matter is that digital monoliths are run by private corporate entities, each with their own content policies and enforcement behaviors. Twitter already has a problem enforcing its own rules regarding transphobic content on its platform. Facebook and YouTube have both been center-stage in conversations over radicalizing and dangerous content. It takes concerted efforts from anti-fascists and other concerned parties to get Amazon to take down sites hosted on AWS which espouse violent white-nationalist rhetoric. In a very concerning trend, Tik-Tok tends to allow posts with racist language from white creators to stay online, while frequently deleting or outright banning BIPOC creators who call those posts out. We cannot reasonably rely on these platforms to consistently provide service. Hostile content moderation, service disruption, and security failures all present large challenges and risks to organizing groups and individuals. Digital self-reliance presents a response to this problem, albeit with caveats.
The Basics
Let’s start with defining the concept a bit. Digital self-reliance refers to a concept of not only technical skill, but also security practice, digital literacy, and structural resilience. Depending on your position in a given group, and your comfort with technology, the scope by which you practice digital self-reliance will differ. From a non-technical perspective, this means building an understanding of the risks associated with putting content on a given platform, and practicing basic operational security (often shorthanded as ‘opsec’). Building good security habits is probably the most crucial in this category. That doesn’t just mean not re-using passwords (you shouldn’t, and you should consider using a trustworthy password manager), but also being deliberate about the information you give out. Consider the reach of what you post. If it’s on Twitter, and your account is public - that information is permanently visible to anyone and everyone. If your account is private, there’s some degree of restriction - but you can’t always be entirely certain that the accounts you allow to follow you are actually who they say they are. The term to describe this is a chain of trust. Following each link along the chain from yourself, to the server your post is hosted on, to each individual who might be able to see that information. You should be able to assign a degree of security or “trust” at each link on that chain. Trust, in this case, refers to the reliability of each link not to share that information, be it deliberately or through operational vulnerability (easily cracked passwords, unsecure operating procedures, etc.). As the saying goes, a chain is only as strong as its weakest link.
Security practice is the primary skill anyone should start with when building digital self-reliance. The points discussed beyond here are near useless if the security practice in place is lackluster. From there, we can start to look at resilience planning. Does all of your organization happen on Facebook groups? Do the majority of your communications come from Twitter? While these platforms are powerful tools, they shouldn’t be considered the final stop for your technical infrastructure. Always have a back-up plan. For communications, consider having an opt-in mailing list or backup group-chat to fall back on for general communications. Fine-grain planning shouldn’t happen on these platforms regardless, as that presents a potential security hazard. Does your group have its own site for members to get information in the case that a primary service in use is down? Setting up a free website on a service like wix or github pages can provide basic contact and background information for your group. Even better, if you or someone in your group has some technical skill, setting up a self-hosted website with a cheap domain and web host provides an even greater degree of control and self-reliance.
Familiarize yourself with data concepts as much as possible. Encryption is a key point we see talked about a lot in the media especially, but much of the discussion outside of technical circles can often miss a critical point: what type of encryption is in use? End to End (E2EE) vs Client to Server or “Transport Layer '' encryption are the two major forms of encryption in use day-to-day. Encryption itself is a method of taking a piece of data, say a message, and using a special key to convert it into a sort of scrambled unintelligible form that can’t be read without having a separate, complementing key. When you send a message on a service which uses transport layer encryption, that data is sent from your device, to the server that hosts the platform, and then unencrypted to be stored or operated on. The message is then (maybe) re-encrypted from the server to its destination(s). On the other hand, End to End Encryption works by having every receiving party decrypt the message you’ve sent, without the managing server(s) ever seeing the contents of your message. End to End Encryption offers more security overall, although the specific implementation of the key-sharing process (especially with regards to group chats) can vary in overall security. This is all getting very technical, so let’s roll back to the core point: we now know that there are a few different methods of handling encryption, and they have different methods of handling our data. From a security practice perspective, we want to pick a method that presents the least “stops” (in tech parlance you’ll often see these called surfaces) for a third party to view those messages.
Combining security practice and a basic understanding of how data is transported in a given service is a fantastic start for building digital self-reliance. Building fallback services and resilience is an added bonus, if that is a viable option for you or your group.
Federation and Decentralization
Something which comes up often in conversations about digital monoliths, especially Twitter, is federation. Mastodon, which provides similar micro-blogging functionality to Twitter, is generally the go-to example in this regard. The appeal with it, as well as other federated services, is the underlying “structure” of how the service is provided.
Starting at the basics, a website - at least, those on the normal world-wide-web - runs on at least one server. Typically, for a service like Twitter, the actual architecture in practice is a little bit more complex than that, but for now, just keep in mind that any service on the internet has to have at least one server behind it. The trouble here comes with ownership. Because twitter owns all of the servers running its services, it has a complete authority over how its platform runs, who has access to it, and what content people can and can not see. This goes likewise for any privately controlled platform. Federated services, by comparison, are not solely hosted by one specific controlling group. There are organizations which might manage the standard that governs how that service works (rules for how one server can talk to another), but the ability to host an instance of that service is open to anyone with the means and time to do so. Since the communication protocol is open and strictly defined, any two servers running the same service can choose to “federate”, meaning that they will communicate with each other and share information from one server to the other.
There are benefits to this structure. Firstly, there is no requirement that any one server must federate with the others. It is entirely possible to run a single, un-federated instance of Mastodon, meaning users who post on that instance will only ever see posts from other users on that same instance. Likewise, a server administrator can selectively federate with other servers. For example, an administrator who sets up a catalan-language Mastodon server could choose to selectively federate only with other servers which are entirely or primarily in catalan. These links are arbitrary and flexible, and allow for a group of servers to make up a networked platform that is significantly more resilient than a centralized service. A single host or even a group of hosts may go down, but the remaining instances will continue to work and communicate unimpeded.
Microblogging isn’t the only place federation exists. There are federated blogging platforms, instagram-style picture sharing platforms, irc-like chat platforms, and many many more. These services offer a potential avenue for digital self-reliance without necessarily sacrificing scale. Mastodon, while still certainly small compared to Twitter, has a fairly large user base at this point. In fact, there are numerous leftist-oriented mastodon instances running right now. Of note is the anarchist-created kolektiva, run by the people at It’s Going Down. Likewise, The Anarchist Library runs its own Matrix instance, a federated chat service which functions a lot like IRC. These services offer a resilient alternative to the more monolithic structures otherwise used, such as Twitter or Discord.
Often, federated services are referred to as “decentralized”. While, from a thousand-foot view, this isn’t entirely wrong, it’s also not technically correct. From a technical perspective, decentralization can refer to one of two things:
- Something which is not run and controlled by by a singular entity
- Something whose function is not predicated on a specific server/cluster to facilitate function
In both cases, federation doesn’t exactly meet the mark of decentralization. While a given federated platform is not singularly controlled, and thus somewhat “decentralized”, each individual instance is. To the second point, there is no way currently that a federated service can run without some sort of central server or cluster that runs the instance in question. This isn’t a huge deal, in everyday practice, but still has ramifications when we look beyond current contexts. Consider, for a moment, a political crackdown on internet services. Service providers are made to shut down or otherwise block objectionable content. It’s not a particularly unimaginable scenario for some. Under these conditions, a federated platform could face real issues with staying alive, if it can at all. The simple fact that the services must be hosted on some server which takes traffic to a dedicated address means that locking out services like these is entirely possible.
Enter true decentralization. While the world-wide-web requires a myriad of dedicated servers all orchestrated to guide you on your path and deliver the content you’re requesting, a decentralized web protocol operates on a completely different paradigm. There are a few different implementations of this concept, but the most notable is IPFS. While this technology is still largely in its infancy, it presents a fantastically resilient answer to the problem of centralized internet services. The scope of decentralized technology reaches beyond the internet as well. Messaging app Briar supports mesh-networking over bluetooth. This means that in a large protest setting, activists can go semi-offline, or otherwise cell service could be blocked, and those activists could still communicate with each other given enough other activists are also using the app. Without going into the weeds on the fine details of decentralized technology, the potential for extremely resilient organizing and communication methods it can provide are a major aspect of upcoming development that bears keeping an eye on, and where possible, utilizing.
Against the Monoliths (Digital Self-Reliance as an Ideal)
The internet of 2021 is starkly different from that of the early web, or even of the 2000s. Digital monoliths dominate the landscape, both in the user and infrastructure spaces. Google/Alphabet, Microsoft, Amazon, Facebook, Alibaba, and Twitter represent the majority of the web usage “share”. Where they do not directly control a site, they often have presence through cookies, Single Sign On (“login with ____"), and content delivery. This extremely broad reach is concerning. It means that fewer and fewer users on the internet are viewing and engaging with content out of their reach. It means that, for many, the means by which they can provide themselves a living are fundamentally at the whims of these monoliths. In a very real sense, the digital monoliths can enact a broad degree of control over what can flourish on the web. The “free and open internet” is increasingly less free and open, if it ever has been.
Digital self-reliance from an ideological standpoint proposes a resistance to this paradigm. It involves developing a keen understanding of the various structures in place. To be digitally self-reliant means both to be able to adapt to the consequences of this current state of the internet, as well as advocate for and work towards a future where digital monoliths do not implicitly control such a huge share of the web. It means building skills to support your usage of the internet through non-standard models. Tools like Twitter, Facebook, Google, et al. are incredibly useful and should not be discounted in their modern-day contexts. We should use them while we can, but we cannot expect that they will always be there, be it due to catastrophic financial failure or simply because they decide that banning activists is worthwhile. Whatever the reason, we should have fallbacks. Resiliency should be baked into our organizing - on the ground and online.
Wrapping it up
I do not expect that every group will have the means to practice every aspect of digital self-reliance. Some aspects of this ideal apply to on-the ground practices as well. As activists and organizers we owe it to ourselves to build safety into our groups, both in a security and resilience context. While much more could be said here about each individual action one could take to build digital self-reliance, the overall goal remains the same: to respond to the dependencies and risks manufactured by digital monoliths as well as the hazards and risks associated with online organizing. We cannot guarantee for ourselves the stability or future of any platform we do not control, and we can not guarantee for ourselves any trust we do not implicitly know. In the uncertain and increasingly consolidated world of technology, making choices to deliberately revoke reliance on monoliths is one way we can foster distinct control of our digital environment.