which works closely with the State Department's regime change arm and is funded through several layers of Cold War CIA cutouts — including Radio Free Asia and the Broadcasting Board of Governors (Levine 2016).

Telegram creator Pavel Durov's critique of Signal goes in the same direction, stressing that no US-government funded application can be trusted.

Beyond Signal's 'non-standardisation as a business model', centralised end-to-end encrypted secure messaging applications propose different business models, though it seems that no ideal solution has yet been found. Wire's project is to propose paid services to users for supplementary storage space (encrypted Cloud services). Wire also proposes business solutions for end-to-end encryption of the Internet of Things. Threema, one of the few end-to-end encrypted applications requiring a financial subscription from users, asks for a $2 contribution per user. Some users underline that as an advantage: 'All of us use Threema [...] I prefer to pay, at least I am sure that I am not the product' (Cryptoparty organiser, male, Austria).

As in previous histories of software development, for Signal and the ecosystem of applications using variations of the Signal protocol, the licensing, business-model and open/closed source choices turn out to be complex sociotechnical processes that are embedded in both community-related interactions, economic context and legal arrangements.

## CENTRALISATION CALLS FOR CENTRALISATION? SIGNAL'S 'DEPENDENCIES' CRITIQUED

Though the Signal protocol has enjoyed extensive attention from academics and has been formally verified, with only minor flaws found, several users and tech-savvy communities have critiqued the tool — critiques that were highlighted during our interviews. Interestingly, some of these critiques do not concern cryptographic properties of the protocol per se, but are focused on the
application's UI/UX, privacy features and the particular architectural design choices that bind Signal to other applications and protocols that are, in their turn, under scrutiny by particular communities because of their centralised and/or proprietary structures.

## De-Googling Signal: The LibreSignal controversy

First of all, tech-savvy users – especially crypto trainers from low-risk countries such as Austria, Germany and France – have pointed out Signal's dependence on Google services. They see it as a negative from the standpoints of both open-source community ethics and privacy, the two main points of controversy being Signal's relationship with Google Cloud Messaging (GCM) services and its reliance on Google Play. As a consequence, two initiatives were launched in order to 'decentralise' or 'de-Googlise' Signal: The F-Droid repository,⁵ which aimed to distribute Signal outside the Google Play Store; and a Github repository, which aimed at completely removing the Google components of Signal, even from the server side. This second project was called 'LibreSignal'. Open-source client used the Signal protocol and was lauded as 'The truly private and Google-Free messenger for Android'.

LibreSignal's authors stated on their GitHub page that the problem of Signal relying on GCM 'is only an issue for people who use a custom Android ROM without Google Play Services. For the vast majority of people who do have Google Play on their phone, this issue is completely irrelevant'.⁶ Thus, the Google dependencies of Signal are problematic only for a very specific user community, both privacy-aware and tech-savvy (those who, like the mail service provider cited in Chapter 1, 'do not like mainstream on [their] computer'), who opt for decentralised communication tools explicitly designed to be alternatives to those developed by the Silicon Valley tech giants. In this context, the choice of a 'Google-free' messenger can be perceived and defined as a 'lifestyle' choice. During our interviews, we noticed that this choice often coexists with alternative hardware choices (Linux phone, Fair Phone, CopperheadOS and others), or customised versions of the Android operating system, in particular versions free of Google Play.
LibreSignal was launched in 2015 but its development was stopped in November 2016 after a long online discussion between the LibreSignal team and Moxie Marlinspike. LibreSignal started as a fork of TextSecure,⁷ that several open-source contributors forked by integrating an alternative to Google Cloud Messaging, called WebSocket.

LibreSignal published a **build** on F-Droid, the community-maintained software repository for Android, similar to Google Play but containing only free and open-source apps. However, in the course of a discussion on the GitHub repository of the project, Moxie Marlinspike controversially demanded that the name of the fork be changed (not referring to TextSecure or Signal), and that it should not use Open Whisper System servers. He also insisted that no distribution of Signal via FDroid was possible.⁸ The debate between LibreSignal and OWS raised several issues that are important for the overall understanding of the sociotechnical and legal problems related to the debate about centralisation in secure messaging, and its relationship with projects focused on federated architectures (see also Chapter 4). A first argument concerned the server infrastructure needed for federated projects, which seemed complicated to set up and maintain, compared to the 'forking' of the client-side code. The latter does not, as the former does, demand coordination efforts between different agents: developers are able to fork and experiment on their own without having to care for the server infrastructure. However, the process of publishing a build on any of the app repositories – the open-source oriented F-Droid or the proprietary GooglePlay – demands a greater coordination and enrolment of a multitude of actors, as well as adherence to a number of legal and technical standards. This problem of federated protocols, as opposed to centralised ones, which we will come back to in Chapter 4, was also underlined in our interviews:

> Obviously, I think that federation is good otherwise I wouldn't be doing Conversations or using XMPP. But of course it's more challenging to do. Because you have to coordinate with a lot of different vendor (ChatSecure developer).
In the case of Signal, the problems of forking and federating the protocol – as LibreSignal intended to do – turned out to be legal (disputes concerning the use of the Signal trademark), technical (the quality of LibreSignal builds, questioned by OWS), and financial (the costs of running servers).⁹ Ultimately, the enflamed debate about the LibreSignal GitHub page led Moxie Marlinspike to publish his standpoint on federation and centralisation in a blog post, ‘The Ecosystem is Moving’, which would become a landmark intervention in the controversy surrounding architectural choices in secure messaging (Marlinspike 2016). The Signal team was accused of not being ‘truly’ open source because of their refusal to draw upon open federated protocols. Comments such as ‘The problem is that Moxie and OWS don’t want Signal to be 100% free/libre software (it is not important for them … )’ or ‘They are not interested in removing the Google GCM dependencies [...] Moxie has been quite explicit on this point, several times’ were commonplace.¹⁰

Starting from 21 February 2017, Signal could be used without dependencies upon Google services. As Elijah Sparrow, the creator of LEAP (see Chapter 4) explains, the long process of ‘degooglising’ Signal is related to an important technical problem, that of notifications, that demanded infrastructure investment:

LibreSignal was an attempt to avoid the Google services push. The problem with push on mobile is that it’s a very difficult problem to be able to push events to mobile devices without burning the battery and without setting up a complex infrastructure for that. So you can rely on Google infrastructure for that, it’s more efficient and they do it for free. But it’s controversial [...] mostly because it requires to install all Google services on your device, which means you basically have to turn your device over to Google that always finds ways to gather your data so you couldn’t run Signal on a Google-free device. That’s recently changed, Signal very recently supports push notifications without Google services [although] Moxie still insists that no one should distribute the Signal application outside the Google Play market because he wants to get bug reports and data who’s running and how they are running it when it’s crushing (LEAP lead developer).
The problem of Google Cloud Messaging dependency and push notifications was addressed by other projects that found different solutions to this problem. For example, ChatSecure uses its own system for push notifications – a complex system, based on randomised tokens – that claims to have better privacy properties than the one used in Signal. For its part, Wire claims to be ‘pretty much Google-free’; however, it relies on another ‘net giant’, Amazon, for push notifications and analytics. Wire’s CTO describes the transition from Google services as a long evolution, marked by a dependency on Google’s ‘reputation’ privacy-wise:

> [Being free of Google] took time... It wasn't easy. As you know maybe, when we started Wire 3+ years ago, Google was already under suspicion but there were some people in the company who were Google fans, now they are completely disillusioned [, nonetheless] it took us some time to take away all of the Google stuff (Alan, Wire CTO).

## ‘ID’D BY PHONE NUMBER’: THE PRIVACY WEAKNESS OF CENTRALISED APPLICATIONS?

The second important controversy focused on Signal concerned the usage of phone numbers as identification mechanisms. Although the Signal protocol provides confidentiality, it involves exposing phone numbers to the server and so allows the server – despite efforts by Signal, acknowledged by the tech-savvy public, to minimise logs – or a passive adversary to capture all the metadata, including the social graph of users. This phenomenon is not specific to Signal, but common to the majority of popular IM apps that are based on centralised architectures. As a consequence, having users’ phone numbers as an identification mechanism is considered one of the central problems of post-Snowden end-to-end encrypted secure messaging.

The developer of Heml.is and Pirate Bay, Peter Sunde, as well as Wire’s CTO, Alan, argue that identification via phone numbers and the possibility of sharing a user’s phone contacts are important for contact discovery: they help users to build their network of contacts, and to rapidly find other users in their
phonebook who use the same messaging app. An easy contact discovery is
important, according to Alan, to build contacts and stabilise users' relationship
with a new messaging app:

> In the beginning we didn't have a possibility to have your phone number to register, we wanted to have just emails. But then we had an amazing two days with hundreds of thousands of downloads, even millions [however] we could not build a good network effect. People were just downloading it individually and not connecting to each other. So we went towards [having] your address book uploaded so it will help you to have some contacts established, and then once people have contacts, they stick with Wire (Alan, Wire CTO).¹¹

Here Alan raises an important issue, also underlined by several users in our inter-
views, which we call the ‘migration problem’: how do we migrate our contacts
from one IM to another? Or inversely, how do we ‘stick with’ a new IM if no
one from our social group is using it? A significant number of our respondents
among non-tech savvy users explain the weak adoption of PGP and Signal
with reference to the unpopularity of these tools among their peer groups (‘no
one uses it). Moxie Marlinspike also underlines how secure messaging tools
are far from being immune to the network externalities effect, well-known and
documented for social networks (e.g. Zhang et al. 2017):

Social networks have value proportional to their size, so participants aren't motivated to join new social networks which aren't already large. It's a paradox where if people haven't already joined, people aren't motivated to join (Marlinspike 2014).

This effect also becomes an important factor for advising on IMs choices
during security training sessions. For example, several Ukrainian trainers whom
we interviewed tended to recommend WhatsApp and Gmail over Signal,
and PGP over Thunderbird, partly because users already have some of their
contacts using these tools, and the transition/adoption costs are lower (see
also Chapter 1).
Eventually, Wire decided to move away from the use of phone numbers as an
authentication method, and to give users the option of signing up only with an
email address. On 25 May 2017, Wire added to its system the option to delete
a previously registered phone number and adopt email-only authentication.
This design solution was partly influenced by the critiques addressed to Signal,
and as a 'selling argument' means of distinguishing itself from the latter. Wire
largely promoted this new feature on social media and published a guide on the
specific subject of 'staying anonymous on Wire'. Anonymisation became one
of the app's core features - giving users the possibility to subscribe using a fake
email account, over VPN or Tor, providing almost no personal information
(Wire 2017). In general discussions, this feature also became a popular argu-
ment in favour of adopting Wire over Signal, as could be inferred both from
our interviews and from social media and press analysis. Eventually, Edward
Snowden came to recommend Wire as an alternative to Signal for those users
wishing to stay within the realm of centralised applications.¹²

As the controversy unfolded, the use of phone numbers as an identification
mechanism appeared to be related to the centralised architecture as such, making
it more complicated to consider a transition towards federated systems. This
issue was closely linked to the critique of telecom operators, perceived by several
developers as fundamentally driven by a proprietary culture, and untrustworthy
in terms of privacy. Using phone numbers as an authentication method is seen
as linked to the increase in metadata collection (see the following section), and
as opposed to alternative methods of identification, used in federated systems:

With Signal it's impossible to create a decentralised system because phone
numbers aren't decentralised. With XMPP it's like an email address. Even
users who aren't technologically savvy can understand: this is my user
ID, and this is my server. We have no idea what server you use and what's
your ID. It's on the client side, and we don't need it for pushing messages
(ChatSecure developer).

The lack of confidence in telephone numbers as a means of authentication is
grounded in specific episodes of digital infrastructure-based attempts at state
control in collaboration with the private sector (Musiani 2013). For example,
in Russia, the use of phone numbers as IDs has been a source of important leaks
and attacks on Telegram, another widely used centralised secure messaging
app. On 29 April 2016, the accounts of two opposition activists from Moscow
were seized by the Russian government: in collaboration with the telephone
company MTS – which both activists subscribed to for their mobile commu-
nications – the government deactivated the SMS delivery service for the two
users, and reclaimed recovery codes for their Telegram accounts. When these
codes reached the MTS servers, the police could intercept them and use them
to access the activists’ accounts. Pavel Durov, the creator and core developer of
Telegram, highly recommended using **two-factor authentication** in order
to prevent this kind of attack – a method that is also recommended during
cryptoparties – and to reinforce protection of accounts on centralised end-to-
end encrypted messengers.

Overall, our research demonstrated that high-risk, tech-savvy and privacy-
concerned users are aware of and preoccupied by the possibility of their phone
numbers being used for identification. Similarly, the usage of existing users'
social graphs – especially using third-party authorisation mechanisms, such
as Twitter, Gmail or Facebook authentication services – was widely criticised.
Wire's introduction of a 'matching' feature, suggesting new contacts based on
a particular user's Wire contact list, was also attacked as 'creepy' by some of
our respondents (tech-savvy security trainers from Austria and Germany).
Ultimately, the 'phone numbers as IDs' controversy suggests that – among
specific communities of users and developers in particular, but post-Snowden,
more widely among the general public – there is a strong need for an alternative
contact discovery mechanism that would give users better control over their
social graphs.

*Metadata collection: A misunderstood and unsolved issue for*
*centralised applications*

Some secure messaging solutions, like the experimental Ricochet,¹³ attempted to use Tor to hide the IP address of their users. However, none of the popular
Signal-based messengers hide metadata, even though its users often believe that Signal indeed protects metadata and keeps their conversations anonymous. Although Signal does not log metadata (besides the last time a user installed the application and the time of her latest connection), it has been argued by one of our developer respondents that a real-world adversary could simply watch the encrypted messages going in and out of the Signal server in order to capture, to a large degree, the social graph of its users.

Even more easily, the physical seizure of a device would reveal the phone numbers of all other Signal contacts. Although applications such as Ricochet attempted to achieve protection against this kind of threat – which is a particular worry for users living in authoritarian countries – high-risk users are in general much more aware of the existence of Signal and find it easy to use, while all interviewed users were unaware of attempts at possible alternatives, such as the anonymised Ricochet application. In short, the issue of metadata collection (see Chapter 1) is one of the most controversial in the field of secure messaging today, as on the one hand, developers recognise that there is currently no satisfactory way to limit it or prevent it altogether, and on the other hand, it is an issue largely misunderstood or misinterpreted by users – even users who are informed and concerned about the problem – who believe they are completely anonymous when in fact they are far from it.

In the absence of solutions that prevent metadata collection, ‘selling arguments’ by different IM services have focused on its minimisation. Wire, for example, claims to reduce metadata storage of its messages to 72 hours, and this only to follow up on abuse or for troubleshooting reasons. In this sense, the minimisation of metadata collection is meant to single Wire out with respect to other IM applications:¹⁴

[For Wire] what was important was end-to-end encryption as a first step. But besides, there is a whole new dynamic that needs to happen, related to all of the metadata and what, how, it is used for. So the first step is to absolutely minimize all of the metadata. This is the part we are currently heavily working on, and some of the metadata we have was here for historic reasons. When you launch an application first without end-to-end encryption and
then you upgrade it to support end-to-end encryption there is still some
stuff left from the previous implementation. This is something that we are
cleaning up (Alan, Wire CTO).

Based on our interviews, it's clear that most developers have come to consider
the improvement of privacy via the minimisation of metadata collection to be
the second most important feature in IM after the development of end-to-end
encryption itself. Yet interestingly, developers themselves sometimes misinter-
pret the issue of metadata collection, confusing whether or not a third-party
adversary could be passively monitoring the communication – and thus col-
lecting metadata – with whether or not they, as developers, personally collect
data – as exemplified by one developer who candidly stated, ‘I do not have
anything in my code that would let me know how many people are watching
the app right now’. Other developers – a majority – declare their full awareness
that they do have to collect some metadata in order to interoperate with features
such as push notifications of arriving messages; however, they try to limit the
collection as much as possible, to minimise harm:

With push messaging, it's the first time we're exposed to possible metadata.
But we don't log anything, we don't know who is talking to who, we don't
log any information. We designed it specifically to be as harmless as possible
[and] I think we're going to enable server operators to run additional com-
ponents that reduce exposures as well. There's now some level of registration
with our servers but it's optional. It's required to use push-messaging, but
if you use an account with TOR, we disable this information (ChatSecure
lead developer).

Most developers who are aware of third-party data collection of metadata
declared themselves supportive of using Tor and disabling the collection of
phone numbers in particular, but they lacked a comprehensive plan to mini-
mise the collection of data as such. High-risk and low-risk users alike generally
supported reducing data collection and increasing privacy, although often,
non-trained users assumed that end-to-end encryption in itself could hide
metadata. Thus, as the reader may recall from Chapter 1, developers and information security trainers underline the urgency to find a reliable solution to the metadata collection problem and state that, at present, nothing in the field of end-to-end encrypted instant messaging apps offers good metadata protection. Furthermore, developers and trainers associated the leaking of metadata with centralised servers – which, as Peter Sunde mentioned in a previously-cited interview, become ‘honeypots’.

## POLITICISED (AND CENTRALISED) ALTERNATIVES TO SIGNAL: THE CASE OF TELEGRAM

As this chapter has shown, for a number of reasons that range from its centralised architecture and the perceived technical soundness and novelty of its features to its business model and relationship to standardisation bodies and open-source communities – and despite a number of controversies around its development and implementation – Signal has come to assume a central role in the secure messaging field. Yet the ‘ecosystem’ surrounding it is lively, including other centralised architecture-based applications that – unlike Wire or ChatSecure – are not based on the Signal protocol.

A case in point is Telegram, which was briefly introduced in Chapter 1. Telegram’s client-side code is free software, while its **server-side** code is closed-source and proprietary, favouring centralised management; furthermore, Telegram has a centralised architecture, as it runs servers on which correspondence is clearly stored. Telegram’s accounts and identity authentication are also tied to telephone numbers. While these features lead both developers and users to situate Telegram unambiguously in the realm of ‘centralised’ services, it remains the most popular secure messaging app for some user populations – in our research, notably Russian users.

According to our interviews, the usage of Telegram may vary quite substantially according to users’ goals and threat models. Several functionalities of the app make it convenient for different user groups: chats, secret chats, group chats, bots and channel broadcasting. Users faced with a low level of threat, not associated with any political activities, tend to adopt Telegram as
an alternative to WhatsApp, using it for sending short messages in everyday conversations with their peer groups. Many activists and privacy-concerned users are aware of the absence of 'privacy by default' in Telegram chats (client-to-server encryption); however, they do not always opt for a 'secret chat' option that offers end-to-end encryption. This user group sometimes adopts two-step authentication and self-destruct timer options. Functions such as 'Group chat' are used for group conversations and are popular among activists, journalists or researchers for organisational purposes, as an alternative to Google Groups or mailing lists.

For example, one of our use-cases, a group of researchers working in Eastern Ukraine, use Telegram on a daily basis to coordinate research activities and discuss fieldwork, materials and other organisational information. However, they do not rely on Telegram for very sensitive discussions and prefer face-to-face offline meetings. During Russian anti-Putin protests in spring 2017, Telegram was also very popular, regardless of previously detected security flaws and the absence of end-to-end encryption in group chats. Telegram group chats remain popular among high-risk users despite the fact that the encryption for group chat offered by the app is very basic.

The popularity of Telegram in Russia can be partly explained by the reputation of its founders, Nicolai and Pavel Durov, Russian-born developers and entrepreneurs. Pavel Durov, the founder of Vkontakte, the most famous Russian social network, is colloquially referred to as the 'Russian Zuckerberg' and became *persona non grata* in Russia after his refusal to collaborate with the FSB. Telegram's swift rise on the market of messaging apps reveals a lot about the socioeconomic factors that influence the success of an innovation in the field of secure messaging: indeed, when Facebook bought WhatsApp (resulting in a lengthy black-out for the latter), the Telegram download rate exploded. In contrast to WhatsApp, Telegram can publicly underline its not-for-profit character and lack of ties with any commercial or governmental services.

While the Russian version of Telegram was released in 2012, before the Snowden revelations, Durov claims that the international version of his tool was inspired by the whistleblower:
In 2012 my brother and I built an encrypted messaging app for our personal use—we wanted to be able to securely pass on information to each other, in an environment where WhatsApp and other tools were easily monitored by the authorities. After Edward Snowden's revelations in 2013 we understood the problem was not unique to our situation and existed in other countries. So we released the encrypted messaging app for the general public (Durov, quoted in Healy 2015).

Despite its centralised nature, Telegram servers are located in five different countries around the world, with the aim of improving response times and better responding to national or regional jurisdictions (for example, the data of users who subscribe from inside Europe is stored only in the Netherlands). Due to the geographical distribution of its servers, Telegram's broadcasting function is used by censored media as a way to bypass the blockage, and by bloggers as an alternative to Facebook and traditional blogging platforms (for example, Alexey Navalny's popular bot on Telegram and the Grani.ru channel and bot, among others). However, unlike private communications on Telegram, public channels may be read and blocked by the Telegram technical team (e.g. as of January 2016, 660 channels attributed to ISIS were blocked).

Recent research in usability showed that Telegram was suffering from a number of important problems in this regard (Abu-Salma et al. 2017a); however, our research shows that this application is widely adopted by high-risk users, in Russia, Ukraine, but also in Iran, and reveals a number of 'alternative' practices and room for resistance within a service that has otherwise a number of centralised 'control points' (DeNardis 2014). In Russia, Telegram is widely used by Pirate Party activists (240 users as of 17 June 2017). Users from and living in Iran highlighted several aspects in favour of their choice of Telegram, not all of them directly connected with the privacy or security properties of the app. Users were especially happy with Telegram's functions such as stickers: Telegram makes it possible for users to generate their own stickers, which permits personalised uses of the app. For example, Iranian users explained, in our interviews with them, that adding stickers representing Muslims in their everyday environment, but also specific stickers on the Iranian political
situation, was a very important feature that differentiates Telegram from ‘first world’ apps that only focus on Western lifestyles and emoticons. Furthermore, during our web ethnography focused on usages of Telegram, we observed how Telegram stickers were used to attract attention to a specific cause, as an alternative way of spreading information and setting a trend. Thus, after the arrest of the Tor exit-node operator Dmitry Bogatov in Russia on 10 April 2017, a group of Russian Internet freedom activists (some of them members of Pirate Party Russia), who used Telegram group chat to coordinate the #freeBogatov campaign, generated a sticker pack dedicated to his case. Apart from stickers – that become at the same time tools for community-building and for personalising this messaging app – other elements of customisation are present in Telegram, such as the possibility to set any image as wallpaper/ background for the app, or to use a wide range of colour themes – functions that are absent in Signal.

Finally – as the quotations from the two ‘Resistance’ group chat participants in Chapter 1 also show – trust in Telegram, according to our interviews, goes beyond the technology to place a special emphasis on Pavel Durov as a ‘charismatic leader’ (Conger 1989) and on his political positioning. The cryptographic protocol and security and privacy properties lose their importance for users, compared to UI/UX features and the ‘aura’ surrounding the app’s creator.

## CONCLUSIONS: CENTRALISED ARCHITECTURES BETWEEN CONTROL AND DEPENDENCY

As we finish writing this chapter, in the summer of 2020, the controversy about phone numbers as means of identification and authentication in secure messaging platforms still unfolds. In late May 2020, Signal released ‘Signal PINs’, a feature meant to allow users to keep control of their account even if they lose their phone or are forced to switch numbers – a feature which, in the words of a Signal developer, is aimed at ‘facilitat(ing) new features like addressing that isn’t based exclusively on phone numbers’ (randall-signal 2020). Still, the debate about this implying the beginning of the end for phone-number-based identification rages on:
Signal isn't yet announcing a way to use its product without handing over a phone number at all (...) You still can't use the laptop versions of the app without setting Signal up on your phone first, and you can't set it up on your phone without handing over a real, live phone number right at the start of the installation. PINs aren't a replacement for phone numbers but they do provide a safer way to recover your account in an emergency than a phone number alone (...) It's a start, not least because it means an interfering government or mobile phone company can't lock you out of your account simply by cancelling your SIM card. But you still need a phone to get onto Signal in the first place (Ducklin 2020).

Whether Signal's latest developments indeed herald a post-number-as-ID era for secure messaging tools or not, the fact that this issue – linked with the problem of metadata collection and retention – keeps on being the Apple of Discord for secure messaging systems is revealing of broader controversies around the ‘dependencies’ of centralised systems upon other entities. Interestingly, these dependencies are discussed in ways that largely overlook the soundness (or lack of) of the cryptographic protocols. On one hand, they are about the ways in which the application’s interface, features and particular architectural design choices bind secure messaging tools to other applications and protocols that have, in turn, centralised and/or proprietary structures. On the other hand, they are about the economic and social ‘trade-offs’ that users must accept in order to use the system – handing over to a server-based service, as identifiers, pieces of information that they consider to be excessively sensitive or revealing, or knowing that a weakness of the system may actually come from the collection and retention of the ‘information about information’, metadata, that is more concentrated and exposed in centralised applications.

At the same time, centralised architectures make it easier for IM developers to experiment with, for example, particular forms of business models where some form of control or concentration of prerogatives must be retained. The choice of the Signal team to refrain from standardisation so as to maintain the capacity of updating the protocol rapidly enough as a response to the evolutions of the
field, and to provide as a service the expertise and specification necessary for a
proper deployment of the protocol, is an interesting case in point.

Centralisation may also mean faith in a charismatic developer, for better or
worse. Beyond Telegram's Pavel Durov – the centrality of Moxie Marlinspike's
figure and interventions in the secure messaging ecosystem is clear in the case
of Signal, as well – motivations for the adoption of privacy-enhancing tools are
also dependent on the reputation of their creators. In the users' mind, these
figures of core developers become a (sometimes very welcome) 'centralisation'
point, and their handling of shifting geopolitical alliances that may affect the
reach of government agencies and, as a consequence, the users' threat models,
is closely monitored and either fiercely supported or blamed.

The (hi)story of the Signal protocol is also interesting from the standpoint
of Internet history. Indeed, it is a story of protocols that mutually influence
each other, borrow from each other, and even try to revert to their predecessors
and renew them in the light of new norms and requirements brought forward
by Signal, such as forward secrecy – nowadays accepted as the necessary mini-
mum. The Signal protocol has deeply influenced the crypto protocol field by
introducing a combination of properties, such as forward and future secrecy
and non-repudiation, combined with a modern interface, that have become a
new minimum required for a secure messaging application. As the inventor of
the OMEMO protocol (see Chapter 4) explains,

> If you are designing a new protocol for end-to-end encryption now, or even
> two years ago, for instant messaging having forward secrecy in it is just a
> good practice. It's just what all the other IM encryption schemes are doing
> as well. Signal does it, WhatsApp does it.

Boosted by Signal's innovations, older protocols have been refurbished, and new
standards are now being discussed that aim at bringing some of these proper-
ties to a documented and stabilised form. Signal's impact goes beyond a 'linear'
leap from older to modern protocols. The turn to mass encryption has shaken
the secure messaging community, instigated protocol renewals and raised new
challenges, many of them still unsolved.
The story of Signal is also telling in terms of ‘informal’ Internet governance. It shows how, as encryption becomes much more of a public concern than it was a few years ago, several end-to-end encrypted messaging developers are becoming sceptical about traditional arenas of exchange and dialogue on potential standards (such as the IETF, XMPP Foundation, W3C or NIST), which they consider less effective (or more ‘compromised’) than a development-based approach. Does this mean that, as far as widespread adoption of encryption in secure messaging is concerned, we are looking at the ‘end’ of the standardisation era? Will governance of encrypted messaging happen by infrastructure and by code, by ‘something that works’? And if so, is a centralised service more likely to lead the way, due to its ‘control points’ – technical, financial and organisational – that can make control by design more straightforward for those willing to attempt it? The next two chapters, delving into more distributed arrangements for secure messaging applications – peer-to-peer and federated architectures – will keep on addressing this core question.

NOTES

<footnote n="1">1 This chapter partially draws upon Ermoshina, K., and F. Musiani, ‘Standardising by Running Code’: The Signal Protocol and De Facto Standardisation in End-to-End Encrypted Messaging, *Internet Histories: Digital Technology, Culture & Society*, 3.3–4 (2019): 343–63.</footnote>

<footnote n="2">2 As a reminder (see Chapter 1’s ‘Instant messaging encryption’ for more details), one of the applications built on top of the Signal Protocol is also called Signal and developed by the same team.</footnote>

<footnote n="3">3 This independent audit of the OMEMO protocol includes a part dedicated to the Signal protocol and refers to a lack of documentation: https://conversations.im/omemo/audit.pdf.</footnote>

<footnote n="4">4 https://signal.org/docs/specifications/xeddsa.</footnote>

<footnote n="5">5 https://fdroid.eutopia.cz.</footnote>

<footnote n="6">6 https://github.com/mimi89999/LibreSignal.</footnote>

<footnote n="7">7 Signal’s former and initial name.</footnote>

<footnote n="8">8 https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165.</footnote>

<footnote n="9">9 https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217231557.</footnote>

<footnote n="10">10 https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217231557 and follow-ups.</footnote>
11 The willingness of users to ‘stick’ with Wire was also the reason why its team implemented a (end-to-end encrypted) chatbot called ‘Otto’, intended to become users’ first contact, a way to get familiar with the app and test it – a way to, in Alan’s words, ‘show [users] the potential of Wire so that they feel comfortable inviting their friends’.

12 @Snowden on Twitter, 8 June 2017, 8:18 PM: ‘Wire seems like a reasonable alternative to Signal, it’s just less well-studied. Also lets you register with anon email instead of a phone #.’ The tweet is no longer available, although the conversation that followed still is.

13 https://ricochet.im, which stopped development at the end of 2016.

14 In 2017, the Wire team claimed that one-to-one voice calls made via its system no longer collect metadata (Wire, 2017b).
PEER-TO-PEER ENCRYPTION
AND DECENTRALISED
GOVERNANCE: A NOT-SO-
OBVIOUS PAIR

IF THERE IS SUCH A THING AS A CONTINUUM IN SECURE MESSAGING APPLI-
cations, based on their technical architectures, the services examined in Chapter
2 would most likely situate themselves towards one of its extremes, and those
addressed in this chapter would be located towards the other. Indeed, particular
populations of users of secure messaging systems, especially those living in high-
risk environments or involved in political activism, show an interest towards, and
sometimes even a hope in, peer-to-peer architectures, as they see a coherence
between their political and economic models, based on horizontal connections,
mutual help, self-governance and participation, and the technical architecture
of distributed networks. Peer-to-peer, as in previous instances in recent history,
also promises less control by both governments and private corporations.

However, as the Introduction to this book has hinted at, this larger apprecia-
tion of decentralisation as a principle and a vision may itself become problem-
atic; most notably, decentralisation may become an objective in and of itself.
Decentralised protocols and applications are too readily assumed, because of
their technical qualities, to bring about decentralised political, social and eco-
nomic outcomes – ‘architecture is politics, but should not be understood as a
substitute for politics’ (Agre 2003).

Peer-to-peer encrypted messaging faces a number of more specifically tech-
nical challenges as well. These include a ‘vicious circle’ between the adoption
barrier and dependency on the number of users; the difficulty of managing users’
reputations and identities, as identities are unique but users usually find them
hard to memorise due to the form they are presented in; and the mechanisms
that lead to trust being invested in the client, which presents a lot of advantages
censorship-wise, but may entail risks for users living in authoritarian regimes,
where the main threat model remains physical pressure and device seizure.

‘Furthermore, while the demand to redecentralise specific components
of the Internet has become ubiquitous (Schneider 2019: 266), and despite a
long history of tensions which we hinted at in the Introduction, the concept of
decentralisation remains uncertainly defined. ‘Despite increased research, there
remains a great deal of conceptual confusion. Researchers attach a startling
diversity of definitions and measures to the decentralisation concept’ (Schneider
2003: 32). Practitioners are not on the same page either when it comes to defin-
ing what decentralisation means, technically and socially, and which of the many
models to opt for when designing a messaging app.

This chapter explores the tensions between the potential and the challenges
of decentralised architectures as applied to encrypted messaging, by discuss-
ing, in particular, the case of the application Briar. In doing so, it also traces a
portrait of the particular populations of users that more frequently adopt these
technologies – usually knowledgeable about **mesh networks**, or with a previ-
ous history of using decentralised technologies.

THE ‘PROMISE’ OF PEER-TO-PEER ENCRYPTION

As we have previously discussed in Chapter 1, the discourse linking encryp-
tion to peer-to-peer (p2p) is frequently associated with the ‘promise’ of this
decentralised technology for the field of secure messaging. It is cited as such in a
number of group chats that we have observed, with a particular focus on Russia¹
and France. These users, whom we have earlier classified as high-knowledge or
tech-savvy/tech-enthusiasts,² regularly discuss the ‘re-decentralisation’ of the
Internet(s) (Rowe 2018). Two main aspects are underlined in these debates:
the potential of p2p as a circumvention tool in the context of growing surveil-
lance and censorship, and the particular kinds of metadata protection enabled
by the technical features of p2p. Further, the potential of p2p to offer a certain
level of technical autonomy useful in case of shutdowns, or in remote areas,³
as well as the technological 'elegance' of these solutions, are among the key
arguments in its favour.

In countries such as Russia, where Internet governance is increasingly state-centred, centralised and authoritarian after a relatively open and decentralised earlier phase (Nocetti 2015), Internet activists suggest not only federation (which will be more extensively addressed in the next chapter), but also p2p as a possibly appropriate technical answer that can potentially help users to 'slip between the cracks' of state filtering and surveillance. In terms of the kind of metadata treatment enabled by p2p, users believe that decentralised solutions will have less impact on privacy compared to Google or Amazon-based solutions, and that metadata can be better protected within distributed or **mixnet**-based systems. Other discussions on re-decentralisation concern infrastructure, at both the physical and protocol levels, for example, how could the Domain Name System (DNS) be re-decentralised. An important place in discussions on re-decentralisation is held by 'alternatives' such as ZeroTier One, a portable client application that provides connectivity to public or private virtual networks, founded by Adam Ierymenko in 2014.⁴

In France, as well, discussions about the need to move away from proprietary and closed-source centralised services are spreading across tech-enthusiast communities. A new trend is developing, which is labelled as a 'relocalisation' of hosting and service providers. With the motto 'host local', a project called CHATONS⁵ has been launched by the 'Degooglise Internet' collective, to map local independent hosting, email and XMPP providers. This collective suggests that instead of hosting data in a wide, centralised, remote and anonymous datacentre, it is more privacy-preserving to host it with someone you know personally. Trust relationships, and sometimes even 'IRL' encounters, give an additional layer of protection in addition to TLS and end-to-end encryption.

Mastodon,⁶ a federated⁷ version of Twitter, is gaining popularity in France (most of its instances are French). Diaspora, a decentralised social network, is also gathering important communities of French privacy enthusiasts, namely through an instance called Framasphere. As one of our interviewees from the French cryptoparty scene commented:
I feel like recently there's a riposte of European services to USA-based ones.
I don't really understand why we should give our data to giant datacenters
somewhere across the ocean. It's like eating our local food... You like French
cheese, French strawberries, why not French hosting? Or even better... you
can grow your own strawberries [laughs] or run an instance at your place
(A., informational security trainer, France).

In this context of the creation of decentralised and federated projects, p2p solu-
tions become part of a more global trend towards re-localisation, associated
with a more responsible and even ‘sustainable’ attitude vis-à-vis the Internet.
De-anonymisation of service providers paradoxically promises better anonymity
and online privacy, which goes hand in hand with new protocol designs, often
based on IRL contacts and key exchange. Several projects are moving towards a
redesign of the backbone and propose a more direct and local, sometimes off-the-
grid, device-to-device connection, in order to increase anonymity. Among the
promises of p2p, data and infrastructure ownership is one of the most frequently
discussed. Unlike centralised applications, which make users delegate part of
their data (and therefore, part of their ‘freedom’) to a server, proponents of p2p
submit that such a model guarantees more autonomy and privacy for users.

<figure><img src="image_16.png" /><figcaption>**FIG. 3.1** A vision of ‘safer Internet’. Drawing made by a feminist activist during a workshop in March 2017 in Saint-Petersburg</figcaption></figure>
The shift towards decentralisation is recursively described as a solution to ‘rescue’ the Internet, with distributed architectures being considered as possible alternatives to the predominantly centralised, corporate and state-controlled Internet. Interviewees described wishing to ‘turn to [the p2p] community to seek digital solutions that defend freedom’ and evaluated mesh and peer-to-peer technologies not only as ‘more secure’ but also as censorship-resistant: ‘community-run ‘mesh’ network … takes back control from corporations: everyone on the network can agree to keep all content open’.

Drawing on a long-term social and historical perspective on decentralised technologies, these statements can appear too technologically deterministic and blind to the big picture. However, what is most interesting about them from our standpoint, in order to account for the recent history of secure messaging development, is that such arguments are grounded in a perspective on decentralised architectures that sees them as intrinsically charged with a specific political and social vision: as Philip Agre has insightfully summarised, p2p is the epitome of a technical architecture that is seen as a ‘substitute for politics’ (Agre 2003). This chapter seeks to examine how this vision is entangled with the day-to-day technical challenges and opportunities posed by p2p technologies, and how developers and users attempt to embody the promise of such technologies in artefacts and procedures.

*Re-localisation, data ownership, and ‘utopias of resilience’*

A first facet of the p2p promise concerns the intrinsic technical interest that developers have in decentralised technologies, coupled with their recognition that these technologies are accompanied by a number of challenges unseen in other architectural configurations. Indeed, the overwhelming majority of developers of secure messaging and email applications that we have interviewed express a general interest in decentralisation, and almost all, in the span of the same sentence, underline the technical difficulties related to the implementation of p2p protocols. It is perhaps due to the awareness of these complications that no one calls for the total replacement of centralised architectures in favour of p2p, even though much optimism and sociopolitical
promise is invested in distributed architectures. Take the following comment from Sarah, a developer:

> They (centralisation and decentralisation) both have the place in the wild. You'll always have to have collaboration on something centralised, but I think that technology and people are safest when power is distributed, and the way to distributed power is to create decentralised means of communication. My philosophy lies in that. I still see a need for centralisation in few areas, but many of the properties of centralised systems can be created within decentralised systems (Sarah, Ricochet developer).

A second facet of the p2p promise lies in what we call ‘utopias of resilience’: a number of projects propose solutions for communities in rural areas, or areas at risk (such as war zones), where Internet connections are non-existent, weak or dangerous (for example, if fully controlled by the state). Thus, a Syrian interviewee describes⁸ his experience during the first months of the civil war in his country as follows: ‘We all became hackers, as we turned to radio waves, walky-talky, mesh and other technologies to coordinate our actions in the absence of network coverage.’

Consequently, countries or areas with frequent Internet shutdowns are also targeted by p2p projects (Vargas-Leon 2016). Among them is Scuttlebutt,⁹ invented by a sailor, and a project that proposes an ‘off-the-grid’ file-sharing, communication and blogging framework. As in Sarah’s account above, understandings of power redistribution are once again related to control of data:

> In a database system, all the power is in the database. It's often called a 'single source of truth.' Who can do what is ultimately controlled by who-ever administers the database. Here, we have no central database to decide for us what a given action means, instead when you make a post or a 'dig' or change your picture, the other peers (or rather, the software they run) interprets that. A social consensus.¹⁰
Traffic layer security, or metadata protection, is yet another feature that makes p2p a desirable alternative to models where the metadata collection and retention issue remains unsolved. However, all the developers working on decentralised projects agreed that peer-to-peer presents a number of important challenges usability-wise. They concur that a trade-off exists between the UI/UX features of centralised services that users have got used to, such as stickers, file sharing and calls, and the better level of anonymity offered by p2p-based applications:

> I feel like a whole bunch of people need it [anonymity]. It's really hard to recommend Ricochet over Signal [but w]here Ricochet is gaining it's because it's using Tor hidden services. Part of my goal is to make Ricochet more usable. Compared to Signal, Ricochet is more privacy-preserving because of no phone number. Ricochet is easy but it lacks a lot of features that other IMs have: like sending pictures and files, calls... Ricochet does not have that because this is hard to develop with respect to anonymity (Sarah, Ricochet developer).

Our interviews help shed light on another facet of the p2p promise that may be showing an evolution in the history of decentralised technologies. Traditionally, these architectures have been thought of as best serving the needs of very specific groups of users: on the one hand, activists and strong defenders of civil liberties, members of anti-authoritarian, left-wing movements with a very high-risk profile who seek strong levels of data and metadata protection – so-called ‘radical techies’ (Milan 2013) – and on the other hand, tech-savvy people interested in ‘playing with a new tool’, in the more ludic dimension of technology development and testing (Coleman 2011).

However, our interviews with secure messaging users living or working in zones at high risk¹¹ show that, with the exception of tech workers, these users do not adopt p2p messengers, as they have not been trained to do so. They prefer offline communication on most sensitive issues, or using centralised tools with a deletion timer (‘ephemeral messages’). Indeed, digital security trainers who advise Ukrainian or Crimean human rights organisations recommend centralised
apps, such as WhatsApp or Signal, as they are worried that p2p will be more
difficult to understand and adopt and will present otherwise avoidable technical
issues. After a risk assessment (an analysis of real threats and their probabilities
in the given context, see Chapter 1), they often conclude that the threat lies on
the client side, and the physical seizure or search of devices at borders is more
likely to happen than traffic interception. However, digital security trainers or
tech professionals like to ‘test’ new tools, including p2p tools, with their col-
leagues and friends.¹²

Based on our sample of user interviewees, heavily politicised users, primar-
ily belonging to left-wing movements, are indeed interested in p2p messaging
applications, as in their imaginaries of communication technologies a direct
connection is established between social and technical decentralisation (Agre
2003); however, actual levels of adoption are very weak, a recurring problem in
the history of decentralised technologies (Rowe 2018; see also Musiani 2015b).
This aspect of p2p was criticised by a number of our developer interviewees,
who share a belief in some of the positive aspects of distributed architectures
but underline a number of unsolved challenges:

People with [...] anti-authoritarian politics bend them [their politics] to a
decentralised model and they believe very strongly that all of the technology
must follow a decentralised model. And our critique was that... there's a
lot of technical problems with decentralised model (Elijah Sparrow, LEAP
developer).

BATTERIES AND BUSINESS MODELS: THE CHALLENGES OF
P2P ENCRYPTION

Among the problems or challenges of p2p, there is, first of all, a vicious circle of barriers to adoption and a dependency on a critical mass of users (also framed in the past as a ‘chicken and egg problem’; see Musiani 2015b and Musiani 2021). Indeed, the more people are using a p2p tool, the better quality of service it can offer; however, it is hard to motivate people to use a relatively unpopular messaging app, due to the poor quality of service in the bootstrapping period. Secondly,
projects that offer better levels of anonymity, such as mixnets (for example, POND), have latency issues. These two challenges are very well described by Roger Dingledine, Tor lead developer, in the interview we conducted with him:

> Part of the challenge was that... should we work on this low latency, low security system called Tor or should we work on this high latency, high security system called mixminion? We have a choice – which one is better for the world? And then we did more economic analysis and we realised mixminion will have approximately no users, so while in theory it must be safe, in practice it will not be more safe. So, the answer [to the initial question] was evident (Roger Dingledine, Tor lead developer).

Another problem of p2p tools is the difficulty of managing users' reputation and identity that is often presented as a 'long hash' (as in Ricochet, which uses Tor 'rendez-vous' points). In this context, identities are unique, but users usually find them hard to memorise. The form that identifiers take in a messaging system is most often the result of a trade-off between different properties, as explained by Elijah Sparrow from LEAP:

> (In p2p environments) user IDs are long strings that are hard to remember... There's something that is called Zooko's triangle. For any identity system you get to pick two of the following three choices: you can have something where the names are globally unique, you can have something where the names are globally memorable, and you can have something where the naming system is decentralised. The problem is that everyone wants to get all three, but you have to pick two (Elijah Sparrow, LEAP developer).

These identity management problems result in reputation management issues. This makes it highly problematic for users of p2p environments to be able to authenticate whom they are communicating with – which developers identify as a core issue of today's Internet due to the numerous problematic and potentially damaging practices it hosts (Badouard 2017):
Certain usability properties of identities are very difficult to do in a peer-to-
peer decentralised model. And a decentralised model also has issues with
Sybil attacks, the question of how you control access, how you establish
reputation when there is no barrier to entry. There's essentially no good
way for a p2p model to have reputation, which is a very big problem in any
online communication setting because there is so much trolling (Elijah
Sparrow, LEAP developer).

Another challenge of p2p concerns the trust that is placed on the client side. For example, Beaker Browser¹³ promises to turn users’ browsing experience ‘inside out’ by hosting websites on users’ clients and using a specific protocol for file sharing. The URLs generated with this process are said to be ‘unguessable’ and are never sent over the network, the URL itself therefore being a public key helping to decrypt files. While this model presents a lot of advantages for efforts to circumvent censorship, as it makes it almost impossible to block or delete any of the Beaker websites or files, it may present risks for users living in authoritarian regimes where the main threat model remains physical pressure and device seizure (see Chapter 1). Secondly, the p2p architecture requires the user’s device, by design, to be constantly online (as every device is also a ‘server’), which has significant consequences for battery consumption:

[The] peer to peer promise [says that you] have to trust your device all the
time and you have to deal with identities with these long hashes and you
have to deal with burning of your battery, memory and mobile device (Elijah
Sparrow, LEAP developer).

Improving this aspect is one of the core ongoing tasks for p2p projects, whose
developers are being creative in exploring alternatives to this major design
constraint, such as whether the client can remain connected to an anonymity
network without constantly exchanging data.

A related feature concerns the possibility of planning regular account backups. In distributed applications, it is difficult, by design, to use any kind of cloud platform or other automated or regular backup solution. This feature
can be a positive in high-risk situations (deleting an account from a client deletes it ‘forever’, as no servers are involved). However, it may be a complication for users who prefer to rely on cloud-based solutions or need to keep archives of their communications. Michael Rogers, the lead developer of Briar,¹⁴ which we will be examining extensively later in the chapter, notes in this regard:

> Briar is in a worse situation than some tools, by the moment your own account is stored on your device. If you destroy the device or uninstall Briar, you lose all your contacts and messages (Michael Rogers, Briar lead developer).

To summarise, in the view of the developers we interviewed who are either working on p2p-based tools or considering whether to do so, adoption of p2p systems in the field of secure messaging seems to be limited because of their insufficient usability levels, restricted multimedia sharing capacities, memory and battery concerns. This makes p2p applications harder to adopt in areas where people use older and less powerful phones with lower quality components, smaller memory and shorter battery life. There is therefore the potential for this architecture to contribute to the digital divide (Howard 2007). Developers underline users’ ‘dependency’ on UI/UX features, such as stickers, and agree fact that peer-to-peer solutions cannot compare to centralised applications in terms of usability.

A related question is why p2p solutions are lagging behind centralised applications, when the search for suitable and sustainable business models has been a long-standing issue for decentralised architectures-based applications (see Musiani and Méadel 2015). An immediate answer is that p2p systems have no central intermediary entity that could track – and monetise – social interactions in order to fund the development of applications. Peer-to-peer architectures traditionally attract sizable attention within academia, with a growing number of conceptually complex and promising projects; however, there remains the problem of the ‘knowledge gap’:
> [There is an] enormous conceptual gap between what the designers of an encryption tool think that everybody knows and needs to know in order to make a system work, and on the other hand what a user actually tries to achieve through the use of it (Michael Rogers, Briar lead developer).

In this sense, while usability seems to be less of a burden for centralised systems, users have not yet formed proper ‘mental models’ to embrace distributed secure communication:

> With a certain technical structure that is more centralised, it is definitely achievable [...] But now the question is: can we also bring decentralisation into that picture without breaking all of those mental models that users have and without asking them to learn a lot and make a lot of theoretical effort before they can use that tool. [...] What we’re trying to achieve is a balance between asking a user to understand how the system works, which is obviously a burden, or having a system do surprising things because it works differently from what they expect (Michael Rogers, Briar lead developer).

Despite extended critiques by tech and trainer communities, peer-to-peer encrypted messaging apps are developing and some of them are gaining users, funding and media attention. The second part of this chapter turns to analyse the case of Briar, a peer-to-peer, end-to-end encrypted, instant messaging app using Tor hidden services.

## BRIAR: RETHINKING ANONYMISATION AND RESILIENCE

Briar is born out of a problem that is activist and academic at once: how to increase anonymity and move communications off the backbone, in the context of Internet shutdowns (Vargas-Leon 2016) and increased governmental control over the network in a number of countries around the world:

> I was working on p2p communication networks for my PhD and I reached a point where I realized that being able to observe the Internet backbone gives
you the ability to observe all of the endpoints and their interconnections;
this shapes the possibilities for having private communications over the
Internet [...] if you can see the end points, you cannot get the anonymity
(Michael Rogers, Briar lead developer).

In the late 2010s, the lead developer of Briar, Michael Rogers, was contributing to LimeWire, a peer-to-peer file sharing service. In 2009, LimeWire developers were contacted by Iranian journalists from the Green Movement. Activists were wondering if LimeWire would be suitable for use as a communication tool in Iran:

> The guy who contacted us worked for BBC Persian service. He had a principal interest [in] getting news from BBC into Iran, but the question was essentially: what can we do to support a movement like this? One part is getting news from the outside world, another part is disseminating news to the outside world, and the third way is internal communication. And those are all things that we kept going as strands within Briar, how do we look at those different use cases (Michael Rogers, Briar lead developer).

At that time, LimeWire was not suitable and secure for high-risk communication; however, Michael suggested building another system with a greater focus on security features. Together with activists, he sketched the rough idea of a network built over social connections, relying as much as possible on local network connections. This technical solution was relevant to the local political context: international connections in Iran were heavily monitored and filtered. In this context, Michael and his team opted for an off-backbone communication: this collective effort took shape, eventually, as Briar. At the time of our fieldwork (late 2017), the team counted four members, with two developers, a UX/UI designer and a security/usability researcher who was also responsible for communications and outreach for the project.

As with most software development projects, its name sheds light on its history and on the *zeitgeist* of its developers. ‘Briar’ is an organic metaphor: it
is a distributed, rhizomatic and ramified structure, which, despite its seemingly
hostile appearance, can create a protective environment:

Briar, as far as I understand, means a thorny plant, and there's a fairy tale
about a little rabbit thrown into a briar patch who knows how to avoid it,
because for him it's not dangerous, he was born and raised there. So it gives
this idea for agility and resilience to escape dangers. And I like the little story
behind it (Thorsten, Briar developer).

Indeed, it's an American folk story: it's about a fox that catches a rabbit
and says: I am going to tear you into pieces. And the rabbit starts crying:
Oh, please, do everything you want to me but please don't throw me into
the briar patch! So the fox eventually throws the rabbit into the briar patch,
the rabbit runs away in the briar laughing: 'I was born and bred in the briar
patch, you know?' [...] In order to communicate privately we have to move
away from these centralised services and rely on our social networks, and we
have to fall back on these much more difficult structures to communicate
(Michael Rogers, Briar lead developer).

The Briar Patch is also a specific region of space featured in Star Trek. According
to the plot of the 1998 film Star Trek Insurrection, the Briar Patch emanates
a specific 'metaphasic radiation' that is concentrated in the planet's rings,
continually rejuvenating their genetic structure – it is a region of space that
star-ships usually avoid because of various radiation sources and energy fluc-
tuations that impair communications systems and make it difficult for vessels
inside the nebula to make contact with those outside it. This description bears
a close resemblance to Briar's architecture and technical features, these being
designed for situations where communication with the 'outside' Internet is hard
to maintain. Briar focuses on a specific context of state-driven blocking and
filtering measures (Bendrath and Mueller 2011; Mueller, Kuehn and Santoso
2012), as well as extreme situations such as a significant Internet blackout or
shutdown (Vargas-Leon 2016). Connections in Briar are made over Bluetooth,
Wi-Fi and Tor. In this sense, Briar is designed both as a circumvention and an
anti-surveillance tool:
What we had in mind specifically was how to get information in and out
of the country in times of unrest when it might be blockaded, and it might
be particularly difficult to reach Facebook [and other international sites].
One of the problems is how do you tunnel information outside or within
the country and then let it spread widely outside the narrow tunnel. And
that remains a question that people in Briar think of. People need to use
it in conjunction with other tools and especially when they need to reach
people who are not part of a movement or whatever social group it is, and
who are not using Briar. We need to think about bridges. So we have an
import feature to import a blog from a web (Michael Rogers, Briar lead
developer).

Briar sees its users as people who are aware of their own need for security and
mindful of surveillance-related threats. Briar's threat model sees governments
as the main threatening group of actors and attackers, performing filtering
and interferences as well as blackouts – not only reading and intercepting
communications and metadata. Briar is also intended to be a solution for
crisis mapping and disaster response, and as such is aiming to collaborate
with humanitarian organisations. Briar's UX/UI and usability concerns are
informed by the experience of lead developer Michael Rogers, who previ-
ously worked as an informational security trainer for journalists and, in his
words, had witnessed in this role the conceptual gap between the expecta-
tions of encryption tools' designers in terms of users know and need to know
in order to make a system work, and actual user expectations concerning
the tool (see also Abu-Salma et al. 2017a and Dechand et al. 2019). In this
sense, one of Briar's concerns is to make a usable peer-to-peer tool for secure
communication.

*From the protocol to the application: A framework for a decentralised
alternative*

The Briar project consists of two parts: the underlying protocol, called Bramble,
and the actual user-facing application, called Briar.
I would say Bramble is a framework, or a library that gives you these peer-to-peer connections with people, without any intermediaries, and it gives you also the notion of groups and of contacts that can interact. And on top of this you can build different applications, and Briar is just one of them, it's a showcase of what the technology can do (Thorsten, Briar developer).

Recently, Briar has been shifting its efforts from the user-facing application to the codebase and infrastructure, and is expecting to guarantee the sustainability of the project without dependency on users – or, to be more precise, in shifting from end-users to ‘re-users’, power-users or lead users (von Hippel 1986) with above-average technical and computing skills who can adapt the protocol to their needs and develop other projects on top of it. The sustainability of Briar is supposed to be guaranteed by separating the protocol from the application, the reason being that, while maintaining pieces of infrastructure is easier in the open-source world as there are several positive precedents (Powell 2012), proper maintenance is more difficult for a user-facing application:

> That's partly why we want to make this separation because the user-facing app will probably have to be maintained with crowdfunding from users, or hopefully it can be maintained on a volunteer basis because most of the difficult technical plumbing will be moved into the infrastructure project, where the users don't have to maintain it (Michael Rogers, Briar lead developer).

The Bramble protocol is not yet standardised, and won't be in the near future, because developers see standardisation as the last step in the chain of releases, after the beta-version of Briar application is properly tested, and the final release is published: 'If you standardise it, you need to know that it's the best way to do it', as Thorsten puts it (see Chapter 2). However, the Bramble protocol can follow Signal's route of 'de facto standardisation', if it is adopted by a sufficient number of other projects. In this way, as with Signal, while the protocol itself is open source, expertise may be needed to implement it. Providing this expertise as a service is now considered a way of providing the project with a certain degree of financial sustainability, which would make the sociotechnical goal of
promoting resilient and distributed networks easier to achieve. Indeed, Briar's
lead developer sees in this initiative of charging for expertise an embryo of a
possible business model for Briar, that echoes Signal's 'non-standardisation as
a business model' (see Chapter 2 and Ermoshina and Musiani 2019):

The idea is that people can build other kinds of resilient networks on top
of the same protocol stack and hopefully we can make a sort of consulting
business for people who need to communicate with devices out in the field
or to communicate within teams that deploy in remote areas, that can be
interested to use this kind of networking technology (Michael Rogers, Briar
lead developer).

Therefore, the Bramble protocol aims to prepare a framework in order to build
distributed alternatives to existing centralised services. In the words of Thorsten,
'I would like as many of the services that people currently use to be transformed
to this peer-to-peer model when we don't need anybody in the middle anymore'.

*Working at the margins: Threats to metadata and Internet shutdowns*

Briar's main 'killer feature', as described by its developers, is intended to be
the close attention it pays to metadata protection. As developer Thorsten puts
it, Briar 'solves interesting problems that are not solved by other tools on the
market, for example, it enables people to chat without needing any servers and
without leaking any metadata. An interesting consequence of this, and of the
fact that Briar uses Tor hidden services even for feedback submission and crash
reports, is that the Briar team itself does not have any precise data about the
number of users, or exact usage statistics:

All the data only exists on the users' devices. There's no Briar server that
can store anything. If two people use Briar in a village in Chad in Africa, we
don't know about it, there is no connection made between them and any of
the computers we control. The only connection ever made to other people,
they add themselves. And we will never know these people even use Briar.
We don't store anything, because it's from person to person (Thorsten, Briar developer).

As mentioned, Briar uses Tor as a 'very well-designed backbone that's designed to know as little as possible on what we do'; however, the team is currently reflecting upon Tor's limitations and security flaws – a concern that mirrors a broader preoccupation in privacy research (Manils et al. 2010). Briar has been conceived to be deployable on any kind of infrastructure; it is not, by design, attached to Tor and could be migrated to a different kind of distributed backbone:

> I think Tor is starting to show its age. Some of the attacks we heard about as theoretical actually went very practical, and we need to think about anonymity infrastructure, privacy infrastructure that is not operated by someone in your house or on your street (Michael Rogers, Briar lead developer).

The Tor vulnerability mentioned by Rogers concerns the exit nodes and is related to the connection point between the onion network and the 'normal' Internet. The traces left by the exit nodes can provoke serious problems for the node administrators – a fact well-known to Dmitry Bogatov, arrested on 10 April 2017 because his exit node was used to post messages judged by a Russian court to be 'extremist' (Hatmaker 2017). The critique of Tor vulnerabilities has led the Briar team to imagine a separate, resilient network, independent from the Internet infrastructure: in the words of Rogers, 'I was looking for something that would work in a sort of partially disconnected environment'.

Briar's particular inspiration comes from the Internet precursor Usenet, when the historical network was running on dial-up connections and supporting early publish-subscribe systems on top of a patchwork of different technologies, before the era of IP addresses (Paloque-Bergès 2017). Some of these ideas had already been developed within the now-dormant Pond project – itself a delay-tolerant, mixnet-inspired messaging system that introduces noise and latency to increase privacy and hide metadata.¹⁵

One of Briar's central use-cases, which was tested in the field in Brazil with local bottom-up activist communities, is the case of Internet shutdowns. In these
scenarios, Briar is meant to still operate using either Bluetooth or any other
network that is not connected to the global Internet. Briar received attention
from Brazilian activists because of the recent Internet shutdowns and mobile
network jamming used by the police during rallies (Internet Without Borders
2018). Briar is also thinking of deploying it in Cuba, where it is common for
networks to be disconnected from the global Internet. By not relying on servers,
Briar need not be dependent on the Internet as a backbone, and can potentially
be run on any kind of autonomous community network:

When I tried to send you a message on Signal before it did not work because
the Internet was down, and the message needed to first go to the Signal
servers and then from the Signal server it came back to you. With Briar we
make a direct connection in here, in this network. We are all in this network,
we have IP addresses and Briar uses these IP addresses to connect to you.
It can also use Bluetooth, or other technologies. For example, we have a
mechanism when you can use USB sticks, USB hard drives or SD cards. You
plug this in your computer, you say for whom it is, who is the contact and it
will synchronize or this contact (Thorsten, Briar developer).

For the Briar developers, their interest in not running exclusively on Tor hidden
services (which is the case, for example, for Ricochet<sup>16</sup>), is that then Tor becomes
one of several possible ways of transporting the data. So, if in some countries
Tor is temporarily blocked (as has happened, for example, in China; Winter and
Lindskog 2012) users have alternatives, including some that may be developed
in the future.

## Group chat: A ‘social-based paradigm’

Briar's group chat architecture and key discovery processes draw heavily from
the observation of social interactions among social movements and grassroots
communities. The Briar protocol is, in some way, a 'modelization of social
phenomena such as friendship links, affinity-based community formation, attri-
bution of trust' (Musiani 2010: 193), something that has been a longstanding
concern of many innovators tackling the development of ‘next-generation’ P2P
applications since the mid-2000s. This ‘social-based paradigm’ (Pouwelse et al.
2006) works towards achieving trust by relying on both the technical features
of the protocol and the social aspects of the ‘human’ community itself.

Briar’s identity management and key discovery are linked to the structures
of social movements and to offline communication structures. In this sense,
Briar seeks to redistribute the trust relationship between human and non-
human agents:

Social networks are the foundation of all-powerful social movements, so by
emphasizing it we bring the attention back to the fact that all the security
relies on the people that you can trust, by bringing those trust relationships
to the fore... This very difficult constraint can turn into a strength. And I feel
again that we are in the position of the rabbit, we're thrown in a supposedly
hostile environment that actually is the place where we were born and bred
(Michael Rogers, Briar lead developer).

Many interactions are happening offline and face-to-face. The key discovery and contact exchange, for instance, is happening **out of band**. Key discovery in Briar happens in two different ways: directly, by QR-code scanning, and indirectly, on the suggestion or invitation of another user. The first configuration postulates the co-presence of the two users in the same physical space; this use context is considered as the most secure and the 'trust level' shown by the application is 'green'. The second case supposes that two users have one contact in common; the trust level is set to 'yellow'. Yellow can later be transformed into green when the two users meet and verify fingerprints by scanning QR-codes out of band. The 'red' trust level designates participants in a group chat with whom no key exchange has been established. However, Briar also tries to minimise users' interaction with keys and make it as smooth as possible:¹⁷

All is end-to-end encrypted by the keys that are automatically created when
you add your contacts. You need to be face-to-face to add each other. And
when you do, you can be sure that no one is in the middle messing up with
your keys. And you don't see your keys, never. It's encrypted but encryption
is invisible to you (Thorsten, Briar developer).

By choosing out-of-band key discovery, Briar tries to solve the **Man-In-The-
Middle** problem. However, the QR-code model showed its limits – for very
material and physical reasons – in the real-life crash test that we, the authors,
performed in August 2017, during a rally on Dvortsovaya square in Saint-
Petersburg. A group of 12 activists had installed the Briar application before the
rally. We met on the square and had to physically scan QR-codes in order to be
able to add each other in the contact list, create a group chat and start the testing.
However, the scanning of QR-codes turned out to be hard due to the sunlight.
Some users had to hide under their coats in order to scan their codes, and this
attracted unnecessary attention from the police and other participants. Other
users had their phone screens broken (a very frequent case among left-wing
activists), and this has also made the process harder and slower. Moreover, this
dependence on offline face-to-face contacts, emphasising the local and the prox-
imity dimensions of the p2p application, made Briar hard to use for coordinating
an international movement, or even country-wide one. When we issued a call
for Briar user testing in Russia using our contacts in different tech and activist
communities across the country, several dozens of people were interested in
testing it, but they could not ‘add’ each other and create a common group chat.
Vast distances and decentralised communities with one or two people per city
made it harder for the out-of-band system to work.

The latest release of Briar, however, implements a solution to the problem of adding contacts remotely, by making it possible to share a special ‘Briar link’ (Figure 3.2).

Briar's group chat model is, by far, one of the most interesting across the end-to-end encrypted messengers that we have examined. Briar's group chat structure takes the shape of a star: everyone is connected only via the creator of the group. This offers some degree of metadata protection to the Briar group chat participants. However, once again, the development of this feature was the result of complicated trade-offs:
<figure><img src="image_17.png" /><figcaption>FIG. 3.2 Adding a remote contact on Briar (source: https://briarproject.org/manual).</figcaption></figure>

Doing the group chat was a surprisingly challenging task. We had to make some compromises there. For example, it was a difficult decision – who can add new people to the group? If you allow everybody to pull new people in it, it's a mess and you have a question who can kick them out again. So to simplify things we decided that only the creator of the group is able to add new people. So if you are in a group and you're not a creator and you want your friend to be part of the group, you would ask the creator please invite my friend – it's a social way of doing it (Thorsten, Briar developer).

Human trust is an important aspect that minimises some of the risks related to 'social centralisation' in Briar's group chat architecture:

In a way, there is a certain centralisation aspect again [in the group chat model]. The creator has more control on the group than other people have. But you are not forced in the group, you are invited and you can join when you trust the creator sufficiently to handle this group, not invite bad people into it, and secure their phone properly (Thorsten, Briar developer).
It is the fact that Briar puts metadata protection at the heart of the protocol that led them to develop this unique group chat model. However, a protocol feature has been implemented in Briar that makes it possible to redistribute the power and remove part of the technical and social responsibility from the group creator:

> Because there's no server that distributes messages to everybody, participants need to exchange messages with themselves. So, if there is a creator, she needs to have connections with all the members of the group for the messages to travel, as she distributes the messages. But the implemented mechanism makes it easier because what if the creator loses the phone or is offline? The whole communication stops. So we came up with a solution that allows people to reveal their contact relationships to the group: if we are in the group and Ivan is also in the group and you want to be able to keep the communication running when I, the creator, am not here, you can decide to reveal the fact that you are friends with Ivan to the whole group, and exchange messages with Ivan directly (Thorsten, Briar developer).

However, while this feature continues to be effective in Briar's beta for Android, our observations of user testing in Russia, as well as discussions with testers from around the world, have shown that users do not have a clear understanding of the 'contact reveal' feature. Users tend to think that this involves sharing their social graph and consider this function as insecure and dangerous for them and their community. However, Briar's threat model does not intend that anybody should know who the contacts of a particular user are, and this is why the user needs to opt-in to reveal her contacts so that she can communicate without the creator. The Briar team is using real-life use-cases to explain this feature to their testers:

> Everyone is connected to each other through the creator. But when you reveal the contact it does not mean that you receive a notice saying you are friends with Ivan, it just means that you can exchange group messages also directly with Ivan without the creator being connected. It can happen
that people need to make more connections to each other so that they can exchange messages more fluidly: if you are in a bigger group at a protest and you send ‘the police is coming, you need to run away’, this message will not arrive to all the members if only the creator is distributing messages (Thorsten, Briar developer).

## Enrolling users: Community-building on top of research

A number of theoretical problems have been revealed during the work on the beta version of Briar’s group chat, for example ‘gossiping’, i.e. making sure that data are disseminated to all members of a group after a user has left it (the nature of peer-to-peer makes it hard to let all users know about it at once, and this may confuse users). The Briar team is looking at both academic work and other projects for solutions but has concluded that existing efforts do not solve these problems. A possible solution may lie in the collaboration between Briar and other anonymity-centred projects, such as Panoramix, Loopix or Pond. At present, Briar does not collaborate closely with any project, but it is following the overall ‘galaxy’ of encrypted messaging applications, even centralised ones, to keep track of the UI/UX features that users want to have. Briar wants to learn from these popular messaging apps and propose a smoother way for users to ‘migrate’ from centralised messengers to Briar:

> We usually look at Signal, WhatsApp and Telegram, simply because in this space these are the biggest three apps that fit… With Signal, since the source code is open, we look at it and use some of it, for emoijs for example. If we want to solve some UI problem, we do look at how other projects do it. Because if we have our own way, it may be confusing for people because they are already used to other ways. [We want] for the users to have it easier switching from other apps to our app (Thorsten, Briar developer).

However, Briar has a very different approach to the protocol governance and centralisation/decentralisation debate. Briar is actively distributing its Android
Package, which allows the distribution and installation of their application, via F-Droid; however, they cannot at this stage give users absolute freedom to modify the protocol, for interoperability reasons. Thorsten explicitly states that Briar has a different philosophy to Signal, inasmuch as Briar does not attempt to centralise the protocol and distributions of its apps: 'They [Signal] are very strict in having control over it [the protocol and distributions] while we encourage other implementations'. (Thorsten, Briar developer)

The Briar project is now experiencing a transition phase as the team is choos-
ing which path to take in the near future; during this transition phase, primary
concerns include the aforementioned separation of the Bramble protocol from
the Briar app, and the search for alternatives to Tor as a backbone.

An important issue to underline is that Briar has become available to users
only very recently; until spring 2018, test builds were available for Android
devices on request, and the Briar team was organising usability workshops
to test different features of the tool.18 Thus, the ‘chicken and egg’ problem of
getting a critical mass of users interested and motivated has not yet had to be
fully confronted. However, the decentralised tool project, though unused by
the general public thus far, has been tested in ‘field’ conditions in remote rural
areas, where participants could communicate successfully in the Briar mesh
at a limited distance. Furthermore, even though Briar does not yet have an
actual user base, it is an interesting example of a project that is driven at the
same time by research interests (usable p2p encrypted instant messaging in
the context of resilient communications and blackouts) and by activist- and
community-based motivations (the team members are frequent participants
of Circumvention Tech, now Internet Freedom Festival, and are collaborating
with the Guardian project, GNUNet, Unlike Us and Open Internet Tools). This
community-building dimension with relevant actors is understood by the Briar
developers as a dynamic that will structure developments in the near future, as
an important motivation for developers:

The sense of community is really important to have everybody motivated to
work on these projects that are very open-ended, and somehow against the
flow that society in general is taking... where there is less and less privacy
and more and more social control. It's nice to be reminded to know that
other people are going in the same direction (Michael Rogers, Briar lead
developer).

Ultimately, Briar is a sociotechnical experiment (alongside other projects from the galaxy of p2p encryption tools, such as the MIT-based Vuvuzela) and as such, illustrates important questions about the limitations and problems of p2p-based secure messaging, while at the same time showing its potential.

CONCLUSIONS: THE DIFFICULT DAY-TO-DAY PRACTICE OF THE ‘PROMISE OF INTERNET EQUALITY’

In the galaxy of end-to-end encrypted messaging tools, decentralised ones
appear to be subject to the highest degree of experimentation. If we consider
this in a historical perspective, we see that the nexus between p2p and secure
messaging today is an important manifestation of a longstanding and complex
tension related to decentralised technologies – between their alluring promise
of interoperability, horizontality, mutual help, self-governance, participation,
reduced control by governments and the private sector, and, on the other
hand, the multiple technical and economic challenges standing in the way of
its widespread implementation, including the ‘chicken and egg’ problem of user
motivation vs technical dependency on the number of users, and the difficulty
of how to manage users’ reputation and identity.

As the ‘promise of Internet equality’ (Agre 2003) of p2p technologies
remains strong, particularly in specific activist and academic settings, seeking
solutions to the different challenges posed by decentralised architectures to
encrypted messaging is at the heart of a substantial portion of current privacy
and anonymity research. However, there seems to be a gap between academic
research fields and activist needs and questions:

It's one of the greatest unsolved mysteries [...] The computer science
problems that activists care about are not necessarily close to the computer
science problems that are prestigious to work on in computer science. For
me, as an activist working on usable communication this is a great unsolved problem (Elijah Sparrow, LEAP).

Some projects, such as LEAP, Delta Chat (see Chapter 4) and Briar are trying to work in between the two; the NEXTLEAP project, via the work of the authors and other members of the consortium, has operated in the same direction, with our focus on activist use-cases (both high- and low-risk) and collaboration with open-source developer communities (Autocrypt).

We have selected the Briar case among decentralised secure messaging projects as we believe it demonstrates well the new potential of peer-to-peer encrypted messaging applications, as well as the challenges presented by p2p. However, in a broader context where net neutrality is put under increasing strain, and Internet censorship around the world is growing and becoming more pervasive, it is important to acknowledge that some of Briar's technical and social solutions can be reused, and possibly improved upon, by other projects. Alongside Briar, several projects sharing its foundational interest in decentralised architectures show a trend towards reinventing the Internet backbone itself, and migrating to other networks – seeking a freer, more decentralised Internet that would be less controlled by both governments and private corporations. New projects develop and define themselves as real 'ecosystems' suitable for any kind of data exchange, such as Matrix.org (see Chapter 4), CJDNS,¹⁹ i2p²⁰ and Yggrasil,²¹ decentralised and encrypted network protocols that have a growing user base in countries like Russia, as a response to the country's current trend towards more centralised control over the Internet.

As the secure messaging field grapples with the issue of delegating too much trust to the creators of centralised IMs (an illustration of this has been the Pavel Durov vs Moxie Marlinspike case, described in Chapter 2) or to the infrastructures they manage, p2p messaging applications seek to somehow *re-distribute* the trust between humans and protocols. However, our research on this type of secure messaging systems has shown that many users are still very much bound to centralised architectures, except for specific technical communities or openly anti-authoritarian activists.
NOTES

1 E.g., Telegram chats of Pirate Party Russia, Cybersecurity chat, internal Rubblacklist chat

2 And questioned/challenged this label in Chapter 1.

3 See projects such as Secure Scuttlebutt: https://scuttlebutt.nz.

4 https://zerotier.com.

5 https://chatons.org.

6 https://joinmastodon.org.

7 See Chapter 4.

8 Discussion at the Citizen Lab Summer Institute, session on armed conflicts and information control, July 2017.

9 See above: https://www.scuttlebutt.nz, a 'decentr(alised) secure gossip platform'.

10 https://github.com/ssbc/handbook.scuttlebutt.nz/blob/master/principles/legacy.md.

11 E.g., in the frame of a 'corollary' project of NEXTLEAP, in January 2018 we interviewed 28 Ukrainian and Crimean journalists, tech workers and activists.

12 See, e.g., the 2017 wave of interest in Tox messenger among the tech community in Kyiv, Ukraine.

13 https://beakerbrowser.com.

14 https://briarproject.org.

15 https://youbroketheinternet.org/secure-email#pond.

16 https://ricochet.im.

17 We will discuss in the final chapter how this and other similar strategies fall into a tendency which we define as the 'opportunistic turn' in encryption.

18 The authors participated in a usability workshop for Briar at University College London in February 2017. Eleven people took part in the workshop, all of them being UCL PhD or postdoctoral students in computer science or usability. We tested several functionalities, such as **key exchange**, invitations for a one-to-one chat, group chat creation, blacklisting and changing the 'trust level' of contacts.

19 https://github.com/cjdelisle/cjdns.

20 https://geti2p.net/en.

21 https://yggdrasil-network.github.io.
FEDERATION: TREADING THE
LINE BETWEEN TECHNICAL
COMPROMISE AND
IDEOLOGICAL CHOICE

WITH THE GROWING POPULARITY OF THE SO-CALLED ‘FEDIVERSE’, MAINLY known by its main projects, Mastodon¹ and Pleroma,² the introduction of OTRv4 and the vibrant scene of ‘chat-over-email’ projects, federated architectures are currently experiencing a phase of increased development and use. They are presented as alternatives, on the one hand, to centralised applications that introduce a ‘single point of failure’ in the network and lack interoperability, and on the other hand, to the p2p apps that necessitate higher levels of engagement, expertise and responsibility from the user (and her device). Federation is sometimes described as an ambitious technopolitical project; federated architectures open up the ‘core-set’ of protocol designers and involve a new kind of actor, the system administrator, responsible for maintaining the cluster of servers necessary for federated networks. Federation is believed to help alleviate the very high degree of personal responsibility held by a centralised service provider, while at the same time distributing this responsibility and the ‘means of computing’³ – the material and logistical resources needed by the system – with different possible degrees of engagement, favouring the freedom of users to choose between different solutions and servers.

As the previous chapter has also shown, the community of developers involved in the field of secure messaging is conducting lively debates about the limits and potentials of decentralised protocols – debates which we have retraced online. The discussions of the tensions between centralisation and
more distributed architectural forms, such as federation, go hand-in-hand with
debates over standards. Supporters of federated solutions claim that reusing
existing standardised protocols or developing new open standards can enhance
interoperability and solve the problem of ‘messaging silos’ (Kent 2019). Indeed,
federated architectures appear to be well-suited to promoting localism and
community-oriented smaller solutions, whose business model does not depend
on the sheer numbers of users and the availability of their data for harvesting
and aggregation. On the other hand, according to advocates of centralised
solutions, federation can present problems in terms of security, as it is harder
to audit all the different implementations of a federated protocol and ensure
that all servers are well configured.⁴ Indeed, federated messaging solutions add
a layer of complexity to the governance of the sociotechnical networks they
structure, as they introduce the need for the decentralised administration of
servers (or ‘instances’).

This chapter retraces debates about federation in encrypted messaging
and analyses the shaping of federation as both an infrastructural and a social
experiment, one that seeks a compromise between the distribution of respon-
sibilities onto a larger number of actors, high levels of security, and better
usability. We discuss federation as a political as well as a technical project
that recognises the dangers inherent to centralised solutions but suggests a
middle ground between centralisation and full-fledged distribution as in the
case of peer-to-peer tools, the latter considered as requiring a steeper learning
curve. In the chapter, we will analyse two approaches to federation. Firstly, we
examine projects that develop new protocols, such as OMEMO and Matrix.
org. Then, we analyse the ‘ecological’ approach to protocol development,
which consists of **upcycling** older protocols and existing open standards,
with the example of ‘Chat-over-email’ projects such as Delta Chat. The chap-
ter shows how community-managed infrastructures and practices of ‘social
encryption’ are used to enhance security beyond encryption protocols. We
also analyse federation as a way to make messaging apps resilient to censor-
ship, a factor that plays a more and more important role for users living in
repressive contexts.
DECENTRALISING TO WHAT EXTENT?

THE ‘DEPENDENCIES’ CONTROVERSY REVISITED

When it comes to the community of developers debating online, the tensions between centralisation and federation are paralleled by debates over standards; the discussions have as a *fil rouge* the controversy about ‘dependencies’ which we introduced in the case of Signal, and the impact of different aspects of dependency for users’ Internet freedoms.

A well-known argument in favour of centralisation – and against standards – was made by Moxie Marlinspike, Signal's lead developer, in a previously introduced (Chapter 2) blogpost (Marlinspike 2016), which attracted considerable attention and was widely quoted by developers, trainers and advanced users as a reason to opt for centralisation. According to this point of view, centralisation offers a better control 'by infrastructure' or 'by design', while federation can be 'dangerous' in terms of security, as it is hard to audit all the different implementations of the protocol and ensure correct updates. This first argument therefore frames the debate in terms of governance of a given project and its implementations. According to Marlinspike, it is the evolution of the market of end-to-end encrypted messengers that demands centralisation:

> One of the controversial things we did with Signal early on was to build it as an unfederated service [...] it's entirely possible to build a federated Signal Protocol based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all (Marlinspike 2016).

Marlinspike argues that only centralised solutions can satisfy constantly changing consumer demand and the overall instant messaging 'ecosystem'. Interestingly, he explains the success of current popular online communication systems as a result of the progressive evolution of federated protocols into centralised services (he uses, more precisely, the word 'cannibalisation':

> It's what Slack did with IRC, what Facebook did with email, and what WhatsApp has done with XMPP. In each case, the federated service is stuck
in time, while the centralised service is able to iterate into the modern world
and beyond (Marlinspike 2016).

According to Marlinspike, decentralisation seems to bring about more problems
in keeping older and newer versions of an application interoperable. Michael
Rogers, Briar’s lead developer (see Chapter 3), tends to agree when he explains
why the Briar app public release took longer than expected:

> We have an app that runs, it's fairly stable, it looks like a fairly complete finished application. The reason that we do not release it now is because we need to change the data format and protocol details, and keeping interoperability with older versions in the decentralised network when you're changing data format and protocol details is really difficult. So we want to postpone having to deal with that problem as late as possible by just doing limited test until those things stabilize before doing public releases (Michael Rogers, Briar lead developer – January 2017).

Thus, the Briar team implements ‘expiry dates’ into its releases in order to make
it technically impossible to communicate between users of newer and older
versions. This problem was also present in the case of a federated messaging
ecosystem, Matrix.org, during its transition towards end-to-end encryption,
when a multitude of older clients became incompatible with e2e. Therefore,
decentralisation supposes a certain amount of coordination and community-
oriented effort.

With respect to federation, another argument in favour of centralisation
concerns the security that comes with greater control over changes in proto-
cols and server administration. Marlinspike claims that social centralisation
is needed to successfully respond to unsolved challenges, such as metadata
protection:

> If anything, protecting metadata is going to require innovation in new
> protocols and software. Those changes are only likely to be possible in cen-
> tralised environments with more control, rather than less. Just as making the
changes to consistently deploy end to end encryption in federated protocols like email has proved difficult, we're more likely to see the emergence of enhanced metadata protection in centralised environments with greater control (Marlinspike 2016).

Peter Sunde, co-founder of The Pirate Bay and developer of the Heml.is messaging app, whom we have already met in Chapter 2, agrees – despite his preference for federated architectures, which were the initial model envisaged for Heml. is – that centralised control over servers may help enhance users’ privacy (social graphs, metadata):

> The idea to begin with [when developing Heml.is messaging app] was to do federated servers, but then we realized that it was not possible because we also wanted to protect social graphs of how people communicate and in order to do that we needed to make sure that we have control over the servers... All these ideas and technological solutions are always a trade-off (Peter Sunde, Heml.is).

The previously discussed trade-off between security and usability (Norman 2009; Cranor and Garfinkel 2005; Yee 2004) also reappears when it comes to older federated protocols, such as XMPP. Despite the fact that this protocol is defined by its promoters as a ‘living standard’, in Marlinspike’s words, due to its capacity for protocol extensions, it is often criticised for its weak support of rich media and for the difficulty of developing it for mobile uses. Due to the relative freedom developers have to deploy a variety of XMPP-based clients, XMPP suffers – according to Marlinspike – from fractured client support, and the difference between various XMPP clients results in lack of consistency regarding feature support in various clients. This may create confusion for users:

> Someone’s choice to use an XMPP client or server that doesn’t support video or some other arbitrary feature doesn’t only affect them, it affects everyone who tries to communicate with them. It creates a climate of uncertainty,
never knowing whether things will work or not. In the consumer space,
fractured client support is often worse than no client support at all, because
consistency is incredibly important for creating a compelling user experi-
ence (Marlinspike 2016).

However, developers from the PGP and the XMPP/OTR community, and the
growing galaxy of ‘Chat-over-Email’ projects, strongly oppose this critique from
Signal in their own blog posts and on a number of mailing lists where developer
discussions take place. For example, a developer involved in the Conversations
and OMEMO projects argues that the ‘extensibility of XMPP is not a danger
in itself. A good extension will spread naturally. Moreover, there’s a permanent
incentive to innovate in XMPP’. This has led developers in certain communi-
ties to try to standardise versions of the Signal protocol applied to federated
projects; for example, the OMEMO protocol has been submitted to the XMPP
Foundation in order to be standardised.

Signal developers believe that older protocols like PGP and XMPP actu-
ally harm user security and should be abandoned; and as Chapter 2 shows, the
Signal protocol has been crucial in boosting updates to these older protocols
and setting up a ‘required minimum’ of features for instant messaging applica-
tions. Signal has deeply affected the market of instant messaging, not only by
‘informally standardising’ a number of technical features, but also by attracting
financial investments towards centralised projects as opposed to decentralised
or distributed ones:

I believe that the problems with decentralisation we have right now are more
a problem of the lack of funding than a conceptual problem that decen-
tralisation does not work. Most XMPP clients are developed by volunteers
in their spare time. And it's kinda obvious that one single developer that
donates two hours a week of his spare time to develop an IM client is unable
to compete with five full time developers like Open Whisper Systems for
example (ChatSecure developer).
GIVING (OR RECLAIMING) CHOICE, DISTRIBUTING
RESPONSIBILITY

Opposed to Signal's strong discourse on 'consumer space', which has modi-
fied the scene of secure messaging by inviting to the discussion table a more
varied set of actors than the techno-idealists and crypto-enthusiasts of the
early days, are discourses such as that of the LEAP team, which strongly
defends open federated protocols (as opposed to self-made, closed or partly
closed protocols):

Moxie came out recently and ‘arrowed’ himself as a centralist in his blogpost about this topic. I disagree with him. His argument is that… open federated protocols are simply too slow to adapt and they are too difficult to implement because there’s too many different players, you make a change and you break everything [...] I think just because there are examples in the past of being difficult to change protocols does not mean that the idea of open protocols is dead. I think there’s definitely ways in which we can recognize the problems with open protocols so that we still can have interoperability but not be locked in an unchanging [ecosystem] (Elijah Sparrow, LEAP developer).

The arguments put forward by our respondents in favour of federated archi-
tectures concern several aspects: first of all, the danger of trusting one person
or entity behind the service ('putting all your eggs in one basket', as Elijah puts
it) and potentially enabling easier metadata leaks. From this standpoint, the
personal responsibility of a centralised service provider is very high and puts
the provider itself and all its users at risk. A federated solution would help to
distribute this responsibility:

Signal is trusted because it's Moxie, but if I was the government I could
force Moxie to hand over the keys and tell him like... you can't say anything
anymore. But he would at least shoot the system down, like the case with
Lavabit, the email service that Snowden used. That guy closed the service
down instead of working for the government. But most people will not do
that... The way to solve it is to have a federated system like you have your
own data at your own location (Peter Sunde, Heml.is).

Even though developers agree on the fact that decentralised systems are harder to design, their motivation to work on federated systems seems to be grounded in both the political and technical aspects of federation, first and foremost the ‘empowerment’ it can offer to the user by providing the means to control their own data and enable better metadata protection:

I know there are journalist organizations that run their own XMPP server, primarily using desktop clients. I'd like to allow people to run their own infrastructure around their own data as much as possible. There are other great tools that do encryption, at that point you can use WhatsApp or Facebook, they are using the same Signal protocol. But you're still not owning your data, all the metadata is controlled by a centralised system, they know all your contacts, who you're messaging at what time. [...] Other people feel differently. Like Moxie really wanted to do a vertically integrated centralised solution because it's a lot more usable if you control all the technology pieces (ChatSecure developer).

Another argument in favour of federated architectures – this time, as opposed to both centralised and purely p2p ones – emphasises the freedom for users to choose between various services, as Matrix's lead developer explains:

I had a long running dispute with Moxie Marlinspike about [decentralisation versus centralisation] basically because Matrix obviously is an interoperable decentralised network and he considers that a privacy risk because you can't control the whole network, there may be implementations that may not be secure, there may be bugs that you cannot control, that leak sensitive information and that is a thing for privacy. I would argue however that decentralisation is also important for freedom, and the user's ability to pick which service to use (Matrix lead developer).
In this sense, federated protocols are often compared to political systems, where users can ‘vote with their feet’ by leaving a server in favour of a better one. Federated protocols are said to provide better accountability and better control over the service providers. Moreover, the ease of migration offered by interoperable environments makes it possible for users to choose a better option without losing their social graphs.

> There's no way to establish any kind of accountability for centralised services that lock people in. It is very easy if people have federated services, they can just pick up and leave if their provider does something they may not like. So tomorrow Signal started to do that people were critical of, it would be very difficult to get people out of Signal to use something else (Elijah Sparrow, LEAP developer).

Indeed, our user interviews revealed among frequent XMPP users a peculiar attitude of ‘proximity’ with XMPP service providers, as well as a specific set of feedback practices between users and providers. The possibility of developing a client on top of an open federated protocol, with features needed by a specific user community, was also underlined as a positive aspect of federation, albeit that it limits the usage of these solutions to a more tech-savvy audience, or else requires localisation efforts.

Unlike developers, many high-risk users did not bring up the need for federation explicitly, but they raised it implicitly in how they formed trust relationships. Federation provides a suitable infrastructure for specific communities to organise without having to rely on intermediaries. In this sense, developers, high-risk users and trainers tend to build associations between specific configurations of political organisation and of technical infrastructure. For example, some developers and trainers justified federation as mirroring the organisation of anti-authoritarian social movements, which echoes w the conceptual analysis of the sociotechnical meanings of decentralisation proposed by Nathan Schneider (2019). Thus, there was a preference for systems that were considered politically trustworthy p by high-risk users; federation was generally viewed as positive in this regard by a minority of high-risk users. These users expressed concerns
about centralised systems collecting their metadata, although few realised
this would also be possible in most federated systems, albeit in a distributed
form – which attests to the important ideological component included in the
notion of federation.

Some developers believed the choice of federation to be inherently con-
nected to not collecting metadata, and felt that models existed which were both
usable and decentralised:

With Signal, it's impossible to create a decentralised system because phone
numbers aren't decentralised. With XMPP it's like an email address. Even
users who aren't technologically savvy can understand this is my user ID,
and this is my server (OMEMO lead developer).

The ‘chat-over-email’ paradigm is also based on understanding the risks associ-
ated with synchronising contact books and depending on mobile operators.
Moreover, federated projects promote interoperability as a solution to the walled
gardens of secure messaging applications. Building a potentially open system,
pluggable and modifiable according to the needs of a community, also means
removing parts of the work from the developer team.⁵

The remainder of this chapter explores three federated protocols and the
applications based on them: Conversations (and OMEMO protocol), Matrix.
org, and the ‘chat-over-email’ effort, with projects such as Autocrypt/Delta
Chat, LEAP and Pixelated. Through the case studies, we aim to explore the ten-
sions between the elements of technical innovation and the politico-ideological
choices that shape particular definitions of ‘freedom’, both for users and devel-
opers, in federated arrangements.

*Conversations and OMEMO: Bringing future secrecy to XMPP*

The federated end-to-end encrypted messaging app Conversations is based on XMPP and OTR/OMEMO.⁶ This project could be defined as a ‘one-man app’, its core developer working alone, driven by his own technical curiosity and relying on his own previous experience as user of XMPP and OTR:⁷
I am an XMPP user. When I got my first Android phone there were no good examples available for the platform. I actually decided to write my own app. I did maybe 95% of the code by myself. I do have occasional contributors on github but was pretty much alone (Daniel, Conversations/OMEMO lead developer).

Conversations is an end-to-end encrypted instant messaging application that offers users a choice of three encryption algorithms and an unencrypted (TLS-only) mode. This design solution is unique in the field and makes Conversations an interesting case-study. The choice between three different algorithms was, as one of the Conversations developers explained to us, his version of an answer to the interoperability problem; when he started working on Conversations, end-to-end encryption methods were available for different clients, and Conversations tried to be compatible with them all, so it had to implement OpenPGP as well as OTR.

As a third choice for encryption, the OMEMO protocol (recursive acronym for OMEMO – Multi-End Message and Object Encryption) was created with the idea of providing future and forward secrecy and deniability and gives the possibility of message synchronisation and offline delivery, which are both important features for a federated protocol. According to its creator, OMEMO was developed to solve specific limitations and problems that existed both in OpenPGP and in OTR:

> One of the main limitations of OTR was that it didn't work with multiple clients. If you are logged on your mobile client as well as your desktop client, OTR does not work. Open PGP had downsides as well: there wasn't any verification built in, it did not have any forward secrecy or any other nice crypto traits that you wanted to have (Daniel, Conversations/OMEMO lead developer).

OMEMO was developed during the Google Summer of Code in 2015, using the LibSignal library.⁸ Daniel, Conversations and OMEMO's lead developer, acknowledges the lack of standardisation and lack of specification of the Signal
Protocol, which we noted in Chapter 2 ('The underlying cryptography was not very well documented, and we were just basically making through the library'). However, Daniel was able to work with the library well enough to implement the Double Ratchet, the up-and-coming 'golden standard' of instant messaging promoted by the widespread acceptance of the Signal Protocol:

> I personally don't have a very strong cryptography background, I try to rely on what's already there, what's already popular right now. Like Signal protocol with double ratchet is quite widespread these days and seems to be well received by various cryptographers. So it makes sense to base OMEMO on something that's similar (Daniel, Conversations/OMEMO lead developer).

OMEMO, being, in Daniel's words, an 'XMPP wrap around LibSignal', brings Signal's innovative features, such as future secrecy, to XMPP. In this sense, protocol design choices for Conversations and OMEMO are determined by the overall development and state of the art of modern cryptography (see Chapter 2: 'Signal does it, WhatsApp does it'). Instant messaging, over the development of OMEMO, is understood as a set of tools for the exchange of information that is intrinsically 'temporary', and users are likely to favour a feature such as future secrecy over the possibility of permanently accessing their archives. However, Conversations does not support the function that leads to the disappearing of messages, even though users, according to our interviews, have been asking for it. Instead, Conversations opts to entrust users with more choice, but also with the increased responsibility that comes with it:

> If you are looking into data hygiene, not keeping around the history is something that you should do for yourself on your own device according to your own rules and Conversations has a setting that allows you to delete all messages both sent and received on your device and regulate intervals, for example a month or a week. It is a more honest solution. Because you can control when these messages are deleted. It is up to each individual user to decide what to do with the data (Daniel, Conversations/OMEMO lead developer).
Interestingly, this approach of entrusting users with both choice and responsibility differs from the automatic, or ‘opportunistic’ turn in encryption embraced by applications aimed at the general public (e.g. Signal), whose creators actively work on concealing a lot of options from users to make the application more immediate and comfortable to use. Conversations seems to be targeted more towards those users for whom freedom equates to having more control over the application and, in the words of one of our respondents, ‘see[ing] encryption happening’.⁹

The kind of ‘freedom’ that Conversations aims at giving users extends not only to the server, but also to the encryption scheme that they prefer or are more used to. The intention is to help attract more users, regardless of the encryption algorithms that their peers support, as Conversations can talk to OTR- and to OpenPGP-only clients. The language elements of ‘user choice’ return here: ‘They can choose Open PGP and will not have forward secrecy but will have some other features in return’. [Daniel, Conversations lead developer]

This freedom of choice is, as we have demonstrated in the section above, is mentioned as one of the advantages of federation. It also gives users the possibility to gain certain security, privacy or usability features that exist in some protocols but not in others. For example, OpenPGP offers archiving, which, for low-risk users, may sometimes be more important than future- and forward secrecy:

> There are a couple of users who don't want to move away from OpenPGP because all these modern encryption schemes that provide forward secrecy do not have the ability to retrieve your messages, so when you're setting up a new client you can't access the archive with all your messages. And OpenPGP allows you to do that. That's arguably a very niche use case, less secure in some ways because it doesn't have forward secrecy and stuff like that, but some users really prefer to have the ability to access the archive if they are not under high risk (Daniel, Conversations/OMEMO lead developer).

As the app’s developer explains it, Conversations is aimed at a specific user-group, that – if we were to go back to categories we questioned but found useful
earlier in the book – could be defined as high-knowledge, low-risk and privacy-
aware users, who strongly support XMPP, federation and open source, and opt
for Google-free and privacy-preserving solutions such as the minimisation of
data storage, with both technical and ideological components subtending their
choices. While applications such as Signal, Telegram and Wire are arguably
starting to be considered as mainstream, and are often covered in the media, in
the case of Conversations, user enrolment happens via specific digital security
training sessions, advice from tech-savvy friends, personal technical knowledge
and interest in XMPP and federation. These users are, in turn, introducing their
close network and peer groups to the app via word-of-mouth dynamics.

OMEMO is not yet a standardised protocol, though it has already been
adopted by a number of XMPP clients (listed on a dedicated website).¹⁰ At
the time of writing (16 September 2019), the website lists 18 XMPP cli-
ents fully supporting OMEMO and 33 clients that are currently working
on being compatible with OMEMO. OMEMO has been submitted to the
XMPP Foundation for standardisation and is currently at the first stage of
the standardisation process.

However, our interviews with the developer teams of both Conversations
and ChatSecure have revealed that these projects, though well known within
the XMPP scene (developers mention that they regularly attend XMPP-related
events), are almost invisible within more hybrid events aimed at privacy
advocates and high-risk users and other stakeholders (Internet governance
organisations, lawyers, researchers), such as, for instance, the Internet Freedom
Festival or RightsCon. These applications could have had a wider adoption,
especially given the strong modern-state cryptography implemented in both
tools; however, their authors remain disconnected from the ‘high-risk, low-
tech’ communities. Media coverage is also partly responsible for that dis-
connect: both applications are much less visible in non-tech-savvy oriented
media, and cannot draw on the support of well-known public figures such as
Edward Snowden, or organisations such as EFF, AccessNow or Tactical Tech.
The latter are more eager to cover centralised applications (except for the Tor
browser) and are *de facto* not involved in advocacy for technical decentralisa-
tion or federation.
*Matrix.org: Facing the interoperability problem*

Lyon, France, 25 May 2017: Ksenia attends the European Lab session on privacy-enhancing technologies and decentralised identity management systems. At some point, an interesting discussion takes place, which illustrates the state of the art in the field of encrypted messaging quite well. The panel moderator, himself a user of multiple encrypted messaging tools and protocols including PGP, Signal, Wire and Jabber, asks the audience: 'How many messaging applications do you use on your mobile phone?' After a brief round of answers from the public, he counts that among the forty people present, the average number of messaging applications is five per person, while several people say that they regularly use more than seven messaging applications. This question allows him to bring to the table the important problem of digital 'silos' (Kent 2019): how do people communicate in this 'mess of messengers', being separated by the walled gardens (Musiani 2016) of their favourite messaging clients, but also, more deeply, by various encryption protocols that are incompatible with each other.

While Conversations suggests a solution for interoperability between encryption protocols (OpenPGP/OTR/OMEMO), it still runs over XMPP and requires users to have an account on an XMPP server (or 'even better, run [their] own XMPP server for [them] and [their] friends', as OMEMO's inventor puts it). However, interoperability remains a problem for users of centralised messaging applications (Kent 2019). Individual projects have attempted to solve the interoperability problem, such as by bridging Jabber — a free IM service based on XMPP — to centralised applications. For example, the Russian Pirate Party has developed a 'Jabber bot' for Telegram, that helps Pirate Party members who do not trust Telegram to continue communicating within their community using Jabber.¹¹

Another project that addresses the interoperability problem is Matrix.org, which works on giving users the possibility to bridge various messaging applications and let users connect without laying on them the 'burden' of having to migrate from their favourite tools. The underlying idea of Matrix.org is meant to go beyond an instant messaging application; it is framed by its developers as an ecosystem that could be used for any kind of data sharing:
The model is very much inspired by the phone network, in terms of the phone network being a global way to exchange communication data. But in the end it's closed, it's not open, it's quite centralised to the telcos. So we wanted to create a complementary network which has the openness and the decentralisation baked in (Matthew Hodgson, Matrix lead engineer).

The main goal of the project, as underlined in several articles, is to ‘create an architecture that tackles the interoperability problems that were not addressed by previous approaches’. This interoperability is meant to become a substantial comparative advantage and enrolment factor for users: ‘where IRC has a high barrier to entry, requiring you to know exactly what server you’re connecting to and configure accordingly, Matrix would let you associate with as many public identities as you’re willing to share (phone number, email address, Facebook, Google, and so on), as long as they support the Matrix standard. Otherwise, it requires no setup – it’s just like if you were using any consumer messaging service’ (Weinberger 2014).

Matrix is an open-source, non-profit project under Apache license, and was financed by Amdocs until 2017. Since then, the Matrix team has created its own foundation, called ‘New Vector’, that offers consulting services to those who want to use hosting services within Matrix or use Matrix for commercial purposes:

> We offer help to build bridges between various messaging platforms. If I have an enterprise where everyone is using Slack, I can pay huge amounts of money to Slack to buy their corporate solutions, or I can pay a couple of bucks per month to Matrix to maintain bridges (Matthew Hodgson, Matrix lead engineer).

Recently, New Vector obtained funding from an Ethereum startup, and Matrix attracted interest from the French government that asked for support in deploying an internal messenger for civil servants, built on Matrix/Riot.¹² As of 16 September 2019, the team counted sixteen members, eleven of them based in London and five in France. They support Android, iOS and Desktop versions. Currently there are 5000+ chat rooms registered on Matrix, focused mostly on
‘the techno-privacy aware community, computer scientists and normal developers’, in the words of Matrix’s lead developer.

Unlike LEAP (which will be addressed in the last part of this chapter) and Signal, the Matrix team does not take an explicitly political or ideological stand and does not aim at providing software for specific audiences with a political agenda or engaged in political arenas, such as activists. The creator of Matrix positions his team as ‘sort of moderate, really centrist’, and adds:

> I am very sympathetic to the human rights issue and privacy but we haven't set up with Matrix to build something like Tor or Signal or Ricochet or any of those tools which are optimized very specifically for privacy at all costs. Instead we're trying to do the best we can and be very mindful of it, whilst also building an ecosystem that works and is practical (Matthew Hodgson, Matrix lead engineer).

Matrix’s creator identifies his position as a kind of ‘liberal pluralism’, which is reflected in the very architecture as well as the users of his system. From the point of view of the architecture, it is a federated system that bridges a great variety of different messaging tools, thus leaving a certain amount of freedom to users, allowing them to retain their usual interface, while making it possible for them to connect with others. As Matrix’s lead developer points it, Matrix is trying to respond to the problems of walled gardens, produced by the quick and somewhat ‘chaotic’ development of the messaging ecosystem, especially on mobile. As an illustration of his objective, during our interview, he showed us his mobile phone with around 10 different instant messaging applications (from Wire, Threema, WhatsApp and iMessage to Signal).

In terms of user pluralism, Matrix has a variety of rooms addressing a wide variety of subjects, from cryptography and open source, cryptocurrency and decentralisation to psychological help, furries, subcultures and fan communities, left-wing groups and alt-right Donald Trump supporter rooms. Two of the main lingering problems for Matrix are managing spam and maintaining a decentralised reputation system – issues that, according to Hodgson, are still open for research, and need to be supported by a ‘morally neutral’ positioning.
Within the ecosystem of mail and messaging applications, Matrix identifies itself as a compromise, in a positive sense, between centralised and completely decentralised systems, that seeks to provide satisfactory security solutions while running a partially decentralised system:

> Signal is pretty much saying: we’ll run it [Signal] as a centralised service therefore we can guarantee its security. Email in the current state has no privacy and security but it’s being 100% decentralised. So we’re basically a middle-ground approach (Matthew Hodgson, Matrix lead engineer).

For the main developer of Matrix, the relation between decentralisation and security is a thorny issue: according to him, ‘the two things definitely pull against each other’. He sees email as an insecure system, because of the independence of email service providers. In this sense, an attempt to introduce a standardised, automatic mail encryption, that could be implemented by various **Mail User Agents** with relatively low resources, could be a possible step against many passive attacks. Due to the convergence of interests in this regard, Matrix was invited to present its current work at the Autocrypt hackathon in December 2016; this event gathered different projects that discussed not only email encryption but also decentralised reputation and identity systems, such as Scuttlebutt. Introducing encryption through headers also becomes a form of ‘governance’ via federation, between the multitude of mail service providers: this kind of governance, unlike Signal, is based on a very detailed specification, which could be approved by the galaxy of email service providers who take part in the Autocrypt effort.

For Matrix as a decentralised system, the frequency of passive attacks made the implementation of end-to-end encryption a crucial step; it was also a specific way to establish trust within federated infrastructures, where trust is spread across a large number of server administrators:

> In decentralised systems, you end up with a large attack surface. If you were running a server and I am running a server, and I send a message, the message is on both of our servers that means that we have to trust a sysadmin of both
of the servers. In a big room with 5000 people, and, say, 1000 servers, you have an even bigger problem. If you're sending something sensitive or private, it will be shared across all of the servers. Getting end-to-end encryption is critical so that the servers get an encrypted copy of the message rather than the real message so that you don't need to worry about system administrators spying on messages (Matthew Hodgson, Matrix lead engineer).

As a federated project, Matrix is deployed on a multitude of servers (according to its lead developer, more than 15,000 as of 21 December 2018) that are not under the control of the Matrix team. Moreover, as Hodgson explained in the interview, each server can have its own privacy settings and policies for collaborating (or not) with lawful interception. Thus, self-hosting is promoted by Matrix as a way to increase security, in addition to enabling encryption. In the case of Matrix, end-to-end encryption was adopted two years after the beginning of the project – while, as our research has shown, when a system has not been designed with end-to-end encryption from the very beginning, the transition is rather slow and difficult. In the case of Wire, originally built with no end-to-end encryption, the team had to remove part of the server-side code that still contained the possibility of a plain text message being sent before going fully open source. In the case of a decentralised system, the problem of implementation is even harder, as some of the older clients run with no encryption and additional steps must be taken in order not to block users who use older clients:

> So by now it's an opt-in on a room basis. But once we're out of beta we'll be turning e2e on by default by every private room, and we'll have a proxy migration path for other clients so that simple clients that know nothing about cryptography can easily join and participate (Matthew Hodgson, Matrix lead engineer).

The protocol implemented for end-to-end encryption in Matrix is called Olm and is a version of the Signal Double Ratchet. Interestingly, while Wire had difficulties in implementing the Signal Protocol (see Chapter 2), Matrix did not
encounter hostility or tensions from the Signal team,¹³ except for an explicit condition to avoid using names or references to Signal (or its predecessor, Axolotl). Hodgson attributes the cause of this relatively successful collaboration with Signal to the political economy of open source and to the very architecture and nature of Matrix, which opens the possibility of bridging a large number of other projects:

> The difference between us and Wire is that Matrix.org initiative is non-profit and entirely open source. The Apache license that we use is aggressively permissive [...] And I spoke to Moxie and explained what we were doing. And he said: you're crazy, and if it works then go for it, it will be great, but you guys have fun doing that and I will keep doing Signal. He does not want to persecute us. [...] Whereas other companies, which are doing proprietary commercial messaging solutions even if some parts of it are open source, he [Moxie] will see them as competition. We are more like idealistic altruistic hippies who should probably fail while building this white elephant of Matrix, and if we don't it will be a good thing for everybody including him [Moxie]. So why not support us? (Matthew Hodgson, Matrix lead engineer).

Currently, Matrix.org¹⁴ is working on minimising the spread of disinformation and spam. Indeed, while centralised platforms such as Twitter or Facebook are increasingly subject to critique for enabling the spread of disinformation and hate speech, federated alternatives, such as Mastodon or Pleroma seem to offer some ways to counter or minimise the spread of disinformation, by a mix of social and technical moderation by server or instance administrators. The Matrix team hopes to address this problem by deploying a reputational system and seeks a way for users to filter content by developing a system of open and modulable filters. Furthermore, as a response to the increased risk of Internet shutdowns in politically unstable regions, such as Belarus, Iran, Kirghizstan and others, in June 2020 Matrix released an alpha peer-to-peer version of its software, which is not dependent on an Internet connection provided by telecom operators.
Autocrypt: Email encryption as a community-building effort

Email remains stubbornly unencrypted, due chiefly to problems with key management. Proprietary closed-source projects offering ‘encrypted email solutions’ exist; however, they are not managing to solve the interoperability and fragmentation problem. End-to-end encryption in Protonmail, for instance, works only if both users have Protonmail installed; this is reminiscent of how centralised instant messaging clients work: binding users to specific applications. Furthermore, users’ awareness of this constraint is unclear; our early-stage research showed that users do not always know about this particularity of Protonmail and think that all Protonmail emails are encrypted by default.

However, email ‘remains the largest open federated identity and messaging eco-system, anchors the web, mobiles and continues to relay sensitive information between people and organisations’.¹⁵ In the context of centralisation in the field of IM apps, with telephone numbers being massively used as unique identifiers, several initiatives have recently been launched to revive encrypted email, such as Autocrypt, pEp, the Google End-to-End project and LEAP/Pixelated. These efforts have not yet been finalised or have not reached widespread adoption; this process ‘in-the-making’ should be analysed, from an STS perspective, as a technosocial, community-building effort that may have important consequences for the whole encrypted messaging/mail ecosystem as it suggests a ‘(re)turn to federation’ and proposes alternative approaches to identity and key management.

Because of its decentralised architecture, automatic email encryption implementation demands a strong community effort and the enrolment of a multitude of actors (namely, Mail User Agents-MUAs, and email service providers). These actors need to agree on the protocol, its documentation and modalities of implementation, but also its UI/UX features, logo, funding sources and so on.

Unlike centralised mobile applications for instant messaging, that can impose their own protocols (often unstandardised) and try to ‘own’ or capture users who interact within the IM app, the federated email ecosystem remains largely open. It blurs the borders between users and service providers, as the barrier of running a privately-owned email service has become lower, involving more
people in the ecosystem. Migration costs from one email server to another are also relatively low, and users can shift identities or have several ones. Thus, there is fundamentally no way (nor will) to control all of the MUAs and service providers at both the technical and ideological levels. However, there are several ongoing attempts to create a tool that can connect different actors without centralising the whole ecosystem – an artefact that Michel Callon would probably consider a ‘translation’ tool.

One of the most recent innovations in this field is Autocrypt, a project run by an international group of email program developers and crypto enthusiasts from the open-source privacy-aware community. An Autocrypt plugin was added to the Mozilla Thunderbird email client in August 2019, marking an important step for this young project towards greater user adoption. Autocrypt provides a possible answer to the problem of key discovery, exchange and key management, thus addressing two important challenges: usability and ‘re-decentralisation’. Instead of keeping public keys on a centralised public key server (which may create vulnerability), and proposing that users retrieve, exchange and verify keys by themselves (which may create confusion) Autocrypt puts key material in the header of the email.

Usability-wise, this automatic key discovery process helps to solve important problems related to key exchange, verification and management. The part of our research focused on users showed that they rarely verify keys or can even define what a key is. High-risk users tend to verify the authenticity of their contacts when they receive notifications on an IM app about the changes in the key material, using ‘real-life’ non-cryptographic solutions such as voice calls or contacts over social networks. However, this behaviour is rare. And when it comes to email, advanced key verification rarely happens. Moreover, as our interviews with trainers show, the general tendency in the trainer community is to avoid explaining keys during informational security seminars, as ‘the old metaphors of padlocks are not really clarifying what’s going on there, and we waste a lot of time on it’, as a French trainer from the hackerspace Le ReSet explains. The general turn to ‘automatic’ or opportunistic encryption makes the key discovery process invisible to the user, and this is seen by several trainers as a positive step towards the mass adoption of encryption; McLemon, a cryptotrainer from
Austria, points out that ‘having encryption as a default mode means a user does not have to learn about all the math beyond the crypto [. This] is the key part in making encryption popular’.

The Autocrypt solution addresses the problem of centralised public key storage and proposes a new form of coordination or federation of the email app developer community, which has been for a long time rather dispersed and has not really had a place to ‘meet each other’, in the words of Autocrypt’s promoters. In this sense, email headers become instruments of ‘self-governance’, communication and coordination of MUAs, leaving a lot of freedom to MUAs while providing a standard that helps to keep encryption working across different agents. The usability and federation of MUAs are interconnected, as scalability is necessary in order for automatic encryption to work, which implies collaboration between the multitude of third-party projects.

In order to work and to be spread widely, Autocrypt relies on the joint efforts of professional communities – service providers in one case; mail client developers in the other. In short, it relies on the widespread enrolment of email app developers. This community-based approach is very different from the one offered by Signal-like centralised applications, where the authors of the protocol seem to have greater control over the implementations, and various implementations do not offer interoperability.

Until recently, Autocrypt was focused on passive attacks only, primarily targeting a low-risk audience. However, this has served as only the first step towards providing more sophisticated solutions against active attacks and targeted surveillance: indeed, the most recent development of Autocrypt includes a solution against the active attacks of a network adversary.¹⁶ Even though Autocrypt initially focused on low-risk users, the Autocrypt motto ‘email encryption for everyone’ implies in the longer term a benefit for high-risk users: mass adoption of email encryption makes both mass surveillance and targeted surveillance more expensive and harder. By now, Autocrypt has been supported by an important number of email app developers, and starting in June 2017, the Autocrypt specification has been adopted by a new project, Delta Chat, that brings the Autocrypt encryption scheme into the field of instant messaging, offering interoperability between email and the new instant messenger.
*Delta Chat: Secure messaging over email as an Autocrypt offspring*

The Delta Chat secure messaging application is the pioneer of what is now called
the ‘messaging-over-email’ effort. Similar to Matrix, this project is driven by a
push for social decentralisation aiming to unbind users from ‘messenger silos’,
relying on the pre-existing email infrastructure to favour scalability to billions
of email users. The general effort to reuse the interfaces of existing popular
messaging apps (inspired by the Telegram and Signal UI) draws from the same
core principle: avoid creating yet another silo and offer users something they
already know and are familiar with, in order to minimise migration and to focus
on protocol upcycling. In the words of Delta Chat’s lead developer, ‘Delta Chat’s
take is not so much in designing protocols but using existing federation. But of
course, this in turn, is based on protocols, SMTP/IMAP, OpenPGP and others’.

Delta Chat’s approach to social decentralisation includes specific approaches
to teamwork and collaboration with other projects – from crypto libraries to
decentralised file sharing solutions. While it originally started as the ‘lone wolf’
project of German developer Bjoern Petersen, Delta Chat soon joined other
projects and has gradually become a collaborative effort drawing upon a galaxy
of communities. Delta Chat claims a strong focus on usability and to that end
interacts with user groups in various at-risk regions, from Ukraine to Cuba,
Hong Kong, Taiwan and the MENA region.

Some of the sets of protocols used by Delta Chat are long-term standards (SMTP, IMAP, OpenPGP for instance), while others are in active development. In terms of protocol governance, one of the fundamental elements of Delta Chat that makes it ‘pluggable’ and interoperable with other applications is the Autocrypt specification, first released in December 2016 – a set of guidelines that ‘describe how e-mail programs negotiate encryption capabilities using regular emails’ (Holger Krekel, Delta Chat lead developer).

Several key contributors to Delta Chat have also been active in the Autocrypt
community and both share a set of practices. Both have been quite ‘loosely coor-
dinated’ with around a dozen active contributors, from developers and crypto
library designers to UX/usability experts. These contributors, many of whom
work on a voluntary basis, are mostly decentralisation or crypto enthusiasts,
who have known each other from various offline hacker gatherings or online
discussions and collaborations around email and IM encryption, decentralisa-
tion and certain politically engaged hacker circles, including ‘activist tech col-
lectives’. Moreover, many contributors to both efforts use Internet-Relay-Chat
(IRC) on freenode, a major gathering point for open-source developments.
The #autocrypt and #deltachat rooms each have 60–70 participants, and in
September 2018 Delta Chat had around 5500 posted chat lines. Both efforts
also use the github.com site and the ‘git’ versioning tool to collaborate, and to
discuss and review each other’s changes.

Even if the recent funding for Delta Chat provided by the Open Technology
Fund since July 2018 has stabilised the core team working with Delta Chat,
many regular and active contributors continue working without any official
affiliation. Delta Chat seems to share a tacit agreement about certain modes
of collaboration that avoid reproducing what is understood as the ‘startup
way’, which attributes fixed roles to team members and establishes hierarchies
within teams. Instead, the work is organised around a set of main components
of Delta Chat, such as Core, Desktop, Android and iOS versions, legal and
licensing efforts, as well as usability and need finding. Currently, Delta Chat
operates more as a decentralised ‘ecosystem’ than as a messaging app: instead
of offering a specific solution, it works towards bridging various solutions with
the aforementioned components of Delta Chat. The priorities for development
and collaboration are partly informed by fieldwork and constant informal com-
munication with targeted user communities, mainly high-risk journalists and
human rights activists and NGOs. Interestingly, while some of Delta Chat’s
development and collaboration decisions are pushed forward by various Delta
Chat team members out of their personal technical or political preferences,
others are also driven by the design of the current funding proposal, supported
by the Open Technology Fund.

Delta Chat is also working with email service provider communities, push-
ing for certain changes, namely, to identify Autocrypt-friendly providers who
currently support Delta Chat. Indeed, one of the drawbacks of the Autocrypt
solution is the spam problem, with headers often being read as junk by email pro-
viders. Currently, Delta Chat is deepening its collaboration with activist-oriented
email providers to work on new features such as automatic account creation, tailored for specific use-cases, for example those involving field missions for journalists and activists with self-destroying temporary accounts.

While being essentially a non-for-profit and activist-inspired project, Delta Chat aims to be usable by larger user communities. Recently the team has gained a Mozilla Public Licence in order to open up collaborations with for-profit actors: ‘The move to MPL is meant to be more inviting for commercial collaborators as it is now easier to incorporate Delta Chat’s core chat/contact and IMAP/ SMTP/Autocrypt implementations in all kinds of offerings’ (Holger Krekel, Delta Chat lead developer).

## LEAP/Pixelated: An ‘encryption as a human right’ infrastructure for providers

As its website sums up, the LEAP project ‘fights for the right to whisper’.¹⁷ Indeed, in a less subdued way than several other projects analysed in this and previous chapters, the LEAP project is structured by a political vision, most of its members having previously been involved in so-called ‘radical tech collectifs’ (see Milan 2013). However, if LEAP’s initial target was high-risk users, the scope of the project gradually has come to include a wider audience of Internet users, as LEAP frames encryption as a human right:

> Like free speech, the right to whisper is a necessary precondition for a free society. Without it, civil society and political freedom become impossible. As the importance of digital communication for civic participation increases, so does the importance of the ability to digitally whisper. LEAP is devoted to making the ability to whisper available to all Internet users.¹⁸

While Autocrypt engages email app developers and opts for an in-band approach, LEAP primarily addresses email service providers. The server-side part of LEAP, the LEAP Platform, is also called ‘provider in a box’ and is a ‘set of complementary packages and server recipes automated to lower the barriers of entry for aspiring secure service providers’. The client-side part is called Bitmask, a
cross-platform application including a local proxy that a standard email client
can connect to, and an easy one-click Virtual Private Network (VPN) service.
Bitmask offers full end-to-end encryption, while public keys are automatically
discovered and validated. The LEAP project was developed in response to both
the crisis of email encryption infrastructure, and usability issues that make it
difficult for users to use encryption without compromising their confidentiality
and the confidentiality of the people they communicate with.

LEAP's architecture and protocol design solutions have been forged through
discussions with other tech collectives, questioning the 'coherence' between
certain types of politics and architectural solutions, namely, anti-authoritarian
leftist politics and peer-to-peer models. LEAP develops its own philosophy of
decentralisation, that is far from being an apology for radical decentralisation
or p2p, and quite clearly suggests that a third way is necessary:

There are three architectural models: centralised, federated and peer-to-
peer. And LEAP came out of a shared understanding [...] about the way in
which people with certain type of politics, with anti-authoritarian politics,
they bind their politics to a decentralised model and they believe very
strongly that all of the technology must follow a decentralised model. And
our critique of that was that there are a lot of technical problems with the
decentralised model, and that you can't actually... the politics and the
tech architecture... there is some correlation but trying to [correlate them
directly] does not work at all. So for all these reasons and many more we
were upset with how people from anti-authoritarian politics were mapping
this directly to a decentralised architecture which we felt had potential but
there are a lot of hard research problems that are unsolved (Elijah Sparrow,
LEAP founder).

In response to problems found in both p2p and centralised models, LEAP pro-
poses to initiate a transition of the whole modern encryption ecosystem towards
open federated protocols – these can also become an important turn in Internet
governance, as they can become an instrument to redistribute power relations
and re-decentralise infrastructures, nowadays owned by a minority of big actors:
We felt that we needed a revival of the 1990s. [The] 1990s were like before the craziness of the dotcoms, everything if you wanted to communicate you had to use an open protocol that was federated, that was the way everything worked. [...] We felt that... the time was right to take some of the new innovations in the last 20 years and start to turn those into open protocols that can be federated and do not lock people... do not chain them to the monopoly powers of the Internet, Google, Amazon, Microsoft and Apple... (Elijah Sparrow, LEAP founder).

In this sense, LEAP refers to a specific vision of the history of the Internet(s), that postulates the existence of a 'golden age' of decentralised open protocols (Oram 2001) – a vision that is controversial within other communities, such as the one gathered around Signal. The same kind of 'nostalgic' turn to federation has been observed among Russian tech and privacy-aware user communities, from the growing interest in Matrix.org, to the revival of such formats as XMPP-based 'microblogging' as alternatives to Twitter. However, the early-stage federated protocols were accessible only to specific communities of tech-savvy users. Nowadays, as ChatSecure's lead developer noted in a previously cited quote, setting up and maintaining federated infrastructures for larger segments of the online population is far from easy due to a number of infrastructural, financial and human constraints. In this context, one of the main goals of LEAP is to spread federation by deploying 'kits' of interlaced protocols, sets of packages necessary for a quick deployment of a secure infrastructure:

> One reason that holds back the federated model is that properly hosting secure services on the web now is very difficult, beyond the reach of people who do not specialize in keeping their servers secure. So we want to be able to encapsulate all the skills and best practices for maintaining an infrastructure into an automated suite that allows people with moderate skill to be able to do it properly (Elijah Sparrow, LEAP founder).

LEAP is mostly built on existing open federated protocols;¹⁹ the contribution of the project is understood by its members as the combination of these protocols
and their ‘translation’, in Callon’s sense, for easier deployment. LEAP is also interacting with other solutions, such as mixnets, in order to solve important ‘hard’ research problems, including how to keep keys up to date and reduce metadata leaks – problems that are, in fact, linked:

> Initial key discovery is only half of the problem. The harder half is your keys up to date. You have to be constantly refreshing them and that potentially leaking a lot of information. That’s particularly where the metadata leaking becomes important. LEAP also works on it [to] build a mixnet infrastructure for different purposes – e-voting and email (Elijah Sparrow, LEAP founder).

As Conversations, LEAP aims at being ‘backwards compatible’, supporting older protocols and older clients without radical transition towards post-PGP protocols; it also aims at supporting different encryption protocols; however, currently, the only supported protocols are OpenPGP and S/MIME. As a consequence, LEAP-based solutions also lack important security properties, such as forward secrecy. However, this is not inherent to LEAP per se but is, more broadly, a problem of the actual state of the email encryption ecosystem; as Sparrow points out, it is ‘baked in the OpenPGP as a protocol itself’. LEAP proposes an alternative solution to the lack of forward secrecy in OpenPGP, which consists in discarding the encryption and signature information once the message is obtained and re-encrypting it in a new format. Forward secrecy is inherent to the specifics of mobile and instant communication, but the LEAP team argues that email usage is very different, including having a different attitude to time and archiving: users do need archives in email, whereas disappearing messages are suitable and needed for IM communication.

On the client side, LEAP contributes to the development of solutions such as Pixelated, an automated mail encryption client which aims at bridging the gap in user experience between existing mainstream proprietary solutions and open-source tools based on a federated infrastructure with a strong encryption dimension (‘that’s the goal. Same user experience’, says Sparrow). Indeed,
Pixelated is aimed at a specific audience of users with low technical expertise. As our interviews showed, this tool has been tested *inter alia* with a community of Brazilian farmers, a radical collective fighting to keep their land.²⁰ As Pixelated’s UI/UX designer notices, the client has been developed for conditions of low-quality Internet connection, and for a user group that has few interactions with email and online services in general.

In Pixelated, key verification is invisible for users and happens automati-
cally. When we assisted at the Pixelated usability workshop at the Chaos
Communication Congress in December 2017 (33c3), it was interesting to
observe the reaction of its audience (tech-savvy people, frequent GPG users)
to Pixelated UI/UX. A number of participants remarked that they did not feel
their emails had been encrypted because they had ‘nothing to do’. To them,
feeling secure meant the ability to ‘see encryption happening’, possibly with
additional effort and user involvement; however, being a hosted/cloud solution,
Pixelated is specifically built to place less trust on the client side. This solution
turns out to be interesting for specific use-cases, such as journalism and situa-
tions of physical device threat/seizure:

Let's say you're a journalist [...] If you are travelling and doing reporting and crossing borders, your situation changes dramatically. You probably don't have a device that's always in your presence that you may trust, and maybe you don't want to have one. So suddenly it makes sense to have a hosted version and to be able to say may be only on a temporary basis or on a permanent basis, I am gonna move my trust, my most sensitive things like my private keys that unlock my universe of communication archive, I'd like to move that to the web. And the unique thing about what we're doing with Pixelated and LEAP is that by moving that trust from your personal device to a server, you don't have to change your trust relationship with your email provider (Elijah Sparrow, LEAP founder).
CONCLUSIONS: COMMUNITY, COMPATIBILITY, CUSTOMISATION AND CARE — THE FOUR CS OF FEDERATION

Retracing recent debates on federation in encrypted messaging, this chapter has sought to analyse the shaping of federation as both an infrastructural and a social experiment. We have seen how, in the different examined projects, developers seek to achieve a compromise between high levels of security and better usability, in a constant dialogue with ‘ideological’ motivations such as distributing responsibilities onto a larger number of actors and offer particular versions of online freedom, such as giving users the choice of the level of autonomy they wish to achieve.

We suggest that a tentative systematisation and conceptualisation of what has been seen in this chapter can be attempted with what we will call the ‘four Cs of federation’: community, compatibility, customisation and care. We offer some conclusions about these four aspects below.

In terms of community, (self)-governance and advancement of federated projects implies an important community-driven effort and depends on engaging a variety of service providers and clients into accepting new open protocols or new libraries. Communication and consensus among various projects are needed in order to be able to advance in a federated environment. The transition towards next-generation encryption protocols within federated ecosystems is likely to be slow and difficult; however, our research quite clearly demonstrates the rise of a powerful and diverse community of interested actors involved in a co-production of elements (protocols, packages, libraries and others) necessary to prepare the ecosystem for adopting automatic encryption in federated environments. Autocrypt is one of the core examples of such community-based efforts, now collaborating with K9, Enigmail, Mailpile and other important MUAs and service providers. Conversations (with its underlying OMEMO protocol) is another federated project that undertakes important community-oriented efforts to move the secure messaging ecosystem forward. These efforts are recognised across projects: Elijah Sparrow, the leader of LEAP, remarked in our interview with him that ‘the guy who wrote Conversations… he has
done a lot to adapt XMPP, wrote a good demonstration client, and encouraged
the servers to support this set. It's a good example of other "can-be-changed"
protocols'.

Federation comes with challenges of ‘compatibility’, which we identify as
its ‘second C’. One of the practical examples of compatibility is the so-called
‘backwards compatibility’ that makes a harmonious transition from older to
more recent protocols possible, without blocking or boycotting ‘by design’
some of the clients. As seen previously, the field of end-to-end encrypted
instant messaging applications is highly competitive, with important tensions
happening among protocol and application developers, implementers and
open-source community activists. Due to the very nature of centralised and non-
interoperable encrypted IMs that ‘lock users’ (as Sparrow puts it) within a tool
with specific interfaces and sets of features, IMs compete for users. Email being
an open federated ecosystem, it is structured by a number of collaboration and
coordination efforts. However, these are not exempt from tensions and points
of controversy; besides the difference in the technical approaches of different
projects, such debates also involve the necessity to enrol an important number
of email app developers in order to implement and spread their solution and
being able to secure users.

Federated messaging solutions are currently taking shape as attempts to
solve several important challenges experienced by contemporary communica-
tion infrastructures: on the one hand, fragmentation of the web and lack of
interoperability, concentration of power and aggregation of data by centralised
applications and platforms, and on the other hand, the high sociotechnical entry
barrier into p2p networks, which necessitates greater expertise and responsibil-
ity from users and better performance of their devices.

This is where the ‘third C’, customisation, comes in. Federation offers users
the option of choosing among multiple service providers and migrating from
one server to another without losing their social graphs. The ‘bigger/better’
paradigm is thus questioned by federated messengers, whose business models
do not depend on the number of users or on collecting and aggregating their
data. In federated projects, users move beyond the role of ‘data workers’, in
the words of Spanish artist and media philosopher Manuel Beltran;²¹ smaller
user groups appear to be easier to manage, and federated architectures make it simpler to customise and localise implementations, adapting them to the needs of a specific user community without losing the ability to interact with broader networks (by developing bridges, bots or other means to ‘plug’ systems to each other). Federation offers space for creativity; small projects proliferate, challenging researchers who fail to document all the various implementations of a given protocol.

At the same time, implementations of a federated protocol are harder to control, and this may create compatibility problems and security vulnerabilities across different instances or clients. A successful development of federated communication tools therefore necessitates new forms of organisation and decision-making, which is especially challenging for loose, decentralised networks. Federated forms of project governance take shape through the variety of ways in which protocol documentation is laid out and improved; constant negotiations across involved actors; physical, often informal, gatherings and new efforts at standardisation. Working standardised or quasi-standardised protocols function as instruments of self-governance, communication and coordination among actors of federated networks – what Yochai Benkler (2006) has called ‘coordination without hierarchy’.

However, federation adds a layer of complexity in the governance of IMs as sociotechnical networks by introducing new key players, notably the system administrators, responsible for the maintenance and growth – the ‘care’ (Denis and Pontille 2015) – of federated infrastructures, our fourth and final ‘C’ of federation. The stability of federated ecosystems depends, as well, on the successful enrolment of maintainers, which requires the development of good documentation and guides with ‘best practices’, and the dissemination of technical expertise through offline educational events for future sysadmins.

In federated systems, ‘caring about the plumbing’ (Musiani 2012) is especially important and acquires an architecture-specific meaning, as no single entity can be counted on to maintain the system as a functioning one, but the necessity of care is distributed across the multiple sysadmins and other actors that manage the different instances in the federation. The growth of federated platforms marks a turn towards community-managed ‘safe spaces’, with more
power delegated to human moderators (administrators of email or XMPP servers in the case of Delta Chat or Jabber, or instances in the case of Matrix or Mastodon). This introduces new risks of the re-centralisation of power within federated networks (Raman et al. 2019), requiring more research on the role of infrastructure maintainers, administrators and moderators, besides the core-set of protocol designers.

Among the main challenges of federated messengers are spam and reputa-
tion systems, as well as the discoverability of contacts and content that becomes
harder without a centralised registry. On federated social networks like Mastodon
or Matrix, the absence of data aggregation and filtering algorithms is viewed
as beneficial for users’ privacy. However, it is considered by some researchers
as a challenge for wider user adoption, because it makes it harder for users to
discover relevant topics or find other users (Trienes et al. 2018). At the same
time, federated social networks are seen as a beacon of hope by those categories
of users whom we call ‘disinformation refugees’ – users who abandon central-
ised social networks, such as Twitter, because they are tired of disinformation
or hate speech.

At the end of this journey through architectural models in secure messaging and their impact on the configuration – social and economic as well as technical – of encrypted messaging tools, we now turn to examine the ways in which actors in the field have attempted to make sense of the ‘mess of messengers’ through initiatives of categorisation and classification. In a field at this level of maturity, these initiatives contribute to shaping and defining what constitutes ‘good’ privacy and security, and what constitutes a well-performing ‘concealing for freedom’ tool.

NOTES

<footnote n="1">1 https://joinmastodon.org.</footnote>

<footnote n="2">2 https://pleroma.social.</footnote>

<footnote n="3">3 https://www.chapsterhood.com/2019/03/09/decentralize-or-perish.</footnote>

<footnote n="4">4 See, for example, the recent important hack of Matrix.org's default server (https://matrix.org/blog/2019/04/11/we-have-discovered-and-addressed-a-security-breach-updated-2019-04-12).</footnote>
5 In the federated messaging space, we distinguish two main approaches, that we can call ‘protocol innovation’ and ‘protocol upcycling’. Even if innovative protocols are built on existing libraries and standards, they tend to narrow interoperability, while ‘upcycling’ means developing systems that can be reachable via older protocols.

6 See the protocol history section in the Introduction.

7 ChatSecure, and its core developer, have a similar profile and history.

8 https://github.com/signalapp/libsignal-protocol-c.

9 For example, during our observations of Autocrypt usability tests at 33c3 in December 2016.

10 https://omemo.top.

11 The actual bot is called Jabbergram; similar bots now exist that bridge Telegram to IRC and Matrix.

12 https://matrix.org/blog/2018/04/26/matrix-and-riot-confirmed-as-the-basis-for-frances-secure-instant-messenger-app.

13 The harshest critique of Matrix.org actually comes from within the XMPP community, downplaying Matrix.org's innovative aspect and considering that they 'reinvent the wheel'.

14 https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix.

15 Autocrypt project background: https://autocrypt.org/background.html.

16 Countermitm: https://buildmedia.readthedocs.org/media/pdf/countermitm/latest/countermitm.pdf.

17 https://leap.se/en/about-us/vision.

18 Ibid.

19 However, the project also works on new protocols, such as SOLEDAD and BONIFIED.

20 The name of the collective was never explicitly mentioned, for security reasons.

21 https://www.youtube.com/watch?v=TtvYipmFoBg.
WHAT IS ‘GOOD’ SECURITY?
CATEGORISING AND
EVALUATING ENCRYPTED
MESSAGING TOOLS

CLASSIFICATIONS AND CATEGORISATIONS ARE, TO PUT IT IN BOWKER and Star's (1999) words, 'powerful technologies', whose architecture is simultaneously informatic and moral and can become relatively invisible as they progressively stabilise, while at the same time not losing their power. Thus, categorisation systems should be acknowledged as a significant site of political, ethical and cultural work. Building upon the variety of different architectural and interface formats that we examined in the previous chapters, this chapter examines how this 'work' by actions of categorisation and classification happens in the field of encrypted messaging tools.¹ We examine, as a case study, one of the most prominent and emblematic initiatives in this regard: the Electronic Frontier Foundation's 2014 release of the Secure Messaging Scorecard. A particular focus is on the debates it sparked, and its subsequent re-evaluation and evolutions. We show how the different versions of the SMS, as they move from an approach centred on the tools and their technical features to one that gives priority to users and their contexts of use, actively participate in the co-shaping of specific definitions of privacy, security and encryption that put users at the core of the categorisation system and entrust them with new responsibilities, while at the same time, ultimately warning users that 'we can't give you a recommendation' (Cardozo, Gebhart and Portnoy 2018). We also show how this shift corresponds to an evolving political economy of the secure messaging
field: instead of a model of ‘one app to rule them all’, new approaches emerge, such as those mentioned in Chapter 4, that embrace the freedom of users to choose from or use simultaneously a multitude of apps, according to their social graphs and contexts.

## THE EFF SECURE MESSAGING SCORECARD: THE SHAPING OF A ‘COMMUNITY OF PRACTICE’ THROUGH CATEGORISATION

For the Electronic Frontier Foundation (EFF), a digital rights group based in San Francisco, the question of what the most secure and usable tools are, in today’s diverse and crowded landscape of messaging systems, has been at the core of their advocacy work for several years. Their most prominent initiative in this regard has been the 2014 release of the Secure Messaging Scorecard (SMS),² a seven-criteria evaluation of ‘usable security’ in messaging systems.

While the 2014 version of the SMS (1.0) displayed a number of apparently straightforward criteria – including, but not limited to, encryption of data in transit, ability to verify contacts’ identities, available documentation for security design assessment, and whether a code audit has happened in the recent past – our research shows that the selection and formulation of these criteria has been anything but linear.³ This was made particularly evident by the EFF’s 2016 move to update the SMS. Acknowledging that ‘Though all of those criteria are necessary for a tool to be secure, they can’t guarantee it; security is hard, and some aspects of it are hard to measure’, the foundation proceeded to announce that this was why it was working on ‘a new, updated, more nuanced format for the Secure Messaging Guide’.⁴

Indeed, in a digital world where, as Chapter 2 has shown, the words security and privacy are constantly mobilised with several different meanings – even within the same debates and by a priori alike actors, and even more so when profiles of needs and adversaries vary – it seems relevant, so as to shed light on yet another facet of the making of encryption, to take SMS’s first release as a case study. We can see its subsequent discussions and renegotiations as processes that destabilise, negotiate and possibly restabilise particular definitions of
security, of defence against surveillance and of privacy protection. This chapter
intends to show that initiatives such as the SMS and the negotiations around
the categories that are meaningful to qualify and define encryption are in fact
contributing to shape what makes a ‘good’ secure messaging application and
what constitutes a ‘good’ measurement system for assessing (usable) security,
able to take into account all the relevant aspects – not only technical but also
social and economic. In addition to the fieldwork and interviews that are the
basis for previous chapters of this book, the present chapter particularly relies
on three in-depth interviews with current or past EFF personnel, conducted in
November and December 2016. These are the person in charge of the first SMS
(R1), the coordinator of the second SMS (R2) and the trainer and coordinator
of the EFF Surveillance Self-Defense Guide (R3).

As Geoffrey Bowker and Susan Leigh Star remind us in their seminal work
*Sorting Things Out* (1999), issues such as the origin of categorisation and clas-
sification systems, and the ways in which they shape the boundaries of the
communities that use them, have been an important preoccupation for the
social sciences in the last century. STS scholars in particular have explored these
systems as tools that co-shape the environments or the infrastructures they seek
to categorise and have addressed their particular status as both a ‘thing and an
action’, having simultaneous material and symbolic dimensions (Bowker and
Star 1999: 285–286). As this chapter will show, the EFF’s attempt to define an
appropriate categorisation system for assessing the quality of secure messaging
tools is indeed simultaneously a thing and an action, co-shaping the world it
seeks to organise.

From an STS perspective, classification and categorisation processes are
strictly linked to the shared perception different actors are able to have of them-
selves as belonging to a community. In many cases, these processes highlight the
boundaries that exist between communities and constitute the terrain where
they might either move closer or drift further apart:

Information technologies used to communicate across the boundaries of
disparate communities [...] These systems are always heterogeneous. Their
ecology encompasses the formal and the informal, and the arrangements
that are made to meet the needs of heterogeneous communities—some cooperative and some coercive (Bowker and Star 1999: 286).

Categorisation processes, as Goodwin (1996: 65) reminds us, are meant to
‘establish [...] an orientation towards the world’, to construct shared meanings
within larger organisational systems.

Borrowing from Cole (1996: 117), Bowker and Star point out that the
categories produced by such processes are both conceptual (as they are
resources for organising abstractions, returning patterns of action and change)
and material (because they are inscribed, affixed to material artifacts). The
act of using any kind of representation, from schematisation through to sim-
plification, is a complex achievement, an ‘everyday, [yet] impossible action’
(Bowker and Star 1999: 294) that is, nevertheless, necessary to become part
of a ‘community of practice’ (Lave and Wenger 1991), or in Becker’s words,
a set of relations among people doing things together (Becker 1986). The
community structure is constituted by ‘routines’ and ‘exceptions’ as identified
by the categorisation system – the more the shared meaning of this system is
stabilised among the members of the community, the more the community
itself is stabilised as such:

Membership in a community of practice has as its sine qua non an increasing familiarity with the categories that apply to all of these. As the familiarity deepens, so does one's perception of the object as strange or of the category itself as something new and different (Bowker and Star 1999: 294).

We will see how, in the highly unstable environment of the EFF's initial attempt
to categorise secure messaging tools with a view to providing guidance on their
quality, the embryo of a community of practice started to emerge. At the same
time, it went beyond – and revealed the manifold points of friction between –
the relatively homogeneous group of cryptography developers, to include users
of different expertise, trainers, civil liberties and ‘Internet freedom’ activists.

Classifications and categorisations, despite their embeddedness in working
infrastructures and consequent relative invisibility, should be investigated as a
significant site of political, ethical and cultural work (Bowker and Star ibid.: 319) – three aspects that our analysis of the SMS negotiations will unfold. In these three respects, categories are performative (Callon 2009): the reality of the everyday practices they subtend reveals that, far from being ‘enshrined [...] in procedures and stabilized conventional principles that one merely needs to follow in order to succeed’ (Denis 2006: 12, our translation), they actively participate in the construction of the relation between the different actors that have a stake, or a role, in the categorised environment; categories, from this perspective, are one of the components of a complex network of actors and technologies.

## THE SECURE MESSAGING SCORECARD 1.0 AND THE UNVEILING OF ‘ACTUAL SECURITY’

In November 2014, the EFF released its Secure Messaging Scorecard. The SMS was announced as the first step of an awareness campaign aimed at both companies and users – a tool that, while abstaining from formal endorsement of particular products, aimed to provide guidance and reliable indications that ‘projects (we)re on the right track’, in an increasingly complex landscape of self-labelled ‘secure messaging products’, in providing ‘actual [...] security’.⁵ According to R1, ‘We tried to hit both audiences, we wanted to provide information for users and we also wanted to encourage tools to adopt more encryption to do things like release source code or undergo an audit’.

### Overcoming the security vs usability trade-off

The EFF closely linked the SMS initiative to the Snowden revelations, mentioning that while privacy and security experts had repeatedly called on the public to adopt widespread encryption in recent years, Snowden’s whistleblowing on governments’ ‘grabbing up [of] communications transmitted in the clear’ has made widespread routine adoption of encrypting tools a matter of pressing urgency. R1 suggests that the need for such a tool came out of a need expressed by the general public:
It kind of came out of conversations at EFF [...we] got a lot of queries with people asking which messaging tools they should use. So there have been a couple of projects in the past, like the guide 'Who has your back', a project that is a sort of scorecard of Terms of Service and how companies handle data, that's where the idea came from... try to use the same approach to put information out there that we thought was useful about different messaging tools. (R1)

In the EFF's view, adoption of encryption to such a wide extent 'boils down to two things: **security and usability**'. It is necessary that both things go hand in hand, while in most instances, the EFF observes a trade-off between the two:

## Secure Messaging Scorecard

<table><caption>FIG. 5.1 The Secure Messaging Scorecard, version 1.0.</caption><thead><tr><th></th><th>Encrypted in transit?</th><th>Encrypted so the provider can't read it?</th><th>Can you verify contacts' identities?</th><th>Are past comms secure if your keys are stolen?</th><th>Is the code open to independent review?</th><th>Is security design properly documented?</th><th>Has there been any recent code audit?</th></tr></thead><tbody><tr><td>AIM</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td></tr><tr><td>BlackBerry Messenger</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td></tr><tr><td>BlackBerry Protected</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td></tr><tr><td>ChatSecure + Orbot</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td></tr><tr><td>Ebuddy XMS</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td></tr><tr><td>Facebook chat</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td><td>✔</td></tr></tbody></table>
Most of the tools that are easy for the general public to use don't rely on security best practices - including end-to-end encryption and open source code. Messaging tools that are really secure often aren't easy to use; everyday users may have trouble installing the technology, verifying its authenticity, setting up an account, or may accidentally use it in ways that expose their communications (R1).

Citing collaborations with notable civil liberties organisations such as ProPublica and the Princeton University research Center on Information and Technology Policy, the EFF presents the SMS 1.0 as an examination of dozens of messaging technologies 'with a large user base - and thus a great deal of sensitive user communication - in addition to smaller companies that are pioneering advanced security practices', implicitly involving both established and emerging actors, with arguably very different levels of security and usability, in the effort. The visual appearance of the SMS is presented in Figure 5.1: a simple table listing specific tools vertically and the seven classification criteria horizontally. These are the following:⁶

1. Is your communication encrypted in transit?

2. Is your communication encrypted with a key the provider doesn't have access to?

3. Can you independently verify your correspondent's identity?

4. Are past communications secure if your keys are stolen?

5. Is the code open to independent review?

6. Is the crypto design well-documented?

7. Has there been an independent security audit?

The table includes intuitive symbology and colours to account for the presence or the lack of a requirement, and a filter giving the possibility of displaying only specific tools or getting a bird's-eye-alphabetised-view of all the examined tools.

Thus, as we can see, the political and 'quasi-philosophical' rationale behind the SMS was clearly presented. It is interesting to acknowledge, in this context, that the 'Methodology' section in the presentation page was very matter of fact.
It presented the final result of the categorisation and criteria selection process, but EFF provides very little information on the thought processes and negotiations that led to the selection. The page states, 'Here are the criteria we looked at in assessing the security of various communication tools', and proceeds to list them and the definitions used for the purpose of the exercise.

Yet, as researchers exploring the social and communicational dimensions of encryption from an STS perspective, we hypothesised that selecting and singling out these categories had been anything but linear, and that the backstage of these choices was important to explore – not merely to assess the effectiveness of the SMS, but also as a way of exploring the particular definition of encryption and security the EFF was inherently promoting at it was pushing the project forward. Indeed, it seemed to us that by fostering the SMS project, and due to its central role as an actor in the preservation of civil liberties on the Internet, the EFF was not merely acknowledging and trying to accumulate information about a 'state of things' in the field of encryption and security; rather, it was contributing to shaping the field, with the categories chosen to define 'actual' or 'usable' security being a very important part of co-producing it.

## An ongoing reflection on the ‘making of’ the criteria

While the SMS's main presentation page focused on the criteria in their final form, there were some indications of the EFF's ongoing reflections on the 'making of' such criteria, and of their online presence. A post in early November 2014 by chief computer scientist Peter Eckersley, 'What Makes a Good Security Audit?', acknowledged that the foundation had 'gotten a lot of questions about the auditing column in the Scorecard' (Eckersley, 2014). Eckersley proceeded to explain that obtaining knowledge about how security software had been reviewed for 'structural design problems and is being continuously audited for bugs and vulnerabilities in the code' was deemed as an essential requirement, but it was also recognised that the quality and effectiveness of audits themselves could vary greatly and have significant security implications. This in turn, he suggested, opened up discussions that eventually led to the inclusion of three separate categories accounting for the process of code review (regular and
external audits, publication of detailed design document and publication of
source code) (Eckersley, 2014). Despite the fact that methodologies for code
audit vary, Eckersley gave examples of fundamental vulnerabilities that a ‘good
code audit’ may decrease. The code audit criteria thus refer to other systems of
classifications, such as the CVE (Common Vulnerabilities and Exposures), an
international standard for Informational Security Vulnerability names.⁷ Other
‘Notes’ attached to some of the criteria are indicative of backstage negotiations,
as they mention ‘compromises’ both on forward secrecy (encryption with
ephemeral keys, routinely and permanently deleted after the communication,
a ‘hybrid’ version of which is accepted ‘for this phase of the campaign’) and on
the source code’s openness to independent review (‘only require[d] for the tool
and not for the entire OS’).⁸

In parallel, musings on the SMS came from several actors in the encryption/
security community at large. Some criticised the lack of hierarchy among the
criteria, the phrasing of some of them and even the messaging tools’ alphabetical
ranking.⁹ Others conducted alternative reviews of tools included in the SMS and
questioned their quality, despite the fact that they had been scored positively
on the EFF grid (Hodson and Jones 2016). Yet others concluded that the EFF
was being ‘pushed to rethink’ the SMS (Zorz 2016). Indeed, relying on these
documentary sources, it seems that reflections within the EFF on the quality of
the SMS categories and their possible alternatives and evolutions, and, on the
other, more or less constructive external criticisms of these same aspects, took
place in parallel and paved the way for a subsequent version of the tool – all the
while shaping ‘good’ security and ‘good’ encryption, as well as how users and
developers could grasp what this meant.

In early August 2016, these reflections seemed to have reached a turning point
as the EFF ‘archived’ its SMS main page, labelling it a ‘Version 1.0’, and announced
it would be back in the near future with a new, improved and ‘more nuanced’
guide to encryption tools, explicitly referencing the ongoing revisions that had
characterised and were still characterising their categorisation work: ‘Though
all of those criteria are necessary for a tool to be secure, they can’t guarantee it;
security is hard, and some aspects of it are hard to measure’ (Figure 5.2).¹⁰ It
also anticipated that the term ‘scorecard’ would be dropped in favour of ‘guide’.
<figure><img src="image_18.png" /></figure>

CHECK BACK SOON: NEW SECURE MESSAGING GUIDE ON
THE WAY!

In the face of widespread Internet surveillance, we need a
secure and practical means of talking to each other from our
phones and computers. Many companies offer "secure
messaging" products—but are these systems actually secure?
We decided to find out, in the first phase of the EFF Campaign
for Secure & Usable Crypto.

Version 1.0 of our scorecard evaluated apps and tools based on a set of seven specific criteria ranging from whether messages were encrypted in transit to whether or not the code had been recently audited. Though all of those criteria are necessary for a tool to be secure, they can't guarantee it; security is hard, and some aspects of it are hard to measure. That's why we're working on a new, updated, more

<caption>FIG. 5.2 Secure Messaging Scorecard main page between August 2016 and its withdrawal in 2018 (https://www.eff.org/secure-messaging-scorecard).</caption>

What did the first SMS do? Performativity and performance of a categorisation tool

And thus, Version 1.0 of the SMS was no more, except in the form of an archive
preserved ‘for purely historical reasons’ of which the EFF itself discourages
further use.¹¹ Nonetheless, our interviews with EFF members and with security
trainers in several European countries – as well as the fact that the EFF decided
to leave the SMS visible to the public while putting it in context – demonstrate
that the first SMS *did* a lot of things to and for the encryption and security
community, and contributed to shaping the field itself.

Indeed, the first SMS appears to have had a performative effect on the com-
munity: the EFF has a central role as a protector of online civil liberties and
setting up a scorecard in this field was a pioneering effort in its own right. In
an otherwise mostly critical discussion thread among tech-savvy users,¹² it was
recognised as such ('The EFF scoreboard carries the embryo idea of a global
crypto discussion, review, comparison and knowledge site that could also serve
as a great resource for non-crypto people and students to learn a lot about that field'), and most interestingly, it led the encryption technical community to be reflexive about itself and its own practices.

There were a number of reasons for this reflexivity. The first was because a ‘hybrid’ organisation – EFF includes some technical people but also individuals with a number of other profiles – spearheaded this effort (‘Isn’t it a bit strange that a small organisation of non-computer scientists produce something that was painfully missing for at least 50 years?’). The second was because it prompted reflection on parallel categorisation efforts that may better respond to what the technical community sees as ‘good security’. As one contributor put it:

> The highly valued information you and other experts are dropping [...] should be visible in a place that collects all that stuff and allows for open discussion of these things in the public, so people can learn to decide what security means for them. If such a thing exists, please show me. If not, please build it.

Indeed, by its very creation, the SMS caused a reaction in the developer community, making them wonder whether a categorisation effort of this kind was worthwhile, including the EFF’s particular efforts. Despite the flaws they saw in the scorecard, developers seemed to perceive EFF as a sort of standardising or trend-setting body; they knew that many users would rely on the SMS if they perceived it to be the advice of EFF, in part thanks to some of the other initiatives aimed at bridging technical soundness and user-friendliness, such as the ‘crypto usability’ prize.¹³

Interestingly, and despite the EFF’s announced intentions, we can retrace some early ambiguity and perhaps confusion about the SMS’s intended target audience. The simplicity and linearity of the grid, the symbols used, the way categories were presented – each of these aspects could indeed lead the encryption technical community to think that it was aimed at both developers and users (confirmed earlier by R1, as well), and perhaps primarily at users. However, there are other indications that it might have been the other way around – in which the
primary target would be fostering good security practices among a wide number of developer teams, with usability being a subsequent target. According to R2,

what motivated us to make the scorecard, is to survey the landscape of secure messaging and to show developers: ‘look that’s what we think is important. So you should use all these things to make a truly secure tool’, and then we can get to the usability part.

And later, even more clearly:

> Originally the target of the SMS was not users, telling users ‘you should use Signal or you should use something else’. [...] It was... we were trying to make a grid so that developers could see ‘ok I need to get this and this to check all the boxes’. But it backfired....

So, it appears that one of the core things the SMS did was to prompt practices by end users that to some extent escaped the EFF team’s intentions and control: intended as an indicative checklist for developers, the SMS actually assumed the shape of an instruction tool for users and cryptography trainers – a ‘stabilised’ and defining artefact, when in fact it was anything but.

Ultimately, and despite the EFF’s warnings,¹⁴ developers appeared worried that the SMS and its set of criteria would appear to guidance-seeking users as a performance standard that tools should achieve in order to qualify as ‘good encryption’. Take, for instance, this comment by ‘tptacek’ on Hacker News:

> Software security is a new field, cryptographic software security is an even newer field, and mainstream cryptographic messaging software is newer still. The problem with this flawed list is that it in effect makes endorsements. It’s better to have no criteria at all than a set that makes dangerously broken endorsements.¹⁵

This concern is echoed by EFF, with R2 pointing out during our interview how the organisation became worried about the SMS’s use as an endorsement, or a