Concealing for Freedom

Ksenia Ermoshina, Francesca Musiani

► To cite this version:

Ksenia Ermoshina, Francesca Musiani. Concealing for Freedom: The Making of Encryption, Secure Messaging and Digital Liberties. Mattering Press, 2022, 10.28938/9781912729227. halshs-03649984

HAL Id: halshs-03649984

https://shs.hal.science/halshs-03649984

Submitted on 23 Apr 2022

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
<figure><img src="image_2.png" /></figure>
MATTERING PRESS

Mattering Press is an academic-led Open Access publisher that operates on a not-for-profit basis as a UK registered charity. It is committed to developing new publishing models that can widen the constituency of academic knowledge and provide authors with significant levels of support and feedback. All books are available to download for free or to purchase as hard copies. More at matteringpress.org.

The Press' work has been supported by: Centre for Invention and Social Process (Goldsmiths, University of London), European Association for the Study of Science and Technology, Hybrid Publishing Lab, infostreams, Institute for Social Futures (Lancaster University), OpenAIRE, Open Humanities Press, and Tetragon, as well as many other institutions and individuals that have supported individual book projects, both financially and in kind.

We are indebted to the ScholarLed community of Open Access, scholar-led publishers for their companionship and extend a special thanks to the Directory of Open Access Books and Project MUSE for cataloguing our titles.
## MAKING THIS BOOK

Books contain multitudes. Mattering Press is keen to render more visible the unseen processes that go into the production of books. We would like to thank Joe Deville, who acted as the Press' coordinating editor for this book, the two reviewers Andrew Clement and Maxigas, Steven Lovatt for the copy editing, Jennifer Tomomitsu for the proof reading and work on the book production, Alex Billington and Tetragon for the typesetting, and Will Roscoe, Ed Akerboom, and infostreams for their contributions to the html versions of this book.

## COVER

Cover art by Julien McHardy.
CONCEALING FOR
FREEDOM

*The Making of Encryption, Secure Messaging and Digital Liberties*

KSENIA ERMOSHINA
FRANCESCA MUSIANI

foreword by
LAURA DENARDIS
First edition published by Mattering Press, Manchester.

Copyright © Ksenia Ermoshina and Francesca Musiani, 2022.

Foreword © Laura DeNardis, 2022.

Cover art © Julien McHardy, 2022.

Freely available online at matteringpress.org/books/concealing-for-freedom

This is an open access book, with the text and cover art licensed under Creative Commons By Attribution Non-Commercial Share Alike license. Under this license, authors allow anyone to download, reuse, reprint, modify, distribute, and/or copy their work so long as the material is not used for commercial purposes and the authors and source are cited and resulting derivative works are licensed under the same or similar license. No permission is required from the authors or the publisher. Statutory fair use and other rights are in no way affected by the above.

Read more about the license at creativecommons.org/licenses/by-nc-sa/4.0/

<figure><img src="image_3.png" /></figure>

<figure><img src="image_4.png" /></figure>

<figure><img src="image_5.png" /></figure>

<figure><img src="image_6.png" /></figure>

ISBN: 978-1-912729-22-7 (ppk)

ISBN: 978-1-912729-23-4 (pdf)

ISBN: 978-1-912729-24-1 (epub)

ISBN: 978-1-912729-25-8 (html)

DOI: doi.org/10.28938/9781912729227

Mattering Press has made every effort to contact copyright holders and will be glad to rectify, in
future editions, any errors or omissions brought to our notice.
# CONTENTS

List of figures 7

Authors 9

Foreword: The political life of encryption by Laura DeNardis 11

Preface: A note for readers 15

Acknowledgments 21

List of abbreviations and acronyms 27

0 · Introduction 31

1 · Concealing from whom? Threat modelling and risk as a relational concept 66

2 · Centralised architectures as informal standards for ‘control by design’ 89

3 · Peer-to-peer encryption and decentralised governance: A not-so-obvious pair 120

4 · Federation: Treading the line between technical compromise and ideological choice 148

5 · What is ‘good’ security? Categorising and evaluating encrypted messaging tools 183

6 · Conclusions: Encrypted communications as a site of social, political and technical controversy 210

Bibliography 241

Appendix: Interview selection process and ethical guidelines 257

Glossary 261
<figure><img src="image_7.png" /></figure>
LIST OF FIGURES

<table><tr><td>FIG. 1.1</td><td>Digital security training observed in Kyiv, January 2017</td><td>72</td></tr><tr><td>FIG. 1.2</td><td>User representation of ‘insecure communications’</td><td>76</td></tr><tr><td>FIG. 1.3</td><td>User representation of ‘secure communications’</td><td>77</td></tr><tr><td>FIG. 1.4</td><td>Drawing collected during the interview on February 16, 2017</td><td>83</td></tr><tr><td>FIG. 3.1</td><td>A vision of ‘safer Internet’.</td><td>123</td></tr><tr><td>FIG. 3.2</td><td>Adding a remote contact on Briar</td><td>141</td></tr><tr><td>FIG. 5.1</td><td>The Secure Messaging Scorecard, version 1.0</td><td>188</td></tr><tr><td>FIG. 5.2</td><td>Secure Messaging Scorecard main page between August 2016 and its withdrawal in 2018</td><td>192</td></tr><tr><td>FIG. 5.3</td><td>Sample of ‘user paths’ on the SSD home page as of early 2017</td><td>202</td></tr></table>
<figure><img src="image_8.png" /></figure>
AUTHORS

KSENIA ERMOSHINA and FRANCESCA MUSIANI are tenured researchers at the French National Centre for Scientific Research (CNRS). They are based at the Centre for Internet and Society, which Francesca co-founded and co-directs. From 2016 to 2018, Ksenia and Francesca worked within the H2020 project NEXTLEAP (NEXT-generation techno-social and Legal Encryption, Access and Privacy). Their research explores Internet infrastructures and architectures as tools of governance (and resistance) in today's digital world.

LAURA DENARDIS is a globally recognised Internet governance scholar and Professor in the School of Communication at American University in Washington, DC, where she also serves as Faculty Director of the Internet Governance Lab. With a background in information engineering and a doctorate in science and technology studies, she has published seven books and numerous articles on the political implications of Internet architecture and governance.
<figure><img src="image_9.png" /></figure>
# FOREWORD

## THE POLITICAL LIFE OF ENCRYPTION

Laura DeNardis

WHAT HAPPENS IN CYBERSPACE NO LONGER STAYS IN CYBERSPACE. A ransomware attack on a fuel pipeline company leads to long lines at gas stations. A healthcare system data breach prevents people from receiving medical care. An infiltration into a home video security system leads to egregious violations of personal privacy. Foreign probing of digital voter rolls reduces trust in democracy. And security disruptions to cyber-physical industrial systems are also disruptions of our food supply, livelihoods and ability to function in daily life.

Being ‘offline’ is no longer a defence against the effects of any of these disruptions. People who have never even been on the Internet can be affected by, for example, a data breach of credit card information at their favourite retail store or be harmed by a security vulnerability in a telemedicine device. The complication of society’s digital dependencies, with all of its undoubtedly upsides, is that the security of everything in life now depends upon strong cybersecurity. Hence, cybersecurity is a great human rights issue of our time. Democracy, financial transactions, consumer safety and the stability of all industrial sectors now depend upon it just as much as personal privacy does.

Strong encryption solves many of these concerns. Yet those who have invented the numerous ingenious encryption protocols over recent decades sometimes express surprise that widely available and strong encryption is
not implemented everywhere in digital society. Is this merely because of the
cost or processing power required for strong encryption, or something more
complex?

Encryption is arguably the most politically charged of all Internet technolo-
gies. The ability of governments to apply encryption and break encryption has
been at the core of diplomatic strategies, foreign intelligence, law enforcement
and national security approaches for decades. The complication is that encryp-
tion – and especially encryption strength – is a site of contestation and tension
between competing values, even within a single government. National security
now requires strong cybersecurity around critical communication and industrial
systems, and the digital economy. But at the same time, governments also have
an interest in weak encryption for law enforcement and intelligence gathering
purposes. Law enforcement personnel sometimes call this the ‘going dark’ prob-
lem, where encrypted messaging and encrypted devices become inaccessible
for routine evidence gathering. The intelligence necessary for counter-terrorism
similarly depends upon the ability to access encrypted communications.

Societal requirements for strong encryption – for securing financial transac-
tions, defending infrastructure and protecting the right to privacy – are directly
opposed to the societal requirement that law enforcement and intelligence agen-
cies need access to encrypted information, or more authoritarian surveillance
approaches that monitor and control the lives of citizens. This same tension exists
between privacy and the invasive business models that rely upon personal data
gathering in exchange for customised online ads. Many of the largest technol-
ogy companies do not charge users for their services but they rank among the
highest revenue generating institutions on the planet by collecting the personal
data of users and converting this into revenue.

Responding to these tensions and the dynamic norms around the global
intersection of security, privacy and social control, different governments have
established diverse regulatory approaches to encryption technologies, rang-
ing from banning some outright, to restricting exports to certain countries, to
requiring licenses to use them. Because of the political stakes of encryption, it
is not surprising that cryptography has sometimes been regulated under the
same statutes as firearms and munitions.
In short, cryptography occupies a powerful place in modern society. It is a highly politicised lever of power balancing trust in the economy and democracy, national security, human safety, individual privacy, and law enforcement and intelligence gathering functions.

Considering the stakes, there has not been sufficient examination of encryption and secure messaging as a central lever of infrastructure politics. *Concealing for Freedom* is a much-needed book that cracks open the black box of encrypted secure messaging and discusses the consequences for freedom and online civil liberties. Secure messaging and tools are not just born when implemented into products or regulated by governments. They are created by design communities. And they are shaped by designers who make technical decisions that consider risk, threat models, business models, sociopolitical context and technical constraints. Decentralised versus centralised? Localisation versus globalisation? Anonymous or pseudonymous approaches? What counts as ‘good’ or ‘desirable’ security? The standardisation process itself, and design decisions about arrangements of architecture, are also arrangements of power.

Fundamental human rights such as personal privacy and free speech, and the right to trust in digital infrastructures and economies, are shaped by communication protocols. The tension in protocol design between security and privacy has a long history, but it came to the fore after American government contractor Edward Snowden's disclosures about the massive extent of National Security Agency (NSA) surveillance. Internet protocol designers immediately called for ‘hardening the Internet’ with more extensive end-to-end encryption. The Internet Engineering Task Force (IETF) published consensus documents suggesting that indiscriminate surveillance of either content or metadata was an assault on individual privacy that should prompt stronger encryption choices that make such surveillance either less possible or more expensive. These designers acknowledged both the importance of individual privacy and also the need to restore trust in the Internet. This wasn’t the first-time protocol designers would push back against government surveillance.

The political and social stakes around encryption continue to rise as government and corporate surveillance approaches alike become more sophisticated, but also as new technologies emerge. As the Internet has leapt from two
dimensional digital screens to the three-dimensional objects all around us – the Internet of Things – so the consequences for privacy and national security have become starker. There is also well-founded speculation about how rapid advancements in quantum computing power may intersect with encryption technologies, possibly cracking historically entrenched cryptography.

Considering the political pressure and the momentum of invasive and powerful emerging technologies, society may already be at a tipping point. We must design a world in which privacy and security are still possible.
PREFACE

A NOTE FOR READERS

THIS BOOK TELLS STORIES ABOUT ONLINE LIBERTIES SHAPED BY TECHNICAL architectures and infrastructures. It originates from a three-year research project called NEXTLEAP (nextleap.eu, NEXT-generation Techno-Social and Legal Encryption, Access and Privacy, funded by the European Commission in the frame of the H2020 Collective Awareness Platforms (CAPS) programme). The purpose of NEXTLEAP, which ran from 2016 to 2018, was to 'create, validate, and deploy communication and computation protocols that can serve as pillars for a secure, trust-worthy, annotable and privacy-respecting Internet¹ that ensures citizens' fundamental rights'²: as such, it was an interdisciplinary project at its core. Its consortium included computer scientists and social scientists working in close dialogue with one another in an attempt to build a protocol that 'actually works'. The project was founded in the immediate aftermath of the Snowden revelations, which made technical work surrounding encryption much more of a political issue than it had been in the past, even the fairly recent past, and showed the extent to which sociopolitical factors are crucial in assessing the worth of specific communication technologies vis-à-vis issues such as privacy protection and surveillance. Our role within the project, in close dialogue with technical partners, was to conduct an extensive sociological investigation of technical development processes and user adoption in the field of encrypted secure messaging.

Reflecting this interdisciplinary background, the book is somewhat of a hybrid object, as the research it is based upon was produced with different
(albeit entwined) objectives, including to inform the very practical technical
discussions among the project developers, to fuel interdisciplinary work in
collaboration with computer scientists and to advance a science and technol-
ogy studies (STS)- and sociology of innovation-oriented understanding of
phenomena such as encryption and distributed architectures. We therefore
thought it might be helpful to provide readers with some guidance about how
to engage with the book, which might depend on their interests, backgrounds
or even reading styles. Moreover, in order for the book to be as accessible as
possible, a glossary has been included at the end of the book that provides defini-
tions for the technical terms we use.³ While some of these terms are especially
crucial in the discourses and practices of developers, and as such will (also) be
unpack ed as the chapters unfold, we believe that a glossary can be useful as a
general resource. We also provide a comprehensive list that explains the many
abbreviations and acronyms that characterise this field. This is located before the
book's Introduction. The book does not have an index, but as an Open Access
text, e-book versions are freely available to download, so users can search for
particular terms that interest them.

During our fieldwork we had the opportunity to meet and talk with
many professionals, ranging from cryptographers to user experience and
user interface (UI/UX) designers, trainers and users, who mentioned in
our discussions (both recorded and off the record) the protocols and tools
we focus on here. Moreover, as we continue to be engaged within the field
of cryptographic tools and protocols ourselves, as usability researchers, we
have been exposed to many ongoing debates in the community around such
tools and protocols, and their implications for the field of encryption in
secure messaging. This social science research, deeply embedded among
technologists, and ultimately improving technology, is in our view one of
the stand-out features of this book.

The book has two distinct but interrelated aims: first, to provide what we call
an ‘analytical portrait’ of the state of the art of the highly complex and techni-
cal secure messaging field. While the field is changing rapidly and is becoming
more of a matter of interest for the general public, it is in our view important to
capture the details of how the different technologies and social practices that
compose this field emerged, interact and currently operate. In this sense, one
of the book's key contributions is to provide something akin to an analytical
history of the present, creating a new record of a phenomenon that, even as it
continues to develop, is changing the terrain of digital social life in myriad major
ways. To make an analytical portrait, as we understand it, means to retrace the
development of an artefact – in particular, moments of crises, debates, contro-
versies – to try and understand the ‘life’ of a few selected encrypted messaging
applications, from their creation to their appropriation and reconfigurations
by users, to their becoming, in some instances, a subject of public debate, of
governance and of lobbying.

The second, related aim is to conceptualise this phenomenon via tools and
approaches that have been developed in the social sciences, with a particular
focus on bringing to the field of secure messaging insights from STS. Indeed,
encryption, the making of secure messaging tools that adopt it as its core princi-
ple, and the co-shaping of particular definitions of digital ‘freedom’, can be read
through the lenses of questions and issues that have long been of concern to
STS. These range from the effects of competing imaginaries and visions on the
day-to-day enactment of technical innovation, to the performative effects that
processes of categorisation and ‘sorting things out’ have on the structuration
of a field. Writing with these issues in mind implies engaging in close dialogue
with the established STS literature on socio-technical controversies, infra-
structure- and architecture- embedded governance and the political value of
‘mundane practices’. While the style of writing used when engaging with these
questions may be unfamiliar to those outside the discipline, the intention is to
advance the conceptualisation of encryption as an intimately ‘socio-technical’
phenomenon, a foremost example of why, today, digital communication tech-
nologies are controversial and contested, why they are both a target and tool
of governance, and why they have assumed a fundamental place in the exercise
of authority and power.

The book begins – in the introductory Chapter 0 and Chapter 1 – by intro-
ducing how a social science perspective can inform the understanding of very
broad technical questions, such as encryption and decentralisation; it then
progressively narrows its focus to issues specific to secure communications,
such as the relationality of risk and the meaning of elaborating a threat model. In Chapters 2, 3 and 4 the book shifts to provide distinct analytical portraits of the field. It presents several case studies of secure messaging projects, including a real-time history of innovations in the making. The book then gradually shifts back in Chapters 5 and 6 to a more explicitly social science- and STS-informed mode of analysis, by examining issues such as sense-making and categorisation attempts in this field, and the implications of the ‘making of’ Internet freedoms via secure messaging for Internet governance.

As such, the different chapters in this book may ‘matter’ in different ways to different readers. Readers expecting higher levels of conceptualisation, drawing from STS traditions and the literature of technology and innovation in society, may be more immediately familiar with Chapters 0, 1 and 5, where notions such as ‘translation’ in an actor-network theory sense, Bowker and Star’s ‘sorting things out’, as well as more recent STS-inspired notions of data justice and data activism are fundamental tools to analyse the fieldwork. However, these chapters should not be neglected by readers from more technical backgrounds, since they bring to light the relational and highly socially embedded nature of some tools that help users in their great diversity ‘make sense’ of the tools technologists build.

Admittedly, however, technologists will probably feel more at home in Chapters 2, 3 and 4, which focus more on technical analyses of the case studies and on how the technical architecture of different projects co-shapes development choices and user practices. Nevertheless, we would emphasise again that insights from STS inform these chapters in more ways than may appear at first sight. Indeed, by unveiling phenomena such as informal standardisation processes, controversies around different implementations of a particular protocol and trade-offs between usability and technical efficiency, the concepts and methods of STS are both inextricably entwined in shaping our perspectives and embedded in our writing.

While this book is likely to be of primary interest to the readerships described above, we hope that it may spark interest in wider readerships, including those categories of actors that have been so kind as to participate in our fieldwork – developers, activists, journalists, and, last but not least, users. For these groups of readers, we are hopeful that this book may prompt, or, perhaps more modestly,
fuel, a series of ‘taking stock’ discussions on their practices with and around
privacy-protecting communication tools. We also hope that regulators may
find reasons to take pause and reflect upon our analysis. This is likely to happen
most prominently in the concluding chapter, which is not simply the sum of the
conclusions arrived at in previous chapters but a substantive discussion of, and
overture towards, several pressing Internet governance issues of our time as they
relate to the security of communications. This book has the not-so-concealed
objective of being useful to these publics, at a time when encryption is as much,
or ever more, a pressing societal concern as a technical one.

The field of encrypted messaging does not stand still. As we write this note, in
November 2020 and in the context of a pandemic-driven increase in surveillance,
we can observe new contributions that explore the links between civil liberties
and encryption, such as UNICEF's working paper on children, encryption and
privacy⁴, alongside new threats to encryption, such as a resolution proposed by
the Council of the European Union that controversially calls for a discussion
of how to 'better balance' the two principles of 'security through encryption
and security despite encryption'.⁵ Such cases provide reminders – and there
will certainly be more by the time this book is published – of the need for a
technically-informed social and political analysis of what encrypted commu-
nications are 'made of', and of the definitions of freedom they co-produce. We
hope that this book will be a lasting contribution towards this goal, and we look
forward to it joining the debate.

NOTES

¹ This introductory note is perhaps the best place to highlight the difference between the ‘Internet’ and the ‘Web’, although the two terms are all too often used interchangeably in day-to-day discourse. The Internet is the global system of interconnected computer networks that use a ‘common language’ – namely the Internet protocol suite – to communicate with one another. The Web, or World Wide Web (WWW), is a particular set of applications that is built on top of the Internet, one of the most widely used by end users (along with, e.g. file sharing and e-mail applications).
2 http://nextleap.eu.

3 Every time the first instance of a term included in the glossary occurs, it is highlighted in bold.

4 https://www.unicef-irc.org/publications/1152-encryption-privacy-and-childrens-right-to-protection-from-harm.html.

5 https://techcrunch.com/2020/11/09/whats-all-this-about-europe-wanting-crypto-backdoors.
ACKNOWLEDGMENTS

WHEN FINISHING A BOOK, THE TIME OF ACKNOWLEDGMENTS IS A PLEASURE
and, to some extent, a surprise. It is at this moment that authors realise to what
extent ‘their own’ work is actually the product of a collective endeavour – formal
and informal interactions, moments of feedback and challenge, asking for
help and taking stock, thanking and being grateful. To all the individuals and
organisations listed below – and those we may have omitted by mistake – we
are, indeed, deeply indebted for making this book what it is.

First of all, a heartfelt thank you to Mattering Press for taking this book pro-
ject on board at the end of 2018, in a time-sensitive situation, and for following
it carefully and benevolently ever since. Mattering is a wonderful experiment
in researcher-led-and-owned, open publishing that we feel honoured to be a
part of. Francesca had been hoping that a book project suitable for submission
to MP would come along since she shared the ‘keynote spotlight’ with Julien
McHardy at the 2014 meeting of the Spanish STS network (redCTS), and first
heard about the promising nascent Press. She could not be happier that, seven
years later, this ‘declaration of intentions’ which she made in a corner of her
mind has come to fruition.

At Mattering Press, we wish to especially thank Joe Deville for the count-
less, kind and patient hours of work on both the content and form of our
book – despite the multiple disruptions in personal and professional lives
that the Covid-19 pandemic has caused since early 2020. Thank you so
much, Joe.

We wish to thank the team of the H2020 NEXTLEAP project: Jaya Klara
Brekke, George Danezis, Giacomo Gilmozzi, Marios Isaakides, Nadim Kobeissi,
Wouter Lueks, Vincent Puig, Carmela Troncoso and all the other colleagues
who joined the team for shorter periods of time but whose contributions to the project were crucial for its success. A special thanks to NEXTLEAP coordinator Harry Halpin, who first suggested back in 2014 that we should embark on a project on decentralised architectures together and has been a stimulating colleague and co-author throughout the project. A very special thanks to Holger Krekel, head of Merlinus GmbH and lead developer of Delta Chat; we are grateful for numerous insightful and kind conversations during the project, and beyond, on the informatics and philosophy of federation, and for his support of our work. We remember fondly Bernard Stiegler, who prematurely left us on 5 August 2020. His insights permeate the project and its practical and academic outputs.

We also wish to thank the European Commission for funding the NEXTLEAP project via its innovative programme ‘Collective Awareness Platforms for Sustainability and Social Innovation’ (CAPS). Year after year, CAPS-funded projects have produced very stimulating work on sustainability and citizenship in the digital age, and we hope that this book is another ‘brick in the wall’ in this regard. Thank you to Fabrizio Sestini and Loretta Anania, EC Project Officers at DG CONNECT, for their attentive and kind spearheading of the project. We are also grateful to Francesca Bria, Maurizio De Cecco and Stefania Milan, who kindly reviewed our work at different stages.

Our heartfelt thanks also go to Laura DeNardis, who graciously agreed to dedicate some time from her extremely busy schedule as Dean of American University's School of Communication – and as one of the world's foremost Internet governance scholars – to write the preface for the book. Her words mean so much to us, as they position our book as a valuable contribution to the academic enterprise that analyses technical infrastructures and architectures as arrangements of power, and they stress the importance of encryption as a core Internet governance controversy of our times.

As this book was developing, a project of a different kind saw the light – the Centre for Internet and Society of CNRS, which Francesca co-founded, and which has been the ‘professional home’ for us both since January 2019. Thank you to the colleagues who started the adventure of this new research unit with us, this book would not be the same without our ongoing interactions and
conversations: CIS co-founder and director Mélanie Dulong de Rosnay, Olivier Alexandre, Maria Castaldo, Jean-Marc Galan, Axel Meunier, Tommaso Venturini and Céline Vaslin. We also wish to acknowledge the interactions with colleagues of the *Groupement de recherche Internet, IA et Société*, that constitutes a vital dimension of CIS. Let us mention here, in particular, colleagues and friends Séverine Arsène, Anne Bellon, Romain Badouard, Lucien Castex, Marida Di Crosta, Clément Mabi, Cécile Méadel, Julien Rossi, Félix Tréguer, Valérie Schafer and Guillaume Sire. We are also indebted to our former research unit, the Institute for Communication Sciences (ISCC) of CNRS, and its director, Pascal Griset, who for three years provided a comfortable and stimulating working environment for the NEXTLEAP project.

Our ability to continue our work on the NEXTLEAP-born investigation on encrypted secure messaging, and on its outputs including this book, was greatly boosted by obtaining funding for a closely related project, *ResisTIC – The Net Resistants: Critique and Circumvention of Digital Coercion in Russia*. Our thanks go to the French national funding body, the Agence Nationale de la Recherche (that also previously funded Francesca’s first substantial research project on decentralised architectures, ADAM, a predecessor to NEXTLEAP). We are also grateful to the ResisTIC team: Olga Bronnikova, Françoise Daucé, Fabrice Demarthon, Valéry Kossov, Benjamin Loveluck, Bella Ostromooukhova, Perrine Poupin and Anna Zaytseva, for the fruitful scientific exchanges and friendly conversations in the frame of the project and its seminars.

Over the years, a number of colleagues worldwide, beyond those already cited above, gave feedback on either the book proposal, on papers that eventually formed the basis of chapters or on draft chapters. Thank you, Sylvain Besençon, Nathalie Casemajor, Andrew Clement, Philip Di Salvo, Maxigas, Liudmila Sivetc, Sophie Toupin. Special acknowledgements go to Angela Sasse and Ruba Abu-Salma from UCL, who initiated us into usable security and kindly agreed to discuss our work at a very early stage.

During the writing of the book, Ksenia spent a year and a half at the Citizen Lab (University of Toronto, Canada) as a postdoctoral researcher, and wishes to thank its director Ronald Deibert as well as Masashi Crete-Nishihata, Jakob Dalek, John Scott-Railton, Bahr Abdul Razzak, Miles Kenyon, Lotus Ruan,
Adam Senft and all the team. We both wish to acknowledge the Centre for the Sociology of Innovation of MINES ParisTech, where we conducted our PhD theses in a wonderfully stimulating environment and Francesca still holds an associate researcher appointment. Francesca also wishes to thank the editorial team of the *Internet Policy Review*, as well as the Internet Governance Lab of American University, to which she owes a fruitful collaboration with Laura DeNardis, Derrick Cogburn and Nanette Levinson.

More broadly, our work was enriched by a number of academic communities of which we are members. Our thanks go to the International Conferences on Internet Science (INSCI), the Society for the Social Studies of Science (4S) and the European Association for the Study of Science and Technology (EASST), the Association of Internet Researchers (AoIR), the Global Internet Governance Academic Network (GigaNet), The Center for Science and Technology Studies of the European University at Saint-Petersburg, and last but not least, the International Association for Media and Communication Research (IAMCR). Within IAMCR, we wish to acknowledge our joint work with Aphra Kerr, Julia Pohle, Jeremy Shtern and Weiyu Zhang, who co-chair(ed) with Francesca the Communication Policy and Technology Section, and Sylvia Blake, Sibo Chen and Steph Hill, who co-chair(ed) with Ksenia the Emerging Scholars Network.

We write about technical issues that are deeply political, and we hope that our work can be useful to policy. In this regard, being able to interact closely with institutions and NGOs is invaluable. Francesca wishes to thank the French Parliament's Commission for Rights and Liberties in the Digital Age, the CSAlab and the Internet Society France for having engaged with the project and for involving her in their multi-stakeholder reflections on how to make the Internet more open, transparent and usable.

Last but not least, we wish to thank all the activist tech communities that have trusted us, assented to talk to us and assisted in arranging interviews with the most marginalised, at-risk user groups. A very special thanks goes to the Digital Security Lab Ukraine (namely Mykola Kostynyan, Vadym Hudyma, Iryna Chulivska, Maksim Lunochkin and others), Syster Servers collective, Campi Aperti project, Autistici, Riseup, Tails and Espiv. Very warm thanks to dkg, Samba, Vassilis and Spider Alex.
We could not finish these acknowledgments before thanking with all our
hearts our families, for their love and support through thick and thin (as the
first year of the Covid-19 pandemic concludes, this sentence stands for a whole
lot of nuances). Chiara, Jean-Marc, Brune, Loïse, Marco, Patrizia, Carlo, Elena,
Oksana, Sasha, Svetlana, Lerie and Timofey: this book is for you.
<figure><img src="image_10.png" /></figure>
LIST OF ABBREVIATIONS
AND ACRONYMS

A separate glossary of technical definitions is also included at the end of the book.

CAPS Collective Awareness Platforms

CEO Chief Executive Officer

CIA Central Intelligence Agency (United States of America)

CNNum Conseil national du numérique (French Digital Council)

CTO Chief Technology Officer

DNS Domain Name System

DRM Digital Rights Management

e2e End-to-end

ECMA European Computer Manufacturers Association

EDRi European Digital Rights (organisation)

EFF Electronic Frontier Foundation

ENISA European Union Agency for Cybersecurity
(maintained original acronym)

ETSI European Telecommunications Standards Institute

EU European Union

FBI Federal Bureau of Investigation (United States of America)

FOSS or F/OSS Free and Open-Source Software

FSB Federal Security Service (Russian Federation)

GIF Graphics Interchange Format

GitHub and GitLab Platforms for collaboration between developers

GAIM (now Pidgin) F/OSS Instant Messaging client

GCM Google Cloud Messaging

GDPR General Data Protection Regulation

GNU/Linux Free software operating system
<table><tr><td>GPG (GnuPG) GNU</td><td>Privacy Guard (free-software replacement for PGP)</td></tr><tr><td>GPL</td><td>General Public License</td></tr><tr><td>HADOPI</td><td>Haute Autorité pour la Diffusion des Œuvres et la Protection des droits d'auteur sur Internet</td></tr><tr><td>HTML</td><td>HyperText Markup Language</td></tr><tr><td>I2P</td><td>Invisible Internet Project</td></tr><tr><td>IANA</td><td>Internet Assigned Numbers Authority</td></tr><tr><td>ICANN</td><td>Internet Corporation for Assigned Names and Numbers</td></tr><tr><td>ICTs</td><td>information and Communication Technologies</td></tr><tr><td>ID</td><td>Identifier</td></tr><tr><td>IETF</td><td>Internet Engineering Task Force</td></tr><tr><td>IG</td><td>Internet Governance</td></tr><tr><td>IM</td><td>Instant Messaging</td></tr><tr><td>IMAP</td><td>Internet Message Access Protocol</td></tr><tr><td>iOS</td><td>Mobile operating system developed by Apple, Inc.</td></tr><tr><td>IP</td><td>Internet Protocol</td></tr><tr><td>IRC</td><td>Internet Relay Chat</td></tr><tr><td>IRL</td><td>In Real Life</td></tr><tr><td>IRTF</td><td>Internet Research Task Force</td></tr><tr><td>ISO</td><td>International Standardization Organization</td></tr><tr><td>ISP</td><td>Internet Service Provider</td></tr><tr><td>ITU</td><td>International Telecommunications Union</td></tr><tr><td>LEAP</td><td>Encryption access project</td></tr><tr><td>MENA</td><td>Middle East and North Africa (region)</td></tr><tr><td>MIT</td><td>Massachusetts Institute of Technology</td></tr><tr><td>MTS</td><td>Telephone company, Russian Federation</td></tr><tr><td>MUAs</td><td>Mail User Agents</td></tr><tr><td>NEXTLEAP</td><td>NEXT-generation Techno-Social and Legal Encryption, Access and Privacy (H2020 project)</td></tr><tr><td>NIST</td><td>National Institute of Standards and Technology (United States of America)</td></tr><tr><td>NGO</td><td>Non-Governmental Organisation</td></tr><tr><td>NSA</td><td>National Security Agency (United States of America)</td></tr></table>
<table><tr><td>OMEMO</td><td>Multi-End Message and Object Encryption (recursive acronym)</td></tr><tr><td>OpenPGP</td><td>Open implementation of PGP</td></tr><tr><td>Opsec</td><td>Operational Security</td></tr><tr><td>OTR</td><td>Off-the-Record Messaging (see Glossary)</td></tr><tr><td>OWS</td><td>Open Whisper Systems</td></tr><tr><td>PGP</td><td>Pretty Good Privacy (see Glossary)</td></tr><tr><td>p2p</td><td>Peer-to-peer (system; see Glossary)</td></tr><tr><td>PRISM</td><td>Code name for NSA surveillance program begun in 2007</td></tr><tr><td>QR-code</td><td>Quick Response code</td></tr><tr><td>RfC</td><td>Request for Comments (IETF)</td></tr><tr><td>RightsCon</td><td>Summit on Human Rights in the digital age</td></tr><tr><td>RSA</td><td>Public-key encryption technology developed by RSA Data Security, Inc.</td></tr><tr><td>SD</td><td>Secure Digital</td></tr><tr><td>S/MIME</td><td>Secure/Multipurpose Internet Mail Extensions (cryptography norm)</td></tr><tr><td>SMS</td><td>Secure Messaging Scorecard</td></tr><tr><td>SMTP</td><td>Simple Mail Transfer Protocol</td></tr><tr><td>SNI</td><td>Server Name Indication</td></tr><tr><td>STS</td><td>Science and Technology Studies</td></tr><tr><td>TCP/IP</td><td>Transmission Control Protocol/Internet Protocol</td></tr><tr><td>TLS</td><td>Transport Layer Security</td></tr><tr><td>Tor or TOR</td><td>The Onion Router</td></tr><tr><td>UC</td><td>University of California</td></tr><tr><td>UDHR</td><td>Universal Declaration of Human Rights</td></tr><tr><td>UI/UX</td><td>User Experience and User Interface</td></tr><tr><td>UN</td><td>United Nations</td></tr><tr><td>UNICEF</td><td>United Nations International Children's Emergency Fund</td></tr><tr><td>USA</td><td>United States of America</td></tr><tr><td>USB</td><td>Universal Serial Bus (industry standard)</td></tr><tr><td>VPN</td><td>Virtual Private Network</td></tr><tr><td>W3C</td><td>World Wide Web Consortium</td></tr><tr><td>XMPP</td><td>Extensible Message and Presence Protocol</td></tr><tr><td>XML</td><td>Extensible Markup Language</td></tr></table>
<figure><img src="image_11.png" /></figure>
# INTRODUCTION

(F)or a time, I operated part of the US National Security Agency's global system of mass surveillance. In June 2013 I worked with journalists to reveal that system to a scandalised world. Without encryption I could not have written the story of how it all happened [...] and got the manuscript safely across borders that I myself can't cross (Snowden 2019a).

THUS WROTE EDWARD SNOWDEN, THE FORMER NSA CONTRACTOR TURNED into the world's most famous whistleblower for digital liberties, on 15 October 2019, shortly after the damning history of his revelations, and the process that led to them, was published under the title *Permanent Record* (Snowden 2019a, 2019b). According to Snowden, the current debates around encryption have fundamental implications for our individual liberties and collective presence on the Internet and attempts to undermine encryption amount to no less than making Internet users 'vulnerable by design'. Encryption has become one of the core battlegrounds of Internet governance.

Indeed, as can hardly be disputed anymore, Snowden's 2013 revelations have been a landmark event in the development of the field of secure communications. Encryption of communications on a large scale and in a usable manner has become a matter of public concern, with a new cryptographic imaginary taking hold, one which sees encryption as a necessary precondition for the formation of networked publics (Myers West 2018). Alongside turning encryption into a fully-fledged political issue, the Snowden revelations catalysed longstanding debates within the field of secure messaging **protocols**. The cryptography community (in particular, academic and free software collectives) renewed their efforts to create next-generation secure messaging protocols in order to
overcome the limits of existing protocols, such as **PGP** (Pretty Good Privacy) and **OTR** (Off-the-Record Messaging). Protocols are a vital part of the Internet's functioning, providing its conceptual models as well as the set of specifications that explain how data should be regrouped into packets, addressed, transmitted, routed and received; as Laura DeNardis made clear in *Protocol Politics*, the selection and adoption of particular protocols carries important political and economic implications, as well as technical ones (DeNardis 2009).

With recent events such as the introduction of **end-to-end encryption** in WhatsApp, the most popular instant messaging platform, billions of users started protecting their communications by default and on an everyday basis, often without realising it. While the mantra 'I have nothing to hide' is still widespread among Internet users, interest in ways to secure and preserve online communications with means such as encryption is increasing, and this has important socio-technical consequences. While these consequences apply particularly to those whose lives depend on an accurate appreciation of the risks related to their own profession or political context, they are also ever more relevant to the 'ordinary citizen'.

In response to the increasingly widespread understanding of security in online communications as an important social and political issue, as well as a technical one, encrypted secure messaging is a vibrant field in the making. Developers remain in flux about how to implement security and privacy properties – despite a number of novel projects seeing the light – while users have not yet converged on a single application. For example, there is still debate about cryptographic properties such as **forward and future secrecy**, **group messaging** and **non-repudiation**. Furthermore, there is no clear standard to adopt for these properties. In terms of privacy, work is still immature; even the most popular secure messaging applications, such as Signal, expose users' metadata via the requirement to associate users with their phone number or, in the case of Wire, leak **social graphs** via a centralised contact book.

For all these reasons, next-generation secure messaging appears unstandardised and fragmented, leading to a state where secure messaging users exist in dozens of 'silos', unable to inter-operate (Sparrow and Halpin 2015). The 'silo effect' is considered among the most important obstacles to the adoption of secure messaging apps:
The common trend of creating new secure communication tools and assess-
ing the usability of these tools is a significant obstacle to adoption due to
creating fragmented user bases. Also, to reach their communication partners,
participants needed to use tools that are interoperable (Abu-Salma et al.
2017a: 137).

This is in stark contrast to the model used for email, where any email service
can openly communicate with another in a federated fashion, agreeing upon
collective standards of operation. Thus, developers of modern secure messag-
ing protocols are facing a number of trade-offs between various design issues,
including security and privacy properties, the introduction of group support
features, the degree of decentralisation of the application, standardisation
attempts and choices related to the licenses under which they release their
software. In the meantime, vibrant discussions are happening around adapting
open federated protocols (e.g. XMPP) to integrate the most recent security
features.¹ New initiatives, based on decentralised, federated or **peer-to-peer**
protocols are emerging, yet still suffer from a number of limitations related to
usability and scalability.

All these dynamics are relevant to this book’s examination of developers’
actions and their interactions with other stakeholders (users, security trainers,
standardising bodies and funding organisations, for instance) and with the tech-
nical artefacts they develop, with a core common objective of creating tools that
‘conceal for freedom’ while differing in their intended technical architectures,
their targeted user publics and their underlying values and business models.

As next-generation encryption is shaping the ways in which we can securely
communicate, exchange and store content on the Internet, it is important to
unveil the very recent, and sometimes less recent history of these protocols and
their key applications, to understand how the opportunities and constraints
they provide to Internet users came about, and how both developer communi-
ties and institutions are working towards making them available for the largest
possible audience. Efforts towards this goal are built upon interwoven stories
of technical development, of architectural choices, of community-building and
of Internet governance and politics. This book is about these stories – exploring
the *experience* of encryption in the variety of secure messaging protocols and tools existing today, and the implications of these endeavours for the ‘*making of*’ civil liberties on the Internet.

This book intends to provide two main empirical and theoretical contribu-
tions: firstly, it seeks to enrich a social sciences-informed understanding of
encryption, including examining how its different solutions are created, devel-
oped, enacted and governed, and what this diverse experience of encryption,
operating across many different sites, means for online civil liberties; secondly,
it wishes to contribute to the understanding of the social and political implica-
tions of particular design choices when it comes to the technical architecture
of digital networks, in particular their degree of (de-)centralisation.²

The first part of this introduction will discuss both of these perspectives. A
second part will introduce our case studies, our methodology and approach to
our fieldwork. In its final section, in order to facilitate navigation through the
following chapters, we situate our case studies in a genealogy of the fundamental
protocols in the encrypted messaging field, and we introduce relevant concepts
and definitions that will be used in the following chapters, such as end-to-end
encryption, centralisation, federation and peer-to-peer/decentralisation.

FOR A SOCIAL SCIENCES PERSPECTIVE ON ENCRYPTION

For quite a long time, ‘encryption’ as a research subject has mostly been the
prerogative of computer scientists, with more ‘social’ issues concerning it often
being confined to debates about usable security (i.e. discussions taking place
within the computer scientist community, and based on survey-type studies
that aim to find ways of making encrypted tools easier to use). As, since the
Snowden revelations, encrypted communications and the goals of privacy
and security they seek to enhance are becoming a matter of widespread public
debate, it is important that the social sciences take up the challenge of investi-
gating in depth how encrypted messaging tools are conceived and developed,
how they are taken up by different user profiles – sometimes in unintended or
unforeseen ways – how they inspire and are inspired by different imaginaries,
and how they eventually become the target of governance. With this volume,
and the three-year investigation it is based upon, we seek to contribute what is,
to our knowledge, the first book-length endeavour focused on this subject that is
grounded primarily in science and technology studies (STS) and more specifi-
cally in the sociology of innovation processes and technical development. First
and foremost, our work exists in dialogue with contributions that have recently
sought to apply some central concepts in the social sciences, in particular STS,
to the study of encryption.

Encryption is a matter of competing imaginaries and of the visions, designs
and implementations they co-shape, as Sarah Myers West has recently argued
(2018). People think about encryption through cyphers (that transpose let-
ters of an alphabet), and through codes (that replace words) in different social,
cultural and political contexts. As Myers West notes, encryption has built its
different meanings in the realm of national security and secrecy and in that of
democratic systems, in each of which it enables private communication and
makes it possible to avoid surveillance and potential social or political sanc-
tions. Myers West's STS-driven investigation into encryption imaginaries is
especially resonant with our research, as it illustrates how similar technologies
may acquire different meanings and roles in different cultural settings. A par-
ticularly important insight is that these technologies should be understood not
only in a technical sense but in the specific social, cultural and political contexts
in which they are used. Myers West's conclusions are important to emphasise,
as this book will provide numerous examples of how technologies (and tech-
nologists) do not determine universal solutions when it comes to the role and
impact of encryption, with sociocultural contexts of use being paramount. The
historical dimension of these sociocultural contexts and their evolution over
time should also be taken into account, as Isadora Hellegren points out in her
work – grounded in both discourse theory and an STS sensibility – that sees
discourse as a contextual, structuring and performative process of meaning-
making (Hellegren 2017). The multifaceted meaning of encryption evolves
not only across communities of developers and users, but also across time, and
understanding how various actors have constructed specific understandings of
freedom with regard to technologies like encryption is significant to Internet
historians, hackers, programmers and policymakers, as all of these actors are
involved in constructing the form, function and meaning of Internet freedom,
in particular when it comes to its relation to the state.

Encryption, and the debates around it, are the result of multiple public
spheres and expert circles, embedded in broader Internet-and-society ques-
tions such as the control of networked media, surveillance and the protection
of personal data. Linda Monsees' recent *Crypto-Politics* (2019) is an important
contribution to the study of these aspects and more broadly to the development
of a social sciences perspective on encryption, even if her primary focus is not the
*making* of encryption for a specific use, but rather discourses on encryption as a
whole as they unfold in traditional and less traditional political arenas. Monsees
uses discourse analysis methods to examine post-Snowden debates related to
encryption in both the United States and Germany and describes the landscape
of media and specialist discussions as trying to make sense of today's 'diffuse
security' – a context where 'security practices disperse multiple insecurities and
threat images' (Monsees 2019: 5). Monsees develops the notion of 'publicness'
to convey the idea that political controversies on encryption are often located
outside established political institutions (although those that unfold in more
traditional political arenas should not be neglected). In a way reminiscent of
previous work on the performative role of controversies revolving around
complex and open-ended sociotechnical phenomena, she concludes, echoing
Hellegren, that 'encryption controversies entail specific ideas relating not only
to what 'security' means but also how these conceptions rely on specific ideas
about citizenship, statehood and privacy' (Monsees 2019: 10).

Beyond the dialogue with this nascent social science scholarship on encryp-
tion, our work further seeks to build on, and contribute to, the research of several
scholars at the crossroads of media studies, sociology of technology and com-
puter science. They have brought their conceptual and methodological lenses
to the study of networked communication technologies and their implications
for privacy, security and Internet governance.

The technical development of applications and protocols, and the set of
choices involved in this development, critically contributes to making sense
of what digital freedoms are, how they should be preserved and who are their
adversaries. Anthropologist Gabriella Coleman has paved the way for scholars
seeking to explore these questions. In particular, she has examined the role
of hacker culture,³ exploring what hackers mean by freedom and how they
enact it as a form of self-determination that considers unrestricted access to
knowledge a necessary precondition for the evolution of their 'technical art'
(Coleman 2005). Furthermore, Coleman's work is of particular relevance for a
social sciences-based study of encryption. Together with Alex Golub, Coleman
has defined 'crypto-freedom' as a particular form of hacker practice, grounded
in an understanding of freedom that positions the state as the main adversary
in the battle for online privacy. This practice is derived from the particular his-
torical and cultural context of liberalism in the United States and grounded in
the belief that this freedom should primarily be preserved and fostered on the
Internet through the development and use of encryption technology (Coleman
and Golub 2008).

Since the Snowden revelations, several authors have tackled the question of
what it means to be online as an individual, a citizen and a consumer in a world
that is now broadly aware of the extent to which we are being surveilled. Within
this realm, they have focused on the issue of the role played by the technical
development of the architectures and infrastructures of online communication.

As explored by the work of Stefania Milan and colleagues (e.g. Milan and
van der Velden 2018), we are bearing witness to an increasing variety of ‘data
activism’ practices – a set of socio-technical tactics, resistances and mobilisa-
tions that adopt a critical approach towards datafication, mass data collection
and pervasive surveillance. Data activism, as Milan conceptualises it, can be
understood as a contemporary evolution of phenomena such as those analysed
by Coleman (as well as Milan herself in previous works, e.g. 2013), like radical
tech activism and hacktivism. Data activism is meant to represent the ‘next
step’ in these forms of activism. It is both designed for the digital and shaped
by the digital, inasmuch as it ‘explicitly engages with the new forms (that)
information and knowledge take today as well as their modes of production,
challenging dominant understandings of datafication’ (Milan and van der Velden
2018). Interestingly, the proponents of the concept point out that, given that
datafication and the uses of ICTs for different political purposes are so wide-
spread and pervasive, data activism might progressively acquire an appeal for
more diverse communities of concerned citizens. This might extend beyond previous forms of tech activist engagement that seemed (self-)restricted to a niche of experts and technologists (ibid. 2018). Broadening the frame of, and interest in, tech activism is a widely discussed concern in a number of the most recent encryption projects, including some we will analyse more closely as this book unfolds.

Also relevant to our research, and key to understanding several of the dynamics described in the following chapters, is work that explores what it means to be a ‘digital citizen’ of the post-Snowden Internet. The conceptual lens of ‘data justice’ has been proposed by Arne Hintz, Lina Dencik and Karin Wahl-Jorgensen (2019) to illustrate that not only is citizenship and the possibility of citizen agency in today’s Internet profoundly shaped by phenomena such as massive data collection and commodification, but also that user rights and practices concerning online privacy and surveillance are today conceived of in highly individualised terms. According to these authors, these individualising dynamics engender or at least maintain a context of inequality, as they transfer the responsibility to ‘engage and negotiate citizenship in a digital age onto individuals’ (Gangneux 2019).

As our case studies will illustrate, this issue is important in relation to encryption technologies and their mass adoption because the target audience of secure messaging applications either born or substantially developed post-Snowden is far from being limited to tech-savvy and activist groups: several projects are aimed at widespread use. This is a major change in the field, as for a long time, a majority of the technical crypto community considered that greater user-friendliness and usability could realise in practice their desire for large-scale adoption, while simultaneously considering ease of use and comfort a secondary issue to the soundness of the technology. Scholars have previously suggested that the comparatively little attention given to this issue by developers implies a ‘forced responsibilisation’ of users, as it places all the burden of ‘getting up to speed’ on them: it is up to users to acquire the competencies to compensate for the technical artefact’s lack of usability. It has been further argued that this is to the detriment of the development of resilient collective digital security strategies (Kazansky 2015) and that it ‘delegates’ technical matters to ‘progressive
techies' despite a widespread societal desire to develop technologies for social justice (Aouragh et al. 2015).

Finally, we have found a particularly useful set of concepts within STS-focused studies of Internet governance (see e.g. Epstein, Katzenbach and Musiani 2016). Complementary to the predominantly institutional approaches that set the agenda for Internet Governance (IG) research in its early days – and which remain one of its preeminent features – STS approaches invite a consideration of the agency of technology designers, policymakers and users as they interact, in a distributed fashion, with technologies, rules and regulations. These, in turn, lead to consequences with systemic effects that may, at times, be unintended. Following these approaches, social and political ordering is understood as a set of ongoing and contested processes, which translates into a growing attention to the mundane practices of all those involved in providing and maintaining, hacking and undermining, developing and testing, or merely using the network of networks (Musiani 2015). Conceptually, STS-informed IG research relies on understanding governance as a normative ‘system of systems’ and it acknowledges the agency, often discrete yet pervasive, of both human and non-human actors and infrastructures. Particular attention is paid to the processes by which norms – technical or otherwise – are created, negotiated, put to the test and re-aligned, and also how they raise conflicts. These processes are understood to be as important as the stabilised norms themselves, if not more so. These are conceptual contributions that will be particularly relevant in the central chapters of the book, where we introduce the variety of architectural models that different projects choose to adopt initially and which they subsequently have to ‘tinker with’ due to factors including early user adoption, changes in the developers’ teams and efforts to find suitable business models.

STS also provides crucial conceptual resources to enable the understanding of encryption as a site of controversy and contestation, in particular with the notion of sociotechnical controversy. On the one hand, since the very early days of the Internet, being on and managing the network of networks has been about exercising control over particular functions that provide specific actors with the power and opportunity to act to their advantage. On the other hand, there is very rarely a single way to implement these functions or a single actor
capable of controlling them. Thus, the Internet is controversial and contested, both a target and an instrument of governance, and the object of interest of a myriad of actors: from the most powerful and centralised to the ‘simple’ Internet user (Epstein, Katzenbach and Musiani 2016). Infrastructural and architectural arrangements, the development and implementation of particular protocols, can be understood as a fundamental place to exercise economic and political power, as we have examined elsewhere (e.g. DeNardis and Musiani 2016).

The Internet exhibits an increasing number of sites of contestation. These include the interconnection agreements between Internet service providers (Meier-Hahn 2015), the debate around net neutrality (Marsden 2017), the use of deep-packet-inspection (Mueller, Kuehn and Santoso 2012), the deployment of content filtering technologies (Deibert and Crete-Nishihata 2012), ubiquitous surveillance measures and the use of DNS for regulatory aims (DeNardis and Hackl 2015), prediction of people's online behaviours via algorithmic governance (Ziewitz 2016) and the shaping of the visibility and hierarchies of search engine results (Mager 2012). Furthermore, contentious politics, activism and citizen-led protest are often embedded in the Internet and its applications. This is illustrated, for example, by Milan and ten Oever's (2017) work on civil society engagement within ICANN (which operates the Internet's Domain Name System), aimed at 'encoding' human rights into Internet infrastructures. Another illustration is our previous research on the shaping and use of citizen- and activist-oriented mobile and Web applications, and how the design of these tools shapes citizen participation and citizen-state interaction (Ermoshina 2016). Among all these examples, encryption technologies for online communications are becoming one of the core sites of 'governance by architecture', rife with controversies that concern, in turn, the development of these technologies, their implementation, their (sometimes surprising) appropriation by users and the attempts to regulate them.

Interestingly in this regard, Snowden's disclosures of 2013, and the subsequent widening of mass-surveillance-related debates, not only revealed a need for further legal reform of intelligence and surveillance systems but have also highlighted 'a variety of changing practices, policies and discourses that can (...) be related to post-Snowden contentions' (Pohle and Van Audenhove
2017: 2–3). A number of sociotechnical controversies can be related to this. A notable example was the FBI vs Apple controversy that spanned 2015 and 2016, when Apple Inc. received several orders by district courts in the United States to assist ongoing criminal investigations by extracting data from iPhones with extensive cryptographic security protections. Apple itself could not break this encryption unless it wrote specific new software to enable authorities to bypass such barriers. This debate notably questioned whether – and if yes to what extent – judicial or governmental authorities could compel technical manufacturers to provide assistance in unlocking devices protected by encryption systems (see also Schulze 2017). Controversies such as this have contributed to unveil facets of the *experience* of encryption in today’s Internet and suggest that the most pressing issues of our time related to encryption may be not only legal and technical, but also social.

FOR A SOCIAL SCIENCES PERSPECTIVE ON
(DE-)CENTRALISATION

As previously mentioned, the second core empirical and theoretical contribution of this book is intended to be the understanding of the social and political implications of particular design choices when it comes to the technical architecture of digital networks, in particular their degree of decentralisation (or lack of it). This issue, which has permeated the debates of both scholars and practitioners of networked technologies since their early days, in fact goes even further back in time. Indeed, the struggle between centralised, profit-driven systems and decentralised, user-controlled, user-innovated architectures is one that appears in many infrastructures and has been a longstanding concern of sociologists and historians of technology (see e.g. Edwards et al. 2007). In the early days of the telephone, people living in rural areas sometimes put together their own phone networks using barbed-wire fences as transmission lines; they were shared, distributed resources (Fischer 1987). The grand battle between trucking and rail in the United States was a duel between huge centralised systems (the railways) and independent entrepreneurs, often individuals, who used trucks to offer point-to-point (rather than station-to-station) delivery, and ultimately won
by turning a publicly funded infrastructure (state and federal roads) towards a private purpose. Off-grid solar power installations as an alternative means of producing electricity outside standard circuits, and institutional resistance to these, are another case in point (Turner 2010). It is of little surprise, then, that the tension between different degrees of centralisation of technical architecture may also be found in the Internet, and in the different protocols and applications populating it – a tension that has been evident since its beginnings.

Indeed, in the history of Internet-based services, the concurrent push towards different types of design choice, in particular design based on peer-to-peer versus client/server architecture,⁴ has for quite some time been a source of compromises and tension – including social, technical, political, economic and legal tensions (see Musiani 2015b). In a client/server architecture, having information stored not on a user's machine but a separate server, possibly one managed by a third party, greatly complicates resistance to censorship because it provides an obvious control point (DeNardis 2014) for authorities. On the other hand, without such a server, communication between users who are not permanently digitally connected becomes much more difficult. This is why core Internet services such as email usually resort to intermediaries that are able to ensure the ongoing functioning of the service but can also potentially stop it, limit it, block it, and read what passes through the servers they depend on (on the liability of Internet intermediaries for these actions see Riordan 2016).

Efforts aimed at developing decentralised systems date back to the early Internet (Minar and Hedlund 2001). They were generally built as ad-hoc strategic responses to specific threats of shutdown. The file-sharing system BitTorrent, for example, was developed as a response to the shutdown of Napster, in order to make legal prosecution for breach of IP in file sharing networks much more complicated (Izal et al. 2004). Napster had a peer-to-peer component in file search but was in fact being run by a small group of people. This implied that the system was fully dependent on these individuals, technically as well as legally. As a consequence, such systems can be effectively neutralised by turning off servers or seizing the equipment or the people in charge of them (Ku 2016). In contrast, decentralised systems do not have any central servers, and the functioning of the system involves many peers (people, and the computing resources at their
disposal) who do not, or may not, even know each other. If any particular node
is unavailable to the system, it continues to run regardless. Thus, the logic behind
the creation of a decentralised system is usually to be resilient to targeting by
authorities, and such systems are accordingly often deemed by technical and
political actors in need of such resilience to be superior to proprietary, closed,
more centralised systems, because they value long-term robustness over cost-
effective commercial expedience (Oram 2001).

Decentralised systems have been subject to ‘waves’ of interest in the last
twenty years, starting with the early 2000s file sharing frenzy and the hailing of
peer-to-peer as a ‘disruptive technology’ (Oram 2001). In recent years there has
been an even greater interest in and uptake of decentralisation. In the process,
the motivations for adopting decentralised technologies have broadened from
a particular strategy of opposition to specific companies or pieces of regulation,
to proposals of an alternative ‘vision’ of what corporate, legal and state institu-
tions should be. Two main dynamics have driven this tendency: the first is the
emergence of blockchain technology (in particular with Bitcoin technology, as a
response to the 2008 financial crisis; see Campbell-Verduyn 2017 and Brunton
2019), and the second was spurred by Edward Snowden’s revelations of mass
surveillance operations facilitated by a number of telecommunications com-
panies and Silicon Valley giants, on behalf of the US National Security Agency
(see Pohle and Van Audenhove 2017). These events greatly raised the general
public’s awareness of the surveillance-based, and personal data-based, business
models of near-monopoly tech companies, and their ‘dangerous liaisons’ with
state security agencies (Musiani 2013).

As a consequence of these dynamics, ‘both decentralisation and the notion
of authority took on broader meaning and decentralisation became a techni-
cal, political, economic and social aim in and of itself, reaching outside the
‘hacker’ circles of the early p2p systems’ (Brekke & Isakiidis 2019). However,
this larger appreciation of decentralisation as a principle and a vision is not
devoid of side effects; most notably, often decentralisation has become an
objective in and of itself, with little understanding of intent or assessment
of actual effects. As information studies scholar and Internet pioneer Philip
Agre said in 2003, ‘architecture is politics, but should not be understood as a
substitute for politics'; decentralised protocols are too readily assumed, because
of their technical qualities, to bring about decentralised political, social and
economic outcomes. By choosing to structure the central part of this book
around the different degrees of centralisation of the technical architecture
for the examined secure messaging systems, we intend to take Agre's lesson
seriously, and assess in detail the extent to which economic, social, legal (and
last but not least technical) factors complicate the picture of a linear 'transla-
tion' from a peer-to-peer technical architecture into a successful decentralised
socioeconomic system, or from a centralised technical model to a top-down
sociopolitical structure.

CASE STUDY SELECTION

The core of this book is an in-depth understanding of three different end-to-
end encrypted mail and messaging applications. After a preliminary survey of
thirty cases of encrypted messaging applications,⁵ we proceeded to select a few
of them for more detailed study. These three applications were selected based
on their underlying protocols, and because of the relative accessibility of the
developer communities for interviews and observations. The three applications
originally selected were Signal (a centralised end-to-end encrypted instant
messaging application), LEAP/Pixelated (a federated end-to-end encrypted
asynchronous messaging protocol and client) and Briar (a peer-to-peer end-
to-end encrypted messaging application for resilient communication using
**network-layer protection**, such as Tor hidden services).

These three cases offered the possibility to address various research ques-
tions, such as the motivations behind:

- particular architectural choices (centralised, federated or peer-to-peer);

- specific choices of licensing, **UI/UX** design, relations between the underlying protocols and the application level;⁶

- solutions to privacy properties (such as metadata protection);

- design choices for group communication;
- various approaches to security properties (forward and future secrecy; **server-side archives**; **cryptographic deniability**; ephemeral or disappearing messaging).

However, when in September 2016 we started our fieldwork on the three selected projects, we quickly understood that these projects could hardly be treated as discrete given their connections with other initiatives in the field of encrypted messaging and email. In fact, the underlying protocols used by these three projects gave birth to a number of **client-side implementations**, forked or actively interacted with various applications in the field. Thus, we decided to ‘follow’ the three projects as they grew and transformed and use them as our ‘threads of Ariadne’, respecting the loops and knots that these threads were naturally forming on their way. During our fieldwork we had the opportunity to meet and talk with a large number of professionals, ranging from cryptographers to UI/UX designers, trainers and users, about the protocols and tools we focus on here (in discussions both recorded and off the record).

The research work subtending this book was and is thus an attempt to tell the complex story of protocols and communities, and eventually, to approach questions of governance of encryption protocols. Through a comparative analysis of centralised and decentralised protocols and their implementations, we address here several important and broader questions: What are the architectural patterns of successful centralised and decentralised systems? How do developers go about building scalable and high-performing privacy-preserving decentralised architectures? Can decentralisation help deliver privacy and anonymity? What are the motivations, values and characteristics of user communities that lead to the success or failure of certain (de-)centralised systems?

## A NOTE ON METHODOLOGY

Grounded in the different strands of literature from STS and the other disciplines we introduced above, our approach can be described as a multi-sited ethnography, inasmuch as we have undertaken research in, and between, several online and offline locations as part of our study, and we have also explicitly conceived
specific technical protocols and systems as ‘part of a larger context that exceeds the boundaries of the field site’ (Muir 2011: 1015; see also a reflection on the method by its first proponent, George Marcus, who points out that multi-sited ethnography has been ‘most creative, critical, and interesting where it has been involved with the [STS] study of distributed knowledge systems, (Marcus 2012: 27).

We analyse the development of the architectures and the interfaces of mes-
saging apps as ‘meeting points’ between the intentional goals of developers and
the needs of users (Oudshoorn and Pinch 2005), In doing so, we aim to provide
a fieldwork-driven explanation of emerging systems and communities of practice
through ‘analytical thick descriptions’ (for a recent treatment of the concept,
first introduced by anthropologist Clifford Geertz, see Ponterotto 2006) of
events, artefacts and organisations. In particular, we pay attention to moments
of crisis, debate and controversy – to try and understand the life of a technical
artefact, from its creation to its appropriation and reconfigurations by users, to
its becoming a subject of public debate, of governance, of lobbying. The primary
methodology to achieve this goal has been to observe, for relatively prolonged
periods of time, specific case-study groups or communities, while on the side
conducting in-depth interviews with their members and reading appropriate
documentation such as release notes and accounts of working sessions.

Just as we seek a nuanced understanding of developers’ motivations and the
representations they have of users and their needs, in the tradition of ‘user stud-
ies’ developed within STS (see Oudshoorn and Pinch 2005 or, in the French
tradition, Jouët 2000), we understand users not as a homogeneous and passive
group, but as active participants in innovation and co-shaping technologies. In
software development, this is possible via routes such as bug reporting, **pull
requests** on code, mailing list comments and in-person contact between users
and developers.

Among our interview subjects, developers were mostly selected on the
basis of pre-existing personal relationships that the NEXTLEAP research team
members had with the cryptographic research community. For projects with
which research team members did not have any previous personal connections,
we also reached out to developers via the GitLab and GitHub pages of the
projects (e.g. Ricochet, Conversations). In contrast, user studies tended to be
conducted with individuals selected through their attendance at training events
in their local environments (both high-risk, in the case of Ukraine and Russia,
and low risk in the case of France, Germany, Austria and the United Kingdom).⁷
Our selection of events and conferences to attend was driven primarily by our
interest in speaking to users from high-risk contexts. Indeed, while the inclusion
of high-risk individuals was important for the project (as Chapter 1 will show),
due to the level of repression these users face in their native environment, it
would have been difficult if not impossible to interview them there, since they
would be unable to speak openly. This was the case for users from Egypt, Turkey,
Kenya and Iran, where the interviews took place in March 2017 at the Internet
Freedom Festival and at RightsCon. All interviews were conducted between
autumn 2016 and the late summer of 2018, with 63 interviews in total. At several
of these gatherings and training events, we also asked our respondents to take
a moment to provide us with a drawing or a graphical representation of what/
who they considered to be their security threat or adversary when it comes to
digital communications. These images proved to be a very fruitful addition to
our fieldwork materials, as Chapter 1, in particular, will show.

Throughout our research, and due to the sensitive nature of our subject vis-
à-vis online civil liberties, it was important to keep questioning the modalities of
our access to fieldwork, and to be continually reflexive about our core assump-
tions and the ethical guidelines we as researchers were working with – questions
that have been identified as particularly relevant when issues of secrecy, privacy
and security are at play (Barbosa and Milan 2019; De Goede et al. 2019; see
also the Appendix to this book).

*Being the ‘useful sociologist’ in a team of technologists*

The fieldwork behind this book was a journey through disciplines, fields of expertise, methodologies and communities – an experience of professional and sometimes personal transformation for us as researchers, that led to a redefinition of our role as sociologists within a tech-oriented project. The NEXTLEAP team was a consortium of six partners: four were research teams
based at academic institutions (three in computer science, one – the authors of this book – in sociology), one was a research centre whose activities include a mix of philosophy-inspired action research and outreach to civil society and institutions, and one was a software development firm. Thus, the team was far from being exclusively composed of academics, and STS academics were a definite minority.

We, the authors of this book, come from what is often considered as ‘the temple of actor-network theory’:⁸ the Center for Sociology of Innovation, based at the MINES ParisTech school of engineering in Paris We therefore initially approached our research on secure messaging as a challenge for STS. Our initial academic desire was to target the work of technical actors – developers and protocol designers – and the encryption protocols themselves. However, after we delivered the first state-of-the-art description of end-to-end encrypted messaging applications and protocols, we faced a clear demand from other members of the research team: ‘focus on users’. The following months of fieldwork were marked by several interactions between us and the technologists in the team, and ultimately led to an important redesign of our interview guide. At times we were also asked to revise our research questions and priorities to include a clearer focus on insights from user-oriented interviews. Eventually, we came to understand how we looked to the rest of the team: when software development cycles include a non-technical role, this role is usually that of the ‘usability researcher’, a place that had been, somehow, automatically reserved for us.

Thus, the story behind this book is also a story of two STS researchers defining their own role within an interdisciplinary team, not without a certain amount of tension. The attempts to convey to the technologists what our STS approach was, and how it could actually be useful for them and their development process, despite not being straightforward user studies, eventually led us to develop our own ‘circumvention techniques’ to make collaborative work possible.

Embodying the ‘useful sociologist’ in a team of technologists, we found ourselves between fields, something that is also reflected in our previous publications related to the project. We found ourselves presenting our work at conferences on usable security, publishing our works in computer science reviews focusing
on usability studies, side-by-side with usability researchers. However, we main-
tained a connection with the STS world through a thin but, we believe, robust
thread of reflexivity, as we developed a critical attitude to our own usability
alter-ego and managed to use it as a key that helped us penetrate the otherwise
quite hermetic world of crypto protocol design. While, by consortium design,
our interactions and collaborations with our primarily technical colleagues were
frequent and close, this book is most definitely, in retrospect, a way to tell the
story of our three-year investigation that is intimately our own, departing when
necessary, from the compromises needed throughout the project to produce
results and publications driven by the conventions of both computer science
and the social sciences.

The first step in this process was perhaps the Autocrypt⁹ gathering in Berlin,
in December 2016, where Ksenia was invited to talk about ‘user needs and
desires’ for encrypted email and messaging and develop ‘use-cases’ that could
potentially be helpful in the design of the new specifications for email encryp-
tion. This event became the true starting point for our fieldwork – a gathering
of some of the most advanced cryptographers and developers, working on
projects such as Matrix.org, Enigmail, Wire, Secure Scuttlebutt, LEAP, Riseup
and others. At the end of the day, the rest of the NEXTLEAP research team’s
‘hunt for the user’ had finally brought us to the heart of ongoing development
and protocol design work.

Thus, this book is an occasion to reflect upon our work as an example of
embedded real-time STS, where researchers are active participants in techno-
scientific work involving multiple stakeholders and contingencies. Throughout
our case studies, we describe several examples of how our research fits into
protocol design work, and occasionally reflect upon tensions within the research
team. Ultimately, the desire to ‘meet the user’, that shows through the work of
our technical colleagues, tells us something about the evolution of encrypted
messaging towards a more human-centric design, reflected in recent develop-
ments among certain Internet governance standardisation bodies, such as the
IETF (Internet Engineering Task Force) and its research branch IRTF (Internet
Research Task Force), that seek to include human rights considerations in pro-
tocol design (see ten Oever 2021).
Before we present the structure of the book, and in order to facilitate navigation through the chapters that follow, the last part of our introduction will present a genealogy of the fundamental protocols in the encrypted messaging field; in it, we introduce relevant concepts and definitions that will be used in the following chapters.

*Encrypted messaging protocols: The short genealogy of a 'feedback loop'*

The most recent generation of tools for secure communications (appearing in the 2010s, in particular post-Snowden) marked the rise of encrypted secure messaging ‘for the masses’.¹⁰ Yet despite this recent success vis-à-vis the general public, encrypted messaging is an unstandardised and fragmented field, as developers remain in a state of flux about how to implement security and privacy properties. In particular, developers face a number of trade-offs between various design issues, including security and privacy properties, the introduction of group support features, the degree of decentralisation of the application, and standardisation and licensing attempts. To attempt an initial systematisation of this complicated landscape, our first step was an in-depth survey of thirty email and chat applications offering end-to-end encryption.¹¹ As part of this, we analysed their architectural and protocol choices, as well as their interfaces and business models (see also Ermoshina, Musiani and Halpin 2016). As an introduction and contextualisation of our research subject, this section provides a historical look at the development of email and secure messaging protocols in the light of cryptographic and usability problems that these protocols have sought to solve, while introducing relevant concepts and definitions that will be used in the following chapters. This brief, non-linear history of protocols and applications that have recently built the field of secure messaging is also a first look at an issue which we will further develop in the coming chapters: the technical and organisational choices made by protocol designers and app developers are, in fact, enacting various forms of freedom, both for users and developers.

End-to-end encrypted messaging is increasingly prominent, with its adoption by large proprietary applications such as WhatsApp and Facebook Messenger. In ‘end-to-end’ encrypted messaging, the server that hosts messages for a user or
any third-party adversary that intercepts data as the message is *en route* cannot read the message content due to the use of encryption. The ‘end’ in ‘end-to-end’ encryption therefore refers to the ‘endpoint’, which in the case of messaging is the client device of the user rather than the server.

After the Snowden revelations, the academic cryptographic community has, with renewed impetus, sought to rigorously engage with the ‘**untrusted server**’ problem. This is an issue that until recently had felt, as suggested by Phillip Rogaway, ‘almost intentionally pushed aside’, although it is perhaps ‘the most fundamental privacy problem in cryptography: how can parties communicate in such a way that nobody knows who said what’ (Rogaway 2015). The so-called ‘new generation secure messaging protocols’, such as Signal’s **Double Ratchet**, seek to address these issues and provide a remedy for the security and privacy flaws identified in older protocols, such as OTR or PGP. The success of the Signal protocol, widely forked and adopted by many secure messaging projects, has catalysed debates within cryptographic communities, and led to the revival and renewal of older protocols, creating a ‘feedback loop’ effect. Thus, the genealogy presented here challenges linear histories of secure messaging protocols, as it unveils dynamic iterations between recent and older protocols, as well as between what was considered ‘synchronous’ versus ‘asynchronous’ protocols.

## Email encryption

Historically, email has been considered a form of asynchronous messaging, where a user does not have to be online to receive the message, while chat is considered to be a form of asynchronous messaging, where a user has to be online to receive the message. However, these distinctions are increasingly blurring now that popular chat protocols generally support asynchronous messaging, and the email protocol is more and more often used for instant messaging, with the rapidly evolving galaxy of **chat-over-email** projects (see Chapter 4). Email is now considered a possible infrastructural solution for projects seeking not only privacy and security but also **interoperability** and some resistance to censorship.
Email is based on standardised and open protocols that allow interoperability between different email servers, so that, for example, a Microsoft server can send email to a Google server. SMTP (Simple Mail Transfer Protocol) is the protocol originally used for transferring email and as such is one of the oldest standards for asynchronous messaging, first defined in 1982 by the IETF¹² (Unger et al. 2015) and by default not including provision for content confidentiality. Classically, as the NSA's PRISM program has eloquently revealed, email is sent unencrypted and so the server has full access to the content of email messages. The federated nature of email infrastructure makes this even more problematic, as trust in service providers within decentralised systems is hard to guarantee. Thus, developers have for a long time made clear their intention to progress towards usable methods of end-to-end encryption for email.

To add end-to-end encryption capabilities to email, the PGP (Pretty Good Privacy) protocol was created in 1991 by Phil Zimmerman, as an ambitious technosocial attempt to 'preserve democracy' and let people 'take privacy in their hands.'¹³ Due both to pressure from the US government and patent claims by RSA Corporation, Zimmerman pushed PGP to become an IETF standard. The OpenPGP set of standards was finally defined in 1997, to allow the open implementation of PGP. GPG (GnuPG) is a free software implementation of the OpenPGP standards developed by Free Software Foundation in 1999 and compliant with the OpenPGP standard specifications, serving as the free software foundation for most modern PGP-enabled applications.

OpenPGP is implemented in both desktop and mobile email apps, including Outlook, Apple Mail and Thunderbird through plug-ins. An alternative standard for encrypted email, called S/MIME,¹⁴ is also supported via plug-ins by most major email clients. The main difference between OpenPGP and S/MIME is that the latter requires the installation of certificates provisioned by centralised certificate authorities. In contrast to PGP, which is based on a decentralised 'Web of Trust' between users who accept and sign each other's keys (and therefore delegates the responsibility of the complexity of **key management** to the end-user), S/MIME uses a centralised **public key infrastructure** to manage keys. Thus, while it has been adopted by some large, centralised institutions, it has been much less frequently adopted by the general public. In contrast to
centralised approaches, OpenPGP offloads the key management to the users
via a decentralised ‘Web of Trust’ model.

OpenPGP and S/MIME also work on mobile devices, such as PGPMail,
but as OpenPGP binds the key to the particular device, there have often been
concerns about how to securely transport any long-term private key material
between devices, and so mobile adoption of encrypted email is considered to be
low among users and problematic in terms of security. Although the challenges
of using PGP on mobile platforms are well known, mobile PGP has not been
subject to usability studies in the same manner that PGP itself has. S/MIME
has been tested in some usability studies and in general demonstrates better
usability than PGP, insofar as key management does not have to be maintained
by the end-user, but users still have trouble understanding the interface.

In general, PGP was considered to have poor usability as users could not
understand key management and judge how cryptographic keys establish
trust relationships, or even understand the interface. These problems extend
to security: if an adversary compromises a user's private key, this allows all
encrypted messages to be read. While there has been a resurgence of interest
in OpenPGP since 2013, it has not been deployed to any great extent by ordi-
nary users due to the aforementioned issues. In 2015, the IETF reopened the
OpenPGP Working Group¹⁵ in order to allow the fundamental algorithms to
be upgraded and to use more modern cryptographic primitives (for example,
support for new algorithms).

The underlying PGP protocol presents a number of well recognised flaws.
First, PGP tends to allow any and every combination of uses of encryption and
signatures based on user preference, but does not offer authentication of the
**headers** (i.e. the ‘to’ and ‘from’ fields). This allows messages to be surrepti-
tiously forwarded and otherwise redirected. In general, PGP has been consid-
ered an open standard that has serious problems in terms of both security and
usability, and this prompted the rise of a generation of competing technologies
such as Off the Record Messaging. However, recently, the email community has
been quite active and has developed a number of initiatives that have sought
to renew PGP and to ‘make email encryption great again’, as Delta Chat’s lead
developer and former NEXTLEAP member, Holger Krekel, summarised during
a conversation with us. The result is that, since 2016, the PGP community has experienced a definite revival through the introduction of new solutions such as Autocrypt, which automates both secret and public key management by adding an Autocrypt-specific mail header to outgoing mails which contains, among other information, the sender's public key.¹⁶

## Instant messaging encryption

Unlike email, which started as a high-latency and asynchronous messaging system, chat protocols began as low-latency synchronous messaging, although recently the line has become increasingly blurred as many chat protocols allow asynchronous message delivery. The user patterns of chat apps have also become increasingly varied in recent years, questioning the distinction between social media and messaging platforms ('messaging is the new social media [...] families use WhatsApp groups instead of Facebook'; Balive 2015).

The development of encryption for chat apps corresponded to changes in the contexts of usage (notably the move from desktop to smartphone technologies) and the spread of mobile Internet. The first encryption protocol for instant messaging, called OTR (2004), presumed a synchronous setting with both contacts being online at the same time. The birth of the second important protocol for end-to-end encryption protocols (Axolotl, started in 2013, now called Signal protocol) corresponded to the rise of instant messengers (in 2013, chat apps surpassed short message services in global message volume for the first time; see eMarketer 2015) and to the Snowden revelations.

The most widely used standardised chat protocol is called **XMPP** (Extensible Message and Presence Protocol) and it became an IETF standard in 2004. XMPP is a federated standard that 'provides a technology for the asynchronous, end-to-end exchange of structured data [...] among a distributed network of globally addressable, presence-aware clients and servers' (Borisov et al. 2004). There are many implementations of the XMPP specifications, with the XMPP Foundation giving a list of 35 clients, 12 servers and 15 libraries using the XMPP protocol.¹⁷ XMPP traffic and content are not encrypted by default, although network-level encryption security using **TLS** has been built into the core. In
addition, according to the XMPP foundation, a team of developers is working on an upgrade of the standard to support end-to-end encryption.¹⁸

The OTR (Off-the-Record) protocol, released in 2004, is an extension to XMPP to provide end-to-end encryption. In their paper with the iconic title ‘Off-the-Record Communication, or, Why Not to Use PGP’, the creators of OTR, Borisov and Goldberg, describe their protocol as a security upgrade of PGP, at least insofar as it does not have long-term public keys that can be compromised. OTR also provides deniable authentication for users, unlike PGP messages, the latter of which can be later ‘used as a verifiable record of the communication event and the identities of the participants’ (Borisov et al., 2004). The first OTR implementation was a popular Linux IM client, GAIM. At the present moment it is said to be used by 14 instant messaging clients,¹⁹ including earlier versions of Cryptocat (in-browser Javascript client), Jitsi, and ChatSecure (XMPP client for Android and iOS). However, the first versions of OTR were designed for synchronous messaging between two people, and so did not work for group messaging or asynchronous messaging.²⁰

The Signal Protocol, the non-federated protocol developed in 2013 by Open Whisper Systems, is said to have evolved in response to the flaws and limits of OTR. Moxie Marlinspike, the co-author of Signal, was inspired by some features of OTR, such as the idea of **ephemeral key exchange** (Marlinspike 2013), but also added additional security features such as future and forward secrecy, support for asynchronous messaging and group messaging, going a step further than OTR by allowing clients to be offline. The Signal Protocol is used in mobile messaging applications such as the homonymous Signal (formerly TextSecure and RedPhone) and WhatsApp, while its forks are used in Wire and Riot. Silent Circle, a Washington, DC-based encrypted communications firm founded in 2011, has used a version of the Signal Protocol since 2015 in its Silent Phone. In 2016 Facebook announced the implementation of Signal Protocol for Facebook Messenger.²¹

Regardless of these multiple re-usages and forks, the Signal Protocol remains unstandardised, as we will explore in Chapter 2. However, the first step towards ‘standardisation’ of parts of the Signal Protocol has begun with the creation of **OMEMO** (a recursive acronym for ‘OMEMO Multi-End Message and Object
Encryption'). OMEMO is a new encrypted extension of the XMPP protocol developed in 2015 that effectively copies the Signal Protocol and adopts it to XMPP. It was presented to the XMPP Standards Foundation in 2015 but is still in its experimental phase.²² OMEMO builds upon the work of the Signal Protocol, responding to the flaws of both OTR and PGP, due to OTR's 'inter-client mobility problems' and the absence of forward secrecy of OpenPGP and its vulnerability to so-called replay attacks. The software implementations of OMEMO are growing, and include Conversations, an open-source application for Android that counts over 50000 downloads via Google Play Market, and an unknown number of installs via F-Droid.

## Network-level anonymity

End-to-end encryption does not usually allow a user to be anonymous to the server or a third party without additional network-level encryption. Thus, network-level initiatives, such as P2P routing services or anonymous remailers, which can add supplementary privacy properties to end-to-end encrypted messaging, are worth mentioning here. Metadata protection and traffic obfuscation is still an area of active research, stimulating experiments with standards and architectures (e.g. Vuvuzela's usage of 'noise' to obfuscate metadata, discussed in Van den Hooff et al. 2015). There seem to be no functional standards on this level yet; however, some solutions, such as Tor or I2P, tend to serve as references or *de facto* standards for different projects.

The Tor hidden service protocol offers a platform to develop decentralised and encrypted instant messenger servers. Tor (the name is derived from the acronym of the original software project, 'The Onion Router'), is software that directs Internet traffic through a network of volunteers, globally dispersed, which act as relays to conceal a user's location and usage, essentially making it more difficult for a third party to trace Internet activity to a particular user. Tor's success and fame mostly relies on its ability to provide privacy and anonymity to vulnerable Internet users. It is used as a default by projects such as the Tor Messenger, Pond and Ricochet. Another example is the decentralised and end-to-end encrypted mobile messenger Briar, which relies on the Tor network when
available, but could also work over Bluetooth in case of emergency off-the-grid
situations. Briar is described in more detail in Chapter 3.

Tor only provides anonymity for network addresses, but not metadata such
as the sender, recipient and time of message, which are kept in the email header
at the time of email or can be deduced by the server. Historically, work has been
carried out on anonymous high-latency remailers to fix these transport meta-
data leaks in federated messaging, these falling under three types: Cypherpunk
Anonymous Remailer, Mixmaster and Mixminion. The last of these is not cur-
rently active, according to the project's website.²³

A number of experimental network-level tools, while not guaranteeing
anonymity, provide some level of encryption. Zero Tier One is an end-to-end
encrypted, peer-to-peer virtual network that provides static network addresses
which remain stable even if the user changes physical WiFi/networks. CJDNS
implement a virtual IPv6 network in which all packets are encrypted to the
final recipient, using **public key cryptography** for network address alloca-
tion and a distributed hash table for routing.²⁴

A fragmented yet vibrant field

As we observed in previous mapping research on P2P services (Méadel and
Musiani 2015), part of the reason why there is such great diversity and com-
plexity in this field is the relatively short lifespan of several projects. While our
mapping of thirty end-to-end encrypted messaging and email apps covered
only projects that are currently active (with one exception, Pond, ‘in stasis’,
albeit not deactivated), our preliminary research revealed countless others
that, after two or three years of pre-beta phase, and sometimes less, stopped
development with no evident explanation. While in more than a few cases,
the motives behind this are primarily related to technical experiments that
did not deliver as hoped or expected, a number of additional factors may
also be responsible, including the failure to develop an economic model, the
internal governance of FOSS development groups, and the inability to rally
a critical mass of users around the app (possibly due to a lack of ease-of-use,
as discussed below).
Despite the prevalence of free and open-source software projects, proprietary software is not absent in this landscape, revealing both a potentially fruitful 'business-to-business' market for end-to-end encryption and a lack of open-source and standards adoption by mainstream applications. Open source itself is multi-layered and sometimes hybrid, with the code on the client side being open source and the server side being proprietary. Perhaps unsurprisingly, the proprietary features are more important in applications destined for business-to-business use. Free and open-source software is predominant for tools adopted or designed to be used by activists and tech-savvy users. The transparency of code and encryption protocols used by open-source software is aimed not only at improving the project, but also at producing communities of peer reviewers, experts, beta-testers and advanced users who participate in a collective reflection on the future of privacy-enhancing technologies.

The target audience of the applications is far from being limited to tech-savvy and activist groups; several projects are intended for widespread use, and user-friendliness appears to be the main issue that stands between this wish and its realisation. A look at visual aspects connected to applications – the design of interfaces, for example, or the design of diagrams and graphics to explain the functioning of the applications – also reveals the different publics targeted by applications and how the developers perceive them. General public-oriented systems use very ‘politically neutral’ imagery, resorting to the very classical ‘Alice and Bob’ models²⁵ while stressing that their tools are for ‘everyone’ (e.g. for ‘sharing holiday photos’), while tools meant for companies emphasise in both visuals and words a focus on security. Other narratives refer to fictional anarchist leaders or real-life activists (e.g. ‘Nestor Makhno’ or ‘Vera Zassulitch’), figures likely to resonate with the target audience. Interestingly, in some instances where user feedback is visible on the App Store or Google Play, it shows that end-to-end encryption is perceived as problematic because both sender and receiver have to install the app for encryption to take place, which complicates usage.

Several secure messaging projects propose solutions to the problem of data storage. Indeed, despite the guarantees of ‘no personal data collection’, some projects still store key data on the servers (such as usage statistics, device information, keys, usernames or friend relations). Developers tend to explain such
practices by reference to technical requirements (e.g. proposing a better user
experience based on the usage statistics collected) but many developers remain
keen to seek alternatives that involve minimal data storage and use stronger
forms of decentralisation.

A related issue is a powerful ‘double’ narrative about end-to-end encryption.
If on the one hand, it is associated with a very strong discourse on empower-
ment and the better protection of fundamental civil liberties, several projects
show in parallel a desire/need to defend themselves from associations with
criminal activity and allegations such as ‘encryption is used by jihadists’ (Sanger
and Perlroth 2015). Such narratives are fuelled by previous and current ones
about decentralised technologies and peer-to-peer, with their history of alleged
‘empowering-yet-illegal’ tools. These issues in turn connect to the broader
context of discussions about governance by infrastructure and civil liberties
(Musiani et al. 2016), some of them particularly related to encryption (or the
breaking of it), such as the Apple vs FBI case²⁶ and WhatsApp using, since April
2016, encryption by default. Thus, the present research hints at something that
we will address in the following chapters – something a large majority of the
projects need to take into account, and indeed are already taking into account:
architecture is politics, but not a substitute for politics (Agre 2003).

Given the range of debates, controversies and emergent publics around
encryption and secure messaging, we hope to have begun to show why a social
perspective is necessary for the design and refinement of technical protocols.
This includes the necessity to understand how and whether users understand
and value the various security properties of the protocols. For example, how do
users understand what is a ‘key’ or what is ‘forward secrecy’? Often, protocol
designers make assumptions about whether or not ‘ordinary users’ can under-
stand the security and privacy properties of their protocols. For example, almost
all protocols from PGP to Signal use methods such as ‘out-of-band fingerprint
verification’ to determine whether or not the recipient of their message really is
who they think they are. Our research shows that users rarely actually use these
techniques to verify the identity of their contacts.

Another example that has been debated in the technical community is
deniable authentication. While a protocol may be technically deniable, would
this cryptographic deniability be able to stand the test of society, for example
in a court of law? Answering these kinds of questions influences the kinds of
protocols that can be designed by the research community. Lastly, why do
only some protocols enable decentralisation via **open standards**? Do only
specific groups of users (tech-savvy and activists) have a strong preference for
peer-to-peer or federated solutions over centralised services? This book hopes
to address these and other related questions.

STRUCTURE OF THE BOOK

Over the course of the next six chapters, the overall objective of the book is
to provide an analytical portrait of the field of encrypted secure messaging,
in order to explore the experience of encryption in today's variety of secure
messaging protocols and tools, and their implications for the making of digital
liberties.

The field of encrypted messaging offers many solutions designed to conceal, obfuscate and disguise private communications and other online activities. These solutions are tailored to protect against specific ‘adversaries’. The security and privacy features worked into different protocols offer various degrees of protection and let users conceal different parts of their online identities. To illustrate this, Chapter 1 shows how instruments such as ‘threat modelling’ and risk assessment are deployed during the development of tools in order to either identify from whom a user needs to hide or to analyse the possibility or chance of a threat being realised. Also, it becomes important not only to know who to conceal from, but also to evaluate the chances of actually ‘meeting’ this adversary. In fact, users perceive themselves as having, not a single identity, but rather a set of profiles or personas: daughter, journalist, lover, activist, colleague… Each role, according to users, may require a specific form of digital self-care or a specific set of tools. Each persona implies a specific pattern of online behaviour, thus creating what is called ‘security by compartmentalisation’. A consequence, as we argue in Chapter 1, is that when applied to online privacy and security, risk is a relational and socially defined concept, as it greatly depends on the user’s social graphs and communicative contexts.
Chapter 2 moves into the more empirically focused part of the book, by examining the case of a centralised application – Signal – and its underlying eponymous protocol. The Signal protocol is now considered to embody ‘best practice’ in the field of encrypted messaging and has become a trend-setter for other projects in terms of privacy and security features. Currently, Signal is centralised, as a single server mediates the setup of the protocol in its most widespread deployments. A new means of ‘quasi-standardisation’ or ‘standardisation by running code’ is being practised around this protocol. In this process, a quasi-standard is defined as ‘something that works’ and is iterated and redeployed by others. Centralisation has allowed Signal developers to update the protocol rapidly enough in response to research and bugs, and to limit concerns about the technical competence of having third-party developers potentially adapting their protocol to other applications than their in-house one. However, the ‘bottleneck’ of centralisation also implies that difficulties and tensions have arisen in connection with some attempts to reimplement the Signal protocol, due to the lack of clear guidelines and specifications in order to do so. Chapter 2 discusses centralisation as a ‘control by design’ model – in particular, control over changes in the protocol, so as to respond quickly to technical challenges. Here the chapter draws on two other cases alongside Signal: Telegram and Wire.

Chapter 3 examines peer-to-peer based secure messaging applications. Particular populations of users, especially those living in ‘high-risk’ environments, show interest towards these decentralised systems, as they see an alignment between their own favoured political and economic models – based on the principles of horizontal connections, mutual assistance, self-governance, participation – and the technical architecture of distributed networks. Peer-to-peer, as with previous recent instances, also promises less control by both governments and private corporations. However, peer-to-peer encrypted messaging faces a number of technical challenges, including a ‘vicious circle’ between adoption barriers and a dependency on a critical mass of users, the difficulty of managing users’ reputations and identities (identities are unique but users usually find them hard to memorise due to the form they are presented in), placing trust in the client (which presents many advantages censorship-wise but may present risks for users living in authoritarian regimes, where the main threat model
remains physical pressure and device seizure). By discussing, in particular, the
case of the application Briar and its underlying protocol, this chapter analyses
both the potential and the challenges of decentralised architectures as applied
to encrypted messaging.

Chapter 4 completes the analysis of different architectural choices and their impact on the configuration of encryption tools by examining systems based on federative models. When it comes to communities of developers debating online, the tensions between centralisation and more distributed architectural forms, such as federation, go hand-in-hand with debates over standards. Federation can help alleviate and distribute the very high degree of personal responsibility held by a centralised service provider and favours the freedom of users to choose between different solutions. On the other hand, it can present problems in terms of security, as it is harder to audit all the different implementations of a federated protocol and ensure correct updates. Drawing on the examples of Conversations (and its underlying OMEMO protocol), Matrix.org, and LEAP/Pixelated, Chapter 4 retraces the debates on federation in encrypted messaging, and analyses how federation takes shape in these debates as both an infrastructural configuration and a social experiment, in each case seeking a compromise between more distributed architectures and high levels of security.

Given the great variety of encrypted messaging solutions, how is one – a
user, an NGO, a professional – to make sense of them? Chapter 5 tells the
story of one such attempt. Classifications and categorisations are, to put it
in Bowker and Star’s (1999) words, ‘powerful technologies’, whose architec-
ture is simultaneously informatic and moral and which 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. This chapter examines such work as
it relates to encrypted messaging tools, by examining, in particular, one of the
most prominent initiatives in this regard: the Electronic Frontier Foundation’s
2014 release of the Secure Messaging Scorecard (SMS). 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.

Finally, the concluding chapter of the book ties together insights from the previous chapters to reflect on encryption as a site of social, political and technical controversy. Issues related to encryption and its adoption in messaging systems are inextricably entangled with issues of standardisation (formal/informal), the political economy of software development and adoption, and choices of technical architecture. This concluding chapter will offer some reflections on these different aspects as they have been informed by our fieldwork and will then tie the diverse ways in which political effects can be achieved through technological choices to broader political concerns related to privacy, examining in particular how they can interact with recent supra-national legal instruments such as the General Data Protection Regulation (GDPR). Finally, we will comment on the implications of our study and of cognate research for the development of social studies of encryption and for its interactions with Internet governance research, in particular of STS inspiration.

We now move into the first chapter of this book, written from the standpoint of users and security trainers – encrypted messaging experts working in an intermediary zone between developers and users. We will follow them as they deploy various strategies to make sense of the complex and moving ecosystem of end-to-end encrypted messengers.

NOTES

<footnote n="1">1 For example, future secrecy, which we will address in detail later in the book.</footnote>

<footnote n="2">2 Following up on previous work by the authors (e.g. Musiani 2015b).</footnote>

<footnote n="3">3 Scholarly and non-scholarly debates about the term ‘hacker’ are ongoing. For the purpose of this book, and given that several projects and tools examined in it do not necessarily refer to an imaginary of subversion, we follow Hellegren’s (2017) definition of a hacker as a member of a community that unites with like-minded members ‘in their practices of developing and modifying internet-specific technologies’.</footnote>
4 Many Internet protocols are client/server, which means that the machines that communicate are not equivalent: one is a server, permanently on and waiting for connections; the others are clients, who connect when they have something to ask. This is a logical mode of operation, for example, in the case of the Web: when you visit a website, you are a reader, and the entity which manages the website produces the content you seek to read. But not all uses of the Internet fit into this model; they include direct sending of messages, or file exchanges – not a one-way communication but a peer-to-peer one, with two machines or two humans communicating directly.

5 This work is available as deliverable 3.1 of the NEXTLEAP project.

6 The three cases develop both a user-facing client application and a protocol that can potentially be separated from it (Signal protocol, LEAP and Bramble respectively).

7 We will come back to the high-risk/low-risk distinction, its opportunities and shortcomings, in Chapter 1.

8 We frequently get this type of remark from STS conference attendees.

9 Autocrypt will be extensively presented in Chapter 4 as an example of a federated-architecture encrypted messaging system.

10 A previous version of this section was published as Ermoshina, K., F. Musiani & H. Halpin, 'End-to-end encrypted messaging protocols: An overview', in Franco Bagnoli et al., eds, *Internet science. Third international conference, INSCI 2016, Florence, Italy, September 12–14, 2016, Proceedings*, Springer, p. 244–254.

11 The thirty applications we examined are: Briar, Caliopen, ChatSecure, CoverMe, CryptoCat, Equalit.ie, GData, i2P, Jitsi, Mailpile, Mailvelope, ParanoiaWorks, Patchwork, Pidgin, Pixelated, Pond, Protonmail, qTOX, Ricochet, Scramble, Signal, SilentCircle, SureSpot, Teem/SwellRT, Telegram, Threema, Tor Messenger, Vuvuzela, Wickr, Wire.

12 https://tools.ietf.org/html/rfc821.

13 https://www.philzimmermann.com/EN/essays/WhyIWrotePGP.html.

14 See, e.g., https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/s-mime-for-message-signing-and-encryption?view=o365-worldwide.

15 https://datatracker.ietf.org/wg/openpgp/charter.

16 See Chapter 4. Also, https://autocrypt.org/level1.html#autocrypt-level-1-enabling-encryption-avoiding-annoyances.

17 https://xmpp.org/software.

18 http://xmpp.org/about/technology-overview.html.

19 https://otr.cypherpunks.ca/software.php.

20 The latest version of OTR (v4) aims at supporting asynchronous messaging and out-of-order delivery.

21 https://whispersystems.org/blog/facebook-messenger.
22 https://xmpp.org/extensions/xep-0384.html#top.

23 http://mixminion.net.

24 https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md.

25 ‘Alice and Bob’ are fictional characters used as placeholder names in cryptology and other computer science/engineering literature to lay out a scenario where there are several participants in a thought experiment or a model.

26 The Apple vs FBI dispute was a landmark controversy about whether courts can compel communication technology manufacturers to assist in unlocking phones whose data are encrypted. The controversy was spurred by orders issued by US District Courts to Apple in 2015 and 2016.
# I

## CONCEALING FROM WHOM? THREAT MODELLING AND RISK AS A RELATIONAL CONCEPT

NOWADAYS, THE FIELD OF ENCRYPTED MESSAGING PROPOSES A LARGE variety of solutions for concealing, obfuscating and disguising private communications and other online activities, tailored to enable protection against specific ‘adversaries’. Security and privacy features worked into different protocols offer various degrees of protection and let users conceal different parts of their online identities. As a prelude to the more detailed analysis of how some of these systems are created, developed and used – which will be the objective of Chapters 2 to 4 – this chapter seeks to discuss how instruments such as ‘threat modelling’ and risk assessment are deployed during the development of encrypted messaging systems, in order to identify from whom a user needs to hide, or to analyse the possibility of an impending threat. It is not only important to know who to hide from, but also to evaluate the chances of actually ‘meeting’ this adversary. In fact, users perceive themselves, not as having a single identity, but rather as possessing a set of ‘profiles’ or ‘personas’, and every role may require particular patterns of digital self-care, served by specific sets of tools. These different personas imply a specific online behaviour pattern, thus creating what is called ‘security by compartmentalisation’. This chapter explores how, when applied to digital security, risk is a relational and socially defined concept, as it greatly depends on a user’s social graphs and communicative contexts.¹
CREATING AND CONCEALING AN ONLINE PRESENCE

In response to the recent increasing variety of use-cases for encrypted secure messaging, a number of privacy-enhancing tools offer several different solutions to conceal private communications or other online exchanges. From the more popular centralised solutions such as Wire, Telegram, Signal and WhatsApp to less widely used decentralised platforms such as Ricochet or Briar – some of which will be the subject of the following chapters – and email clients supporting PGP encryption, these solutions are tailored to protect against specific ‘adversaries’. Security and privacy features worked into different protocols offer various degrees of protection and let users ‘hide’ different parts of their online identities.

The great variety of concealing devices that are being developed for our communicative tools is a response to the increasingly complex relationship between Internet users and the circulation of their personal data online. Indeed, our online traces are multi-layered and embedded in the material infrastructure of the Internet. Our identity can be disclosed not only by the content of our messages, but also by the unique identifiers of our hardware devices (such as **MAC addresses**), our **IP addresses** and other related metadata, thus contributing to the ‘turn to infrastructure’ in privacy and its governance (Musiani et al. 2016). This raises questions such as which of our multiple online identifiers can be considered as personal, which data should we hide, and from whom, and – to invoke David Pozen’s ‘mosaic theory’ (2005) – when does a combination of several items of *a priori* non-identifying information construct a degree of personalisation sufficient to de-anonymise a user?

Drawing upon previous work such as the anthropology of spam filters (Kockelman 2013), we understand cryptographic systems as sieves that separate items of information that have to be hidden from items that can be shown. Encryption algorithms appear as inverses or shadows of the information they sort. In fact, designing privacy-enhancing tools requires imagining the ‘worst of all possible worlds’, being constructed through various scenarios implying risk, uncertainty and flaws in security. Identification of a threat model serves as a way
of agreeing upon an appropriate threshold of anonymity and confidentiality for
a particular context of usage. Thus, different users may define in different ways
who their adversary is, may disagree (or in any case, have to find grounds to
agree) on which types of data should be concealed, and make a choice about
which tools are more likely to give them the level of protection they need.
Depending on different use-cases, from ‘nothing-to-hide’ low-risk situations,
to high-risk scenarios in war zones or in authoritarian contexts, users, trainers
and developers co-construct threat models and decide which data to conceal
and on the ways in which to do it, which sometimes relies on a variety of *arts
de faire* deployed by users to ‘hijack’ (Callon 1986) existing encryption tools
and develop their own ways to conceal themselves.

To understand how threat models are constructed, it is useful to recall the
interdisciplinary work that, in the last fifteen years, has explored the ‘collec-
tive’ dimension of privacy and the extent to which protecting it requires the
interdependence of multiple factors and actors. For instance, Daniel Solove has
described the ways in which the contours of online social representation are
gradually identified as a result of the informational traces left behind by differ-
ent interactions, dispersed across a variety of databases and networks (Solove
2006). These traces are at the core of states’ and corporations’ attempts to track
and profile citizens and users, as well as central to activists’ strategies to expose
corporate and state malfeasance. Successfully preserving one’s privacy in the
connected world is thus about managing visibilities (Flyverbom et al. 2016).
Along the same lines, emphasising the ways in which users can be active crea-
tors of their own privacy, Antonio Casilli has shown how the right to privacy
has turned into a ‘collective negotiation’ whose main objective is to master
one’s projection of self in social interactions with others (Casilli 2015). Paul
Dourish and Ken Anderson nicely summarise the core message put forward by
this approach to privacy and security when they suggest that these are ‘difficult
concepts to manage from a technical perspective precisely because they are
caught up in larger collective rhetorics and practices of risk, danger, secrecy,
trust, morality, identity, and more. As an alternative, they argue that we should
move ‘toward a holistic view of situated and collective information practice’
(Dourish and Anderson 2006).
Surveillance studies have also paid specific attention to the collective and relational dimensions of surveillance, privacy and security. Authors interested in exploring the concept of resistance have underlined the algorithmic and ‘rhizomatic’ nature of new surveillance practices and the responses needed to counter them (Martin et al. 2009); others show how a traditional conceptualisation of surveillance, involving an exclusive relationship between the surveillant and his object, does not properly take into account the ‘surveillant assemblages’ (including those that seek to respond to surveillance) that are currently on display in networked media, and are transforming the targets and the hierarchies of surveillance activities, while at the same time reconfiguring the notion of privacy (Haggerty and Erickson 2000).

Some contributions by scholars of online surveillance and privacy, while grounded in research that demonstrates the pervasiveness of digital surveillance and echoes the conceptualisation of surveillance as ‘assemblage’, are explicitly aimed at providing practical ‘guides’ for users. This is the case with Finn Brunton and Helen Nissenbaum’s *Obfuscation*, which aims to provide both a rationale and a set of tools aimed at the ‘deliberate use of ambiguous, confusing, or misleading information to interfere with surveillance and data collection projects’; these strategies may include noncompliance and sabotage (Brunton and Nissenbaum 2015). The work of Lex Gill and colleagues, with a particular focus on the Canadian context, also seeks to provide a ‘field guide’ to the debates on encryption and offer hands-on suggestions for ‘policymakers, legal professionals, academics, journalists, and advocates who are trying to navigate the complex implications of this technology’ (Gill et al. 2018). The increasing frequency of this type of contribution – the provision by scholars of hands-on guides in this field – is interesting to acknowledge in the context of this book. Such texts create hybrids that operate somewhere between scholarly contributions, on the one hand, and, on the other, practical guides meant to act as companions to the proliferation of tools and possible use-cases. Thus, such texts – and possibly, to some extent, the present book – contribute to concretely co-shaping users’ responses to surveillance and actions aimed at protecting privacy.
‘KNOW YOUR ENEMY’: THREAT MODELLING AS A TOOL FOR TRAINERS

In design studies and software engineering, threat modelling is considered an inherent part of the normal design cycle where ‘security needs’ are understood as yet another facet of the complex design process: ‘We must consider security needs throughout the design process, just as we do with performance, usability, localizability, serviceability, or any other facet’ (Torr 2005). When applied to the software development process, threat modelling is defined as a ‘formal pro- cess of identifying, documenting and mitigating security threats to a software system’ (Oladimeji et al. 2006). Threat modelling enables development teams to examine the application ‘through the eyes of a potential adversary’ in order to identify major security risks. However, threat modelling processes and tech- niques are also applied to human agents, in order to find security flaws in user behaviour patterns (both online and offline), identify sensitive information ‘to be protected’, determine potential adversaries, and evaluate their capacities and propose solutions for risk mitigation and protection.

The idea of threat modelling applied to users instead of informational systems is related to the difficulty – rather, the impossibility – of ‘hiding from everyone’. As the Electronic Frontier Foundation, a leading NGO in the digital security sphere, puts it:

> It’s impossible to protect against every kind of trick or attacker, so you should concentrate on which people might want your data, what they might want from it, and how they might get it. Coming up with a set of possible attacks you plan to protect against is called threat modelling.²

Threat modelling is linked to another instrument called risk assessment. While threat modelling means identifying from whom a user needs to hide, risk assess- ment is a tool that trainers and digital security organisations use in order to analyse the chance of a threat being realised. It becomes important not only to know who to hide from, but also to evaluate the actual chances of coming face-to-face with one’s adversary. While risk has been described as a cultural ‘translation’ of
danger (Douglas and Wildavsky 1982; Vaz and Bruno 2006), risk assessment is a
‘quantification of uncertainty’ (Hong 2017), that produces risk as something that
can be ‘known, mitigated, increased and decreased, calculated’ (Porter 1995).

For the digital security trainers, we interviewed over the course of this
research, threat modelling and risk assessment have become powerful instru-
ments for narrowing down and structuring their training sessions. Several train-
ing sessions that we have observed in Ukraine and Russia used different threat
modelling techniques. For example, the ‘Digital security for activists’ session
that took place in Saint-Petersburg, Russia, on 10 April 2016, started with P.,
the trainer, offering the following introduction:

Before we start, we need to decide from whom we are protecting. First, the state. In just the last year 200 court cases have been opened because of online publications, comments and so on. Second, we should be protecting ourselves from corporations. It may be naive to say so, but it is clear that different corporations are accumulating information, and a lot of useful services that are given to us for free, however in exchange these companies are appropriating information about us. Third – there are other malicious agents who would like to get access to our online wallets or to hack us just for fun (translation from Russian by the authors).

This division between three categories of adversary was not just used rhetori-
cally to introduce the training session: it was subsequently used throughout the
three-hour workshop, in order to group various privacy-enhancing tools that
people might need, around the three big categories of adversaries. Structuring
training around a specific adversary means identifying not just the technical
resources the adversary possesses, but also the extra-technical parameters – the
legal context, for example.

Another way of structuring a training session was experimented with by
Ukrainian trainers V. and M., both of whom specialised in high-risk users likely
to face powerful, state-level adversaries, or maybe even physical threats. The
training, held on 15 January 2017 in Kyiv, involved using a spreadsheet for both
participants and trainers to complete (Figure 1.1).
<figure><img src="image_12.png" /><figcaption>**FIG. 1.1** Digital security training observed in Kyiv, January 2017. The table includes the following columns (from left to right): Description of a person, its functions and activities and risks, 'assets' (devices, accounts, types of communications used), adversaries, threats (applied to the assets based on risks), possibility of a threat to happen, how to avoid risks (photograph by the authors).</figcaption></figure>

The training was organised around a collaborative construction of several fictional profiles (for example: Anya, 25 years old, ecological activist; Oksana, 30 years old, journalist, etc.) and the identification of corresponding assets, adversaries and threats. In this way, trainers were focused not on enumerating existing privacy-enhancing tools, but on explaining a precise methodology of personalised threat modelling. For trainers, a user's ability to analyse a very concrete situation and context is more important than their possessing sophisticated knowledge of multiple tools. Though some of the observed training sessions were nonetheless centred around demonstrations of particular tools, the majority of trainers are largely critical of tool-centred approaches and insist instead on tailored, threat-model-based forms of training:

> Very often trainings turn into tool-trainings. But in our work tools are not our primary and even not secondary concerns. What's primary is the evaluation of what participants need, what they already use. And only after we think of what we can suggest them to use, and again, without any hard
recommendations ‘you need only this tool and that’s all’ (M., informational security trainer, Ukraine).

The digital security community is highly reflexive about its own training practices and the evaluation criteria used to assess secure messaging applications and mail clients. In recent years, the transition from a tool-centred approach to a user-centred one has been something of a paradigm shift among trainers and experts, where the user’s capacities to evaluate their own threat model are seen as increasingly crucial. As the famous EFF guide ‘Surveillance Self-Defense’ puts it,

> Trying to protect all your data from everyone all the time is impractical and exhausting. But, do not fear! Security is a process, and through thoughtful planning, you can assess what’s right for you. Security isn’t about the tools you use or the software you download. It begins with understanding the unique threats you face and how you can counter those threats.³

This ‘tailored approach’ to threat models during security training sessions is also important because developers in the secure messaging field are currently discussing a number of unsolved cryptography problems, such as metadata storage, the vulnerabilities of centralised infrastructures, the usage of telephone numbers as identifiers and so on. In the absence of the ‘perfect tool’ in all these respects, trainers recommend patchworks of different tools and operational security practices (‘physical security’) that aim to minimise the drawbacks of existing tools and offer different features, from encryption ‘in transit’ to encryption ‘at rest’, metadata obfuscation, and so on. Threat modelling is a practice that helps to fix, and in some ways compensate for, some of these unsolved technical problems.

It is also important to note that, for a specific threat model, extra-cryptographic factors such as a particular tool having a low learning curve before it can be used, peer pressure or network effect (first-time users joining a tool because a critical mass of individuals already uses it) may be more important than the technical efficiency of a cryptographic protocol. Thus, a trainer in Ukraine
would – seemingly counter-intuitively but, from their standpoint, ultimately logically – often advise their high-risk users to use WhatsApp and Gmail instead of Signal or a PGP-encrypted form of email, as ‘everyone already uses it and knows how it works’. In other words, the adoption of these tools will happen quicker and result in fewer mistakes. Thus, time and learning curve become additional factors affecting the recommendation of a specific tool.

‘NOTHING TO HIDE’ OR ‘TINFOIL HAT FREAKS’?
A CONTINUUM OF RISK LEVELS

Away from trainers and digital security experts, users develop their own meth-
ods to evaluate their risks, and invent specific *ad hoc* practices of digital self-
defence. However, even after the Snowden revelations, a significant proportion
of European citizens share the idea that they have ‘nothing to hide’, sometimes
considering the mere fact of concealing online traces as a potential indication
of criminal activity. A recent study has revealed a certain state of public apathy:
‘though online users are concerned and feel unease about the mass collection of
their personal data, the lack of understanding as to how such data is collected
as well as a sense of powerlessness leads to the public’s resignation and apathy’
(Hintz and Dencik 2017).

The ‘nothing to hide’ argument has, famously, been widely criticised by the security community, resulting in the production of a variety of cultural content and online tutorials aimed at increasing the awareness of the general public about digital security.¹These contributions fuel the ongoing debate about the thin line separating both targeted surveillance from mass surveillance and high-risk from low-risk users. The demarcation between hiding from governments and hiding from corporations is also increasingly blurred, with the image of the ‘adversary’ becoming much more complex and hybrid (Musiani 2013).

While the vast majority of user studies in **usable security** – the field of study that evaluates the usability of digital security – have been conducted with subjects from the ‘general population’ (in fact, usually, university students), our research provides slightly different results regarding users’ awareness of and concerns about privacy. We classified our interviewed population against
two axes: individuals' knowledge about technologies and their risk situation. This resulted in four groups that we will examine in turn in the remainder of this chapter – although, as we will further explore later, while we found this distinction operationally useful, it also had its limits.

For profiles with a low-level risk situation but possessing a high degree of technical knowledge, the awareness of privacy and security related risks was very high; however, the generally adopted user behaviour was not holistically secure: a large number of tech developers or trainers were using unencrypted email and text messaging applications. For example, despite recent usability research showing that Telegram was suffering from a number of important usability and security problems (Abu-Salma et al. 2017a), with encryption for group chat being very basic, Pirate Party activists – themselves software developers, system administrators and/or hosting providers – use Telegram on a daily basis (for example, the group of Pirate Party Russia on Telegram counts 469 users as of 24 November 2019). However, other tactics of self-defence are used, such as self-censorship (avoiding talking about specific topics) and pseudonymisation (avoiding real profile photos and usernames).

Surprisingly, there is no strict correlation, at least in our interviews, between users' threat models, level of technical knowledge, the security features of a tool – such as key length or key generation algorithm – and the dynamics of tool adoption. Instead, other extra-cryptographic and extra-security features can become arguments for the adoption of a specific tool. In the case of Telegram, it is interesting to observe how the actual cryptographic protocol and security and privacy properties lose their importance for users, compared to the features of the interface and to the reputation of the app's creator. The trust in Telegram, according to our interviews, is not located in the technology, but in the person using the technology and their political position:

* User1: 'Maybe you should not discuss that over Telegram?'

* User2: 'Why not? Pashka Durov will never give away any of our data, he does not care about Russian police' (from online discussion in a group chat 'Soprotivlenie' [Resistance], posted on 11 June 2017; translation from Russian by the authors).
Within high-risk and low-knowledge populations, however, the awareness of risks regarding privacy issues (such as the necessity of using privacy-preserving browser plug-ins) was not absolute, with behaviour related to email and messaging estimated as being more important. Even if these users could not always clearly describe possible attack vectors, they had a highly multi-faceted and complex image of who their adversary was. This was clearly expressed in the drawings collected during interviews and observed workshops, which respondents drew when asked by us to illustrate who or what they considered to be their adversary (Figure 1.2).

'Low-knowledge, high-risk' users, for their part, deploy specific, often unique and personal, methods to protect their communications and information, resulting in an assemblage of different tools and practices, both in their offline (social engineering, operational security or 'opsec') and online behaviour (Figure 1.3).

<figure><img src="image_13.png" /><figcaption>FIG. 1.2 User representation of 'insecure communications'. Drawing collected during a digital security workshop in Saint-Petersburg, April 2017. By a female activist of a feminist collective. The 'crocodiles' are labelled (from left top clockwise): 'Corporations, Facebook'; 'Trolls'; 'Center against extremism, FSB, police'; 'Who the f**k knows'. On the cloud: 'Search'; 'Social networks'.</figcaption></figure>
<figure><img src="image_14.png" /><figcaption>**FIG. 1.3** User representation of ‘secure communications’. Drawing collected during a digital security workshop in Saint-Petersburg, April 2017. Female, antifascist activist. From the left: ‘Me: laptop + Tails + 100500 passwords + Tor + Thunderbird + 100500 keys + trusted email provider = message “Nikita, could you buy some tomatoes please?”’ (And if Nikita is online, then Jabber)’</figcaption></figure>

For instance, high-risk users in Russia and Ukraine – namely left-wing activists who face police threats and targeted surveillance – are widely using the so-called ‘one-time secrets’, special web-based **pastebins** or pads that claim to destroy messages once read.⁵ These users describe the main threat they face as being the seizure of their devices. Thus, they suggest, a self-destroying link is the most secure way to communicate, even though the links to these locations are often sent via unsecured channels, such as Facebook Messenger. The flip side of these practices is that applications that are *a priori* more specifically targeted to activists become infrequent choices for these high-risk users.

SECURITY BY COMPARTMENTALISATION AND
‘RELATIONAL’ RISK

As these examples show, the multitude of messaging apps echoes the variety of
user behaviour and risk assessment practices. In fact, users perceive themselves
as having a plurality of identities, each of which may require specific digital
self-care practices and sets of tools. This creates what we call ‘security by
compartmentalisation’.

Users select different messaging apps for different groups of contacts, accord-
ing to the perceived level of risk. Even some of our high-risk interviewees report
that they use WhatsApp or Facebook Messenger for work and family relations,
while preferring PGP-encrypted email, Signal or Privnote for activist-related
contacts. Some prefer to move all the communications to a single application, but
report having a hard time convincing relatives to change their online behaviour
(the so-called ‘digital migration problem’) or face compatibility problems (for
example, older phones cannot run Signal).

As a consequence, when applied to digital security, risk is a relational concept,
as it greatly depends on the user's social graphs and contexts of communica-
tion. A high-risk user from Ukraine, involved in a collective for the support of
political prisoners, explains:

My risk is always connected to the risk of other people. I do not want to use
my mobile phone to connect to my activist account, as it will be possible to
connect the two. And even if I think that I have not done anything, other
people have reasons to hide themselves. And finally... I never know when
someone comes after me. Predicting future is not wise. Khodorkovsky just
before his arrest also said that no one was interested in him.

In this sense, even though using axes to categorise users can serve practical
ends – making it easier, for example, to apply statistical treatments to our
data, something that the technologists in the NEXTLEAP team very much
appreciated, which resulted in a few collaborative papers – the difference
between low-risk and high-risk users is actually highly context-dependent,
and always shifting: a low-risk person in contact with high-risk ones has
to increase their level of security and may themself become high risk. As a
user from Austria, a festival organiser self-identifying as a low-risk person,
puts it:
I work on a festival which is all about generating outreach. And I adapt to the people I invite or strategize projects with. So the risk of my communication is related to the risk taken by the people I am talking to. So for example with [X], [Y]⁶ or others I always encrypt everything of course and I also always check if a guest I am inviting has a public key on a keyserver so I start communication encrypted [...] Enemy? Lots of my guest speakers have serious enemies; so I again adapt to that.

This ‘compartmentalisation’ approach to security also results in some hardware-based user bricolages or tinkering, ranging from the more popular practice of ‘dual-booting’ (combining an ‘activist’ and a ‘normal’ operating system on the same machine), to more sophisticated hiding places or concealed operating systems. These user behaviours and user-driven practices of security by compartmentalisation have been recently incorporated *by design* in a project named Qubes. This is an operational system based on a multitude of virtual machines creating isolated working environments that let users coordinate and manage different ‘parts’ of their online identities with different needs and security requirements.

However, risks and threat models also evolve over time. Not only are these dependent on users’ relational networks, but also on the supposed reactions and behaviours of the adversary. Thus, for this high-risk and high-knowledge user from Greece, it is important to constantly reinvent their everyday security practices:

> According to the act or what I do I have a specific OPSEC. I remember the main steps by heart, though I don't use the same practices every time as once used a specific methodology then it's burned. Depending on the place I try to masquerade to the common practices of this area rather than blindly improvise. The adversary is always learning from me and from trusted people or friends that are not careful enough.

If the distinction between high risk and low risk needs to be taken with a grain of salt, so too do the definitions of sensitive and insensitive data. Religion,
morality and gender become important parameters in influencing the definition of what 'sensitive information' is. Our interviews with Middle Eastern users, for example, show that one of the most important adversaries from whom Muslim women have to hide is their own partner or family member. As one of our interviewees, a twenty-seven-year-old Iranian woman, explains, photos of a non-religious wedding can become as sensitive as an instance of political critique, and can present significant levels of risk to the person sharing the photos. It is not, therefore, the type of information itself that defines the category of 'high risk', but the user's broader context: threat models and risk levels thus can be gender and culture dependent.

## 'IF YOU USE THAT TOOL, YOU HAVE SOMETHING TO HIDE': PARADOXES OF THE MASS ADOPTION OF ENCRYPTION

According to our fieldwork, open-source and licensing choices are covered less in high-risk training sessions, as high-risk users do not always associate open source with security. Open source was perceived as a less important criterion in the context of an immediate physical threat: if a proprietary but 'efficient' and 'easy to explain' solution exists, trainers will give it priority. For example, in Ukraine, WhatsApp is the most recommended application, because it is considered easy to install. Trainers consider WhatsApp's proprietary license and collaboration with Facebook (notably in relation to metadata sharing) as less important than users' perceptions around security. The primary task in high-risk contexts with low-knowledge users is to help them quickly abandon unencrypted tools, as well as tools whose creators may be collaborating with their adversaries.

Since WhatsApp adopted end-to-end encryption, we usually do not spend that much time on instant messaging encryption [during trainings] and recommend to stay with WhatsApp if people already use it. So they can still communicate with all of their friends, and also... it looks familiar, and it does not shock them. And people say [during trainings] if they use WhatsApp it's less suspicious than if they use a special app for activists (I., female informational security trainer, Ukraine).
This quote raises an important concern addressed by a number of our user interviewees and observed during both cryptoparties and informational security trainings: *does the very fact of using an activist-targeted app constitute a threat in itself?* This refers to Ethan Zuckerman's (2008) famous 'Cute Cat Theory of Digital Activism', according to which it is safer and easier for activists to use the same mainstream platforms as those used for sharing 'lolcats' pictures, whereas using a tool marked as 'activist' may put users under targeted (and thus, easier and cheaper) surveillance.

This concern reveals a shared (but often underexplored) anxiety among users about specific kinds of metadata (even though this particular term is not always used explicitly), e.g. data about their installation of particular apps. In interviews, we were often confronted by an extensive critique of all the existing tools by both informational security trainers and non-technical users. This echoes the findings of another recent usability study of end-to-end encryption tools, which concluded that 'most participants did not believe secure tools could offer protection against powerful or knowledgeable adversaries' (Abu-Salma et al. 2017b: 2). Many users mentioned as a reason for not adopting encryption the fact that their social graphs and 'activist' lifestyle would be exposed to adversaries by using specific tools. A Russian user also mentioned the opposite effect – using an activist-targeted tool as means of 'earning trust' – recounting the story of an undercover police officer who used a @riseup.net email account as a way of penetrating a student movement mailing list during the 2011–12 mass protests.

The quintessence of this 'tool-scepticism' can be illustrated with a drawing (Figure 1.4) authored by one of our respondents – a European high-risk war correspondent working in the Middle East – when asked to draw a representation of his adversary.

The adoption of encryption by mainstream messaging applications (as opposed to applications designed more specifically for activists) leads to a peculiar effect that one of our respondents summarised as 'fish in the sea' (used in the sense of being 'one among many similar entities' in a wide-open space that offers mutual protection via mutual concealment):
Imagine if I have nothing to hide, but I still use an end-to-end encrypted app, then people who need to hide themselves... like whistleblowers for example... it will be easier for them, say, to disappear in this big flow of cat photos or love messages. So I feel like I am helping someone when I use encryption all the time for all of my communications (Female, low-risk user, tech-journalist, Austria).

An interesting phenomenon of 'shared responsibility' arises from this mass adoption of encryption: the more users opt for end-to-end encryption tools, the more secure it becomes for everyone to use these tools, but specifically for those users whose life and freedom depend on them. As we will see in the following chapters, while in the mass adoption of distributed or peer-to-peer applications there is a real technical correlation between the number of users and the level of privacy protection, for centralised applications (like Signal and WhatsApp) or for email encryption, the consequences of mass adoption are often described as increasing the difficulty, human and technical, for the adversary to achieve its surveillance objectives:

> The more people use encryption, the more expensive it will be for the governments to read everything. It's not about reaching 100% security... This simply does not exist! It's about making them waste their time and money to decrypt our stuff and in the end they are reading something like 'Let's go eat pizza tonight'... (male, informational security trainer, Ukraine)

Even though the collaboration of Signal's head developer, Moxie Marlinspike, with WhatsApp and Facebook was controversial and subject to critiques within a number of tech-savvy circles – in particular in the **F/OSS** (Free and Open-Source Software) communities – mass adoption of end-to-end encryption had an important impact on Internet governance. With applications such as WhatsApp bringing strong cryptography into the mainstream, the thesis of 'encryption as a human right' and the demand for 'equal access to encryption' have become more widespread. Among recent initiatives, a 2017 letter signed by 65 privacy-focused NGOs (including Privacy Now, EFF and Article 19) and addressed to the UN,
<figure><img src="image_15.png" /><figcaption>**FIG. 1.4** Drawing collected during the interview on February 16, 2017. The user commented on the drawing as follows: 'In the case of a truly secure communication I say something, but no one knows what I said and to whom [...] I could have just given you a blank sheet of paper, it would have meant that no traces of a communication act are visible. But as soon as you asked me to draw you something...' (C, male, journalist, high risk).</figcaption></figure>

demanded the decriminalisation of users of privacy-enhancing technologies and digital security trainers (see IFEX, 2017). Two years earlier, privacy and the right to conceal were presented by the United Nations Special Rapporteur on Human Rights as a core component of freedom of opinion and expression:

> Discussions of encryption and anonymity have all too often focused only on their potential use for criminal purposes in times of terrorism. But emergency situations do not relieve States of the obligation to ensure respect for international human rights law [...] General debate should highlight the protection that encryption and anonymity provide, especially to the groups most at risk of unlawful interferences (Kaye 2015).

In our interviews, developers and information security trainers underlined the urgency of finding a reliable solution to the problem of **metadata** collection. As we have already implied, this is a key area where debates around encryption become relevant. Metadata are data that describe or provide information about other data, such as social media discussions, email exchanges or online
transactions. Devices and systems that are connected to the Internet (or support its operation), including messaging and other online communication systems, collect this 'information about information' that, when aggregated, can account for a user's daily Internet activities, but also for real life activities and activities of other users. The collection of metadata is, or can be, especially problematic because it happens in the background and for a variety of purposes, and users can usually gain access to a mere fraction of the metadata collected about them. Controversies around metadata collection are numerous, including the presence of informed consent, the level of clarity concerning use or sharing, the existence of retention policies (documents stipulating how long an entity will store metadata) and the legal possibility of bulk or warrantless collection, in particular by governmental agencies (Piscitello 2016). Ultimately, developers and trainers appear to share a consensus that there is currently no solution in the field of end-to-end encrypted instant messaging apps that offers good metadata protection. Developers and trainers associate the leaking of metadata with centralisation:

> Metadata connects you weirdly with other people, and there's more sense in the metadata than in the data itself for technological reasons [...] No one from the messaging apps is trying to solve that. Instead they suggest to sync your address books so they know exactly who you're talking to even though you trust them to somehow make it into **hashes** or whatever. That's the issue we are not solving with the apps, we make it worse. We now have centralised servers that become honeypots, and it's not about the data, it's about the metadata (Peter S., Heml.is).

## 'ACTUALLY, IN GOOGLE WE TRUST': QUESTIONING THE PRIVACY-SECURITY DICHOTOMY

When we first attempted to interpret our fieldwork, our hypothesis was that very distinct threat models could be associated with distinct types of users, grouped according to their risk status – ‘high’ or ‘low’. As already noted, this hypothesis was operationally useful, especially for our joint work with computer scientists
more familiar with usability studies. However, our fieldwork showed the limits
of this opposition, demonstrating the relativity of two binary visions: users
could be categorised not only as high risk vs low risk, but also according to
their concern about privacy vs security. These two concerns, and the defensive
practices they give rise to, are in fact interpenetrating, as the remainder of this
section will further demonstrate.

Indeed, among our interviewees, citizens of supposedly ‘low-risk’ countries (Western countries led by long-term democratic regimes) were more concerned with privacy-related issues, while individuals ‘at high risk’ (i.e. belonging to particular socio-demographic groups that placed them in the spotlight of authoritarian regimes) focused on urgent needs and life-and-death situations, often adopting technical solutions that are easier to install and use, even if they do not, in fact, provide strong levels of privacy protection (WhatsApp, for example). This difference can be exemplified by the different attitudes towards tech giants, such as Google, Apple, Facebook, Amazon and Microsoft. Criticism of these companies mostly comes from Western users who have a high degree of knowledge about information technology and its socio-economy. Several ‘high-risk’ users, by contrast, shared the idea that centralised and quasi-monopolistic services like Gmail, for example, offer a better security-usability ratio. In a context of risk and urgency, there tends to be a compromise between user-friendliness and security, while technically experienced low-risk users often focus more on developing genuinely complex and multi-layered privacy and security preserving toolkits.

However, some of the criticisms of the practices of tech giants that have
originated within the F/OSS community have touched larger, non-technical
populations in high-risk countries. An example is the controversy about Signal's
dependence upon Google Play and Google Services,⁷ which originated within
free software circles with the launch – and subsequent rapid shutdown – of the
project LibreSignal.⁸ Signal's dependence upon Google became a problem for a
specific privacy-aware and tech-savvy user community, who opt for decentralised
alternatives to the communication tools provided by Net giants. In this context,
the choice of a ‘Google-free’ messenger can also be perceived as a ‘lifestyle’
choice. This choice often coexists with alternative choices of hardware (e.g. a
Linux phone, a Fair Phone, Copperhead OS, or other privacy enhancing tools). As one tech-savvy user put it, 'If I don't like mainstream in media, if I don't like mainstream in music – why would I like mainstream on my computer?' [Daniel, mail service provider, festival organiser].

However, according to our interviews, Signal's dependencies on Google Play had an important impact not only on tech-savvy users from a priori low-risk environments, but also on users in problematic settings and with little technical knowledge. For example, in Syria, the country-wide blocking of Google Play meant that low-knowledge users no longer had comfortable and immediate access to the Signal app, yet they lacked the competencies to look for alternative routes to acquire it. Technical decisions made by developers of privacy-enhancing technologies – such as dependencies on third-party libraries and their licensing and protocol choices – are not only a preference or lifestyle issue for users but may also impact their security in life-and-death contexts.

Users in 'high-risk' type settings also mentioned as important for their threat models the issue of decentralised networks, once considered an overwhelmingly 'high-tech, low-risk' concern. For example, our recent exchanges with Russian and Ukrainian left-wing activists revealed a growing desire among these populations to run their own file storage and decentralised communication infrastructures.

## CONCLUSIONS: RISK IS RELATIONAL, THREAT MODELLING IS CRUCIAL

By providing a number of examples related to contexts of use, users' perceived needs and selection of possibly appropriate tools, this chapter has shown that in the field of online communications, and more particularly secure messaging, risk is relational, and threat modelling is crucial for choosing the right tool to protect one's communications. For example, if a user's primary objective is to conceal from one's own government, this objective is inextricably entangled with changes in consumer habits and migrating from closed-source platforms with business models based on user data. In this context, the 'adversary' resembles a constantly evolving, fluid network connecting with
both private and institutional infrastructures, rather than a single entity with
well-defined capacities and a predetermined set of surveillance and attack
techniques and tools.

Trainers and digital security organisations are shifting towards a user-centred approach and user-tailored training sessions. At the same time, they increasingly face the challenge of communicating to their trainees that privacy-preserving and privacy-enhancing tools do not guarantee, in and by themselves, absolute security. Unsolved cryptographic challenges, such as how to build usable metadata-preserving solutions, are somehow ‘compensated for’ by a patch-work of operational security techniques and combination of tools that users invent and constantly modify. Thus, the identification of ‘who we must conceal from’ – threat modelling and risk assessment – is a constantly changing process that depends upon a large set of often non-technical or non-cryptographic parameters, such as a user’s social graph, gender, religious or ethical norms, profession, geopolitical situation/the political regime, or the reputation and charisma of app creators. Indeed, encrypted communication is the product of, and sometimes the catalyst for changing, a vast network including institutions (or actors positioning themselves in opposition or resistance to them) and of course, myriad infrastructures and technical devices in which concepts such as security and privacy are embedded (see our previous discussion about ‘doing Internet governance’ in the introduction).

The very distinction between high risk and low risk, while useful operationally for the researcher as a practical methodological tool in order to build a diverse sample of users for interviews, shows its limits, mainly due to the ‘relational’ nature of risk we have introduced in this chapter. If a low-risk user has at least one high-risk user in her social graph, she may adopt a higher level of protection and even install a specific tool for communicating with this contact – and inversely, in specific sociopolitical contexts, what is usually understood as low-risk/non-sensitive data may in fact place its owners in higher risk categories. Indeed, if designing privacy-enhancing tools requires imagining the ‘worst of all possible worlds’, this may well be the world of an individual among our contacts: the person who is most in need of concealing. The following chapters explore how developers seeking to respond to the ongoing turn to ‘mass encryption’
take this into account, as they explore different architectural configurations
for encrypted secure messaging tools and cope with their constraints and
opportunities.

NOTES

1 An earlier version of this chapter was published as Ermoshina, K. and F. Musiani, ‘Hiding from Whom? Threat Models and In-the-Making Encryption Technologies’, *Intermédiarités: Histoire et théorie des arts, des lettres et des techniques*, 32 (2019), special issue Cacher/Concealing. It was also presented and discussed at the annual conference of the International Association for Media and Communication Research in Eugene, Oregon, 7–11 July 2018. We are grateful to the French Privacy and Data Protection Commission (CNIL) and Inria for selecting this work as a runner-up to the 2019 CNIL-Inria Privacy Protection Prize.

2 https://ssd.eff.org/en/glossary/threat-model.

3 See, https://ssd.eff.org/en/ playlist/academic-researcher#assessing-your-risks;
we will analyse in Chapter 6 how this shift entails a change of methodology used to
rank, evaluate and recommend secure communication tools.

4 Among recent initiatives, the documentary *Nothing to Hide*: http://www.allocine.fr/video/player_gen_cmedia=19571391&cfilm=253027.htm.

5 The most popular services are One Time Secret (https://onetimesecret.com) and Privnote (https://privnote.com).

6 Mentioning two important and well-known tech and human rights activists.

7 https://github.com/WhisperSystems/Signal-Android/issues/127.

8 https://github.com/LibreSignal/LibreSignal; see Chapter 3.
CENTRALISED
ARCHITECTURES AS
INFORMAL STANDARDS FOR
‘CONTROL BY DESIGN’

THIS CHAPTER IS THE FIRST OF A SERIES, CONSTITUTING THE CENTRAL PART of the book, that is best read as a triptych. Together, these three chapters are meant to provide an analysis of different architectural choices and their impact on the configuration – social and economic as well as technical – of encrypted messaging tools. Evaluating the consequences of these choices is important, in our view, for the reasons expressed in the introductory discussion of the contributions social sciences can make to the study of encryption and decentralisation. We saw some of this at work in Chapter 1: every technical choice made by developers of secure messaging tools is not about reaching a perfect model, but about implementing, in practice, a series of compromises that are about technical performance, but also about community-building, standard-setting and finding suitable governance and organisational models. It is also about business models and reaching specific publics. Illustrating this interweaving of dynamics has been the core aim of this triptych of chapters.

Furthermore, we understand our review of the three types of architecture
as a discussion of different ways to practise specific visions of online freedom:
freedom to control the implementation of the technical solution, freedom
proposed to users to choose their infrastructure to a more or less large extent,
freedom to do without intermediaries or to configure them in specific ways,
etc. Indeed, throughout these chapters, the overarching, central concept for
this book – ‘concealing for freedom’ – is fleshed out, not as a fixed value, but as
something that is performed differently in different settings and defined by the field(s) within which it operates.

This chapter discusses centralisation, as defined in the Introduction, as a ‘control by design’ model for secure messaging protocols and applications. In particular, we discuss the dynamics of centralisation-as-control deployed as a means to respond quickly to technical challenges in a situation of uncertainty. To do so, we explore Signal as a central case study, but we also touch upon the cases of Telegram and Wire. This chapter shows how ‘concealing for freedom’ dynamics unfold for both developers and users in the case of centralised architectures. While centralised tools can offer users suitable solutions to protect their freedom ‘from’ particular adversaries, their stance vis-à-vis active freedoms, such as the freedom ‘of’ choice – of particular incarnations of a protocol, of specific interface elements – is much more problematic. On the developers’ side, centralised architectures can restrict the freedom ‘to’ reuse and implement code in different applications subtending the same protocol (Nyman and Lindman 2013). As Nyman (2015: 116) points out, quoting Raymond (1999), closed source licensing, made easier by centralised arrangements, erects a number of artificial technical, legal or institutional barriers that prevent ‘good solutions from being re-used’. In this case, a certain level of standardisation – be it formal or informal, as we will analyse below – can become a factor of freedom for developers.

As seminal secure messaging protocols such as PGP and OTR started showing their age in terms of security and usability, cryptographers, unsurprisingly, wanted to develop new and better protocols in the wake of the Snowden revelations. Open-source developers started to deploy efforts to create a next-generation secure messaging protocol. The most advanced and popular protocol in this regard is the Signal protocol, used by applications such as Signal (formerly TextSecure).

The Signal protocol is now considered the ‘best practice’ in the field of encrypted messaging and has become a trendsetter for other projects in terms of privacy and security features. Currently, Signal is centralised, as a single server mediates the setup of the protocol in most widespread deployments (e.g. WhatsApp, Google Allo, Facebook Messenger, Wire). A new means of ‘quasi-standardisation’ or ‘standardisation by running code’ is being practised
around this protocol. In this process, a quasi-standard is defined as 'something that works' and that has been iterated and redeployed by others. Centralisation has allowed Signal developers to swiftly update the protocol in response to research and bugs, and to limit concerns about the technical competence of third-party developers standardising their protocol. However, the 'bottleneck' of centralisation also implies that difficulties and tensions have arisen in connection with some attempts to reimplement the Signal protocol, due to the lack of specifications. This chapter will examine how these attempts to 'control by design' play out in the context of the development of secure messaging's foremost protocols and applications, paying particular attention to attempts at informal standardisation as a way to 'open up' the protocol.¹

## FROM AXOLOTL TO SIGNAL: BETWEEN INNOVATION AND CONTINUITY

As we mentioned in the Introduction to this book, many actors in the field of secure messaging share a tacit agreement that the Signal protocol's Double Ratchet is currently the leading protocol for instant messaging. In order to better understand how the Signal protocol interacts with previous and potential future developments of encryption protocols, it is useful to recall briefly the historical debates around two major protocols that dominated the ecosystem for many years before Snowden: OTR and PGP.

The main problems with PGP discussed in the cryptographic community, and shared by advanced users, could be summarised according to two main issues: complex key management and lack of repudiation and forward secrecy. The crisis of 'public key infrastructures' and of the very concept of cryptographic keys and signatures was also highlighted by digital security trainer communities and international NGOs promoting privacy-enhancing technologies, such as Tactical Tech and the Electronic Frontier Foundation (Musiani and Ermoshina 2017). While still offering one of the most cryptographically robust solutions, PGP clearly faces usability challenges.

The OTR protocol started as a research project at UC Berkeley in 2002 and was first released in 2004. OTR developer Ian Goldberg described himself, in
our interview with him, as a very early PGP user and mostly an ‘email person’;
it was his student, Nikita Borisov, who drew Goldberg’s attention to the grow-
ing field of social networking and instant messaging, thus identifying a new
security gap to be filled. Ian’s description of the mission behind OTR relates
this protocol to pre-existing technologies, as a way to respond to challenges that
were not properly addressed by PGP:

Your choices at that time were either completely unprotected communication
neither encrypted nor authenticated, or PGP in which case it's confidential
and authenticated unless your key leaks in which it's not confidential and the
authentication with digital signatures leads to non-repudiation (Interview
with Ian Goldberg, May 2018).

While OTR's solution of using per-conversation keys offered good repudiation and forward secrecy, it did not permit group chat encryption as, in Goldberg's words, 'that was how instant communication worked back then: you had to be online at the same time': OTR's design was inspired by existing tools that required synchrony (e.g. Aim). However, while popular in high-risk activist communities, OTR-based applications (such as Jabber) were widely criticised for their lack of multi-device support and other usability problems.

These shared concerns were at the core of the efforts subtending the Signal
protocol, which successfully managed to address them, according to Goldberg:
‘Text Secure, and later Signal, basically took OTR protocol and added basic fea-
tures to it to make it work in an asynchronous setting.’ Using per-conversation key
material in a similar manner to OTR, it did not force complex key management
on users. It maintained properties of repudiation and forward secrecy by virtue
of the Axolotl Diffie-Hellman key ratchet, but added ‘future secrecy’ so that
messages could not be read at any point in the future in the case of a key mate-
rial compromise (Cohn-Gordon et al. 2016). It also solved the asynchronous
messaging problem by allowing longer-term pre-keys managed by the Signal
server and offered group messaging implemented as point-to-point messaging.
The Signal protocol uses the ‘Axolotl’ key ratchet for initial key exchange and
the ongoing renewal and maintenance of short-lived session keys, so there is no
long-term key that can be compromised. This provides forward secrecy so that
the compromise of a short-term key does not compromise past keys (which
would enable an adversary to decrypt past messages).

As the Signal protocol initiated a dialogue with the previous crypto protocol
‘tradition’ (mainly by addressing the aforementioned limits of OTR and PGP),
it quickly attracted the attention of the academic cryptographic community,
and only minor flaws were found (Frosch et al. 2016). Although alternative
approaches were developed and widely deployed, like MTProto by Telegram,
these protocols developed their own cryptographic primitives and so received
less attention from the academic community; additionally, a number of bugs and
usability problems were revealed (Jakobsen and Orlandi 2016; Abu-Salma et al.
2017a). Interestingly, while Signal has deeply influenced the crypto protocol field,
it did not depart from previous efforts, but drew from their well-known flaws:
it is this continuity that can partly account for the interest from crypto experts.

With minor variants implemented in the vastly popular WhatsApp mes-
senger, the core Signal protocol seems well on its way to replacing the use of
XMPP+OTR and to becoming a competitive, if somewhat ‘boutique’, feature for
mainstream messaging services (as shown by the adoption of the Signal protocol
as an option by both Google Allo and Facebook Messenger). Encrypted mes-
saging applications like WhatsApp, Telegram, and Signal² are now the default
application of this kind for users who consider themselves high risk. Usability
studies have shown that although Signal, like OTR, is relatively easy to set up
and use, even highly skilled users fail to use verification correctly. Signal is cen-
tralised, as a single server mediates the setup of the protocol in most widespread
deployments (WhatsApp, Google Allo, Facebook Messenger, Wire).

There are also open-source alternatives that claim to use the Signal protocol
or its forks, such as Wire, another centralised application, that uses a fork of
Axolotl protocol called Proteus. Parts of the Signal protocol were copied by a
draft XMPP-Foundation standard called OMEMO, for use by applications such
as Conversations and ChatSecure, which led to usage of Signal's double ratchet
in federated projects. Another decentralised project, called Matrix, has reused
parts of the Signal protocol to integrate them into their own cryptographic
library, called Olm. While Signal appears to be widely adopted and considered
an improvement over both OTR and PGP, the core Signal protocol remains officially unstandardised, even though the protocol's creators Trevor Perrin and Moxie Marlinspike have produced an informal draft after considerable 'community pressure' (in the words of Matrix.org's lead developer).

## A 'QUASI-STANDARDISATION' PROCESS

While most users we have interviewed, including high-risk users, do not appear to have standardisation as an explicit priority, developers care deeply about standards as 'something they would eventually be working on', to increase the 'dialogue' between applications and reduce the silo effect: 'In the long term I am not opposed to the idea of standardising, it's great to have a reference for interoperability' (Briar lead developer).

Standardisation is understood as a *reference* and thus as an important communication or mediation instrument, that helps members of the security community understand each other and build a ground for common knowledge (such as cryptographic libraries); it also guarantees a smoother development of new applications on top of standardised protocols. Yet a widespread discontent with existing standards bodies is expressed by developers, for several reasons. Developers underline recent transformations of these organisations, referring to a previous 'golden age' of standardising bodies, when their mode of existence was closer to that of FOSS communities. Our respondents note the growing importance of private actors as stakeholders within standardising bodies:

> My impression of the IETF is that it's not the same beast it was in the early days. There was a time when it was a group of enthusiastic people who would come to the IETF with an idea that was sort of halfway finished and they'd say look I wanna let everybody know about this, let's knock it into shape and we'll all build on it. I think it's become a much slower moving and more adversarial environment. This area of technologies has attracted more money and more corporate participation and therefore, conflicts of interest (Briar lead developer).
This institutionalisation of standardising bodies and their progressive removal from coding communities creates an environment that is less suitable for experiments and unfinished projects:

> I think that [an automated, periodical clearing out of message history] is something that we will implement, it just probably will not be standardised because the XMPP community is very conservative. I don't think... they don't fully get it. It's something that users want... so why?... I don't know. They end up in that old school stuff (ChatSecure developer).

As Callon (1986) would put it, standardisation implies the ‘translation’ of a protocol as a sociotechnical experiment into a pre-standard, able to ‘enroll’ and convince various agents within evaluation bodies. Standardisation involves collective work that opens up the core-set of protocol authors to include external experts from standardising organisations, some of them being far from users’ experiences and needs, and from the ‘real’ economy of the encrypted messaging field – a process that is hardly appealing to some developers, as it is seen as time-consuming in the early stages of project development:

> I wouldn't really think about submitting something to the IETF on an early stage these days because I think that would probably involve a lot of work to convince other people to allow it to become a standard... and obviously everybody would have their own thoughts of how better to work (Briar lead developer).

Instead, most developers share the philosophy that they would build the application first, and then focus on standardisation and decentralisation via the use of open standards:

> I used to work with W3C a long time ago and I am very aware of how they work and that they may have some limitations. We want to get Matrix as mature enough and solid and stable enough, then we can pass it over to a proper governance organization but right now it's still evolving very rapidly (Matrix.org lead developer).
In the case of secure messaging, it is still felt that more development is needed on the code, and standardisation would only slow down existing development efforts. Indeed, a new way of ‘quasi-standardisation’ or ‘standardisation by running code’ is being practised in the field of end-to-end encrypted messaging applications, around the Signal protocol. In this process, a quasi-standard is defined as something that has been previously iterated and redeployed by others with success. In this sense, all of the various Signal protocol deployments (e.g. Wire, WhatsApp and OMEMO-based apps such as Conversations and ChatSecure) work as crash-tests for the protocol, where the protocol gets forged by usage:

> I think the direction to take is [the one] Signal is taking, when you kind of build a system for a while, you iterate a bit until you think you have something that works well and then you start to document it and if other people wanna interoperate, you talk to them about standardizing on that stage, on a much later stage [...] I wonder whether they [Signal] will think about standardizing at some point, maybe the idea is about delaying it to a later stage of the project, and not about avoiding it (Briar lead developer).

The Signal protocol, characterised by the double Diffie-Hellman ratchet, is now considered the best practice in the field and has become a trend-setter for other projects in terms of privacy and security features (e.g. forward secrecy and future secrecy for example). Developers, even those working in federated (e.g. Conversations) or peer-to-peer (e.g. Briar) projects – which will be explored in Chapters 3 and 4 – see the Signal solution as one of the best designs available, despite its lack of formal standardisation – and, maybe, precisely because its standardisation is happening informally, in the ‘mundane practices’ and multiple implementations taking place in different projects.

## SIGNAL'S MULTIPLE IMPLEMENTATIONS: 'SNOWDEN MEETS THE MARKET'

The field of instant messaging applications has been deeply transformed by the different implementations of the Signal protocol, but also because of the growing
popularity of other secure messaging tools, such as Telegram, Threema or Wickr that use their own protocols. The turn to encryption has modified the market and brought considerable changes at the governance level, engaging important private sector players in the game:

> What is happening in the last two years [interview was done in 2016] is fantastic, with a number of messengers popping up and also greater publicity around Axolotl or Signal... Snowden also talking about it... So this is really good for the industry. And we've seen it's triggered even the big ones who started using encryption (Alan, Wire CTO).

Post-Snowden, one of the most important manifestations of the ‘turn to encryption’ in messaging applications has been WhatsApp’s – one of the ‘big ones’, in Alan’s words – implementation of end-to-end encryption, which became operational in April 2016 (Metz 2016). However, according to former Pirate Bay founder Peter Sunde – creator of Heml.is, an end-to-end encrypted IM application – the adoption of end-to-end encryption by WhatsApp happened for much more ‘financial’ reasons. Before being purchased by Facebook, WhatsApp’s value was estimated at 19 billion dollars. After an unfruitful attempt to purchase Sunde’s protocol, they turned to Signal and acquired the Signal protocol for 1 million dollars. After the implementation of end-to-end encryption in WhatsApp, the app was sold to Facebook for a better price of 21 billion dollars. Peter Sunde recalls:

> [WhatsApp's CEO] was upset that I and other guys [from Heml.is team] were talking about ideology and politics because he was not interested in politics. He was more interested in the government staying out of his life, and not touching him so much and so on. And he did not wanna call that ideology, which was probably the first problem we had between us. And then he said encryption is not something people care about because no one is interested in what people talk about on WhatsApp because there was nothing important. For him it was more like we need to have something because people are complaining in the media, rather than it's actually about
privacy... It was just a business thing. He has no clue what people are using his app for... I don't think he was in touch with his user base, he was more interested in user growth (Peter Sunde, Heml.is core developer).

The element of 'political ideology' raised by Peter in the above citation is another important factor that influences interactions and collaborations among different instant messaging and cryptographic projects. Our fieldwork within developer communities shows that common ideological grounds may become a crucial factor for the decision whether to adopt specific protocol choices and design decisions. We will show later in the chapter how, in the case of Wire, the importance of specific values cement F/OSS communities, and their influence on fundamental development choices.

However, in the case of Signal's cooperation with WhatsApp (and, as a consequence, with Facebook), reflections on the social consequences of the adoption of end-to-end encryption are used to justify this controversial deal, that became one of the most important collaborations in the recent history of instant messaging. Several of our respondents underline the ultimately positive consequences of WhatsApp's turn to encryption, that, according to them, has solved major problems related to its adoption costs by users. Let us recall the Ukrainian security trainer pointing out, in the previous chapter, that since WhatsApp's adoption of end-to-end encryption she recommended users to 'stay with it' if they already used it, and also high-risk users pointing out how a generalist, centralised application such as WhatsApp could in fact make activists less conspicuous than if they used an activist-targeted app.

## FORKING THE SIGNAL PROTOCOL: NON-STANDARDISATION AS A BUSINESS-MODEL

One of the most well-known and popular **forks** of the Signal protocol is called Proteus and is used by the application Wire. Wire was launched by ex-Skype developers, who desired, according to its CTO, to respond to 'one of the biggest gaps that was missing on the market, related to privacy and security'. Wire's primary targeted user group is identified as privacy-aware consumers:
Our users in the first phase are primarily consumers, who care about privacy.
[...] I like to compare passive smoking with rising awareness about privacy
when people understand how information can be misused. It's something
that needs to be spread more (Alan, Wire CTO).

As Wire is not aimed at activists or at a tech-savvy audience, but at the average user, one of its main concerns is to build a usable interface and integrate new features that will distinguish it from other end-to-end encrypted messengers. Thus, Wire supports drawings, GIF exchange, large end-to-end encrypted group chats, multiple-participant group video calls, disappearing timed messages, file transfer, and so on. A number of our interviewees have underlined the aesthetic aspect of Wire's user interface as an advantage, favouring Wire's widespread adoption as opposed to Signal. Another of Wire's selling arguments is the quality and encryption of its voice calls, as it offers end-to-end encrypted voice calls using a specific protocol based on **constant bit rate encoding**.

The underlying Wire encryption protocol, called Proteus, is a fork of Axolotl with ‘pieces that were needed to have support for the multiple devices as a standalone’ [Wire CTO]. However, difficulties and tensions have been observed around Wire’s attempts to reimplement the Signal protocol. Some of these difficulties are connected with the lack of specifications – the set of documented requirements that a product must satisfy, often considered as a first form of standardisation.³ A draft specification⁴ was produced in 2016 – as our respondents explain, not without pressure from other developer communities:

> OWS [Open Whisper Systems, the company managing Signal until 2018, now Signal Messenger LLC] did not prioritize standardizing [the protocol] both because it gave them flexibility to change it as well as allow it to be more valuable to them as intellectual property. However, they have just finished standardizing a lot of it, [...] and I think to some extent that was because of the pressure coming from community like us (Matrix.org lead developer).

So, this lack of specification obliges developers to re-code from scratch sometimes using other programming languages:
There was, I would even say on purpose, not enough available documenta-
tion. But if you wanted to develop your own implementation, you were
pushed or bullied that you have copied their implementation. [...] I was
very naive and went to Moxie last year in June and asked him to review our
implementation and we would pay him very good money for that. Instead
he said you can pay 1,5 million, and I will keep your binaries and will help
you to get the implementation going. And then I was like... yeah, exactly...
[A legal dispute happened.] And then it was just settled. He dropped his
charges, we dropped our charges and we are using Axolotl the way we do
and how we would like (Alan, Wire CTO).

One of ChatSecure's developers explains this conflict as a consequence of a
specific licensing politics that led to tampering and modifications in the legal
terms and agreements between the Signal team and other implementers:

The Signal protocol is open source under the GPL, that means you can't
integrate it into a commercial product; that's why OWS were getting large
licensing agreements from Facebook and Google and WhatsApp to integrate
without opening up all of their source code. Part of that was incompatibili-
ties with GPL and AppStore specifically. So we needed to get some of the
legal language exempted [...] Moxie needs to protect his revenue. Part of
his arguments with Wire was that they [Signal] hadn't documented Signal
protocol, so there was no open specification, so if you wanted to write a
compatible reimplementation, you would have to read the source code
which would create a derivative work, which would not allow you to use it
commercially because he would argue he still has copyright of the majority
of the work (ChatSecure developer).

The Signal developers, for their part, argue that they are concerned about the
technical competence of having third-party developers standardise or deploy
forks of their protocol ('Moxie is a very good coder, and his standards are very
high'). They are also preoccupied with maintaining the prerogative of updat-
ing the protocol rapidly enough in response to research and bugs. This makes
it possible to use the non-standardisation of the protocol as part of Signal's business model, where the expertise and specification necessary for a proper deployment of the protocol can be offered by the Signal team as a service:

> You can say OK, we will license this technology, which is not something I am interested in because I would like it to remain free software. But you can also say 'we are the people who understand this technology, it makes sense to hire us if you want to deploy it'. If people build systems on top of it, then they pay somebody to contribute changes down into that codebase (Briar lead developer).

As our interviews with users and observation of security training sessions have revealed, open source and licensing choices are less covered in sessions destined for high-risk users, as they do not always associate open source with security. Open source is often perceived as a less important criterion in the context of an immediate physical threat; when a proprietary, centralised, but 'efficient' and 'easy to explain' solution exists, trainers will give it priority. The primary task for trainers in high-risk contexts with low-knowledge users is to help them quickly abandon unencrypted tools as well as tools that collaborate with their adversaries. However, users do care about sources of funding and business models of end-to-end encrypted messaging applications, and particularly of centralised systems, due to the great authority the architecture accords to their creators. This was, and is, the case with Signal, as well; in particular, questions about business models are very frequent on the different chats about cybersecurity that we have been observing since September 2016. Users ask for transparency of funding but at the same time show a certain scepticism regarding crowdfunding models (donations) that seem not sustainable enough for an application to be properly maintained. Recent critiques addressed to Signal concern its dependence on US government funding:

> Signal was created by the same spooky regime change outfits that fund the Tor Project. The money primarily comes through the federal government's premier Internet Freedom venture capital outfit: Open Technology Fund,