Hey you!
Prior to transcribing, please look at your style guide: https://wiki.c3subtitles.de/en:styleguide. If you have some questions you can either ask us personally or write us at https://webirc.hackint.org/#irc://hackint.org/#subtitles or https://rocket.events.ccc.de/channel/subtitles .
Please don't forget to mark your progress in the progress bar at the talk's website.
Thank you very much for your commitment!




======================================================================






Herald: Our next speaker is the creator of Signal and 
he is going to tell you what he's doing right now. So the next talk is the ecosystem is moving - challenges for distributed and
decentralized technology by Moxie Marlinspike.

Have fun!

Moxie: Hello!

All right, so these three kids are playing around and they break into the barn of a farmer and

they're playing around in the barn and the farmer hears something in the barn and 
he comes out to investigate, so the  three kids have to hide and they see these three empty potato sacks in  the barn, so they all jump in the potato sacks. But as the farmer comes in,  they're still kind of like moving around a little bit. 
And so the farmer, you know, is investing in this situation and
he starts walking towards one of the potato sacks and
the kid inside sees what's happening and 
so he says meow and, you know,  the farmer's like 'oh there's a cat in there', okay, you know . 
and
so he starts looking at the other potato sack and, 
you know,
the kid inside sees what's going on and so he's like woof and
so the farmer's like 'okay there's like a dog in there' and
the farmer starts looking at the third potato sack and
as he gets closer the kid inside says potatoes.

I'm  like the potato kid right now. All these people who got like six hours  of sleep last night, you're doing better than me. I'm at like seven  percent, you know. 
Jet  lag is a crazy thing. I fell asleep at like six last night. I just  couldn't stay up any later and, you know, I was like hard asleep. I felt  like I had sleep forever, and so I woke up and
I was like 'Wow I slept for a long time' and 
I  looked at my phone and it said 7:15. So I was like 'Oh wow I like slept  all night – This is great!' like I'm waking up at 7:15 in the morning. 
So I like got up I'm like brushing my teeth and shit – and eventually I realized it's 7:15 at night still.
I slept for an hour and 15 minutes, you know.

Okay, so..

My name is Moxie. I work on a messaging app called Signal.

Signal is a private messaging app, but it is not decentralized. 
Which is to say that there's no like federated mesh p2p blockchain something something, 
but every now and then people are like there should be a federated mesh p2p blockchain something something.

I want to talk a little bit about decentralized systems from the  perspective of the time I've spent at Signal and the work that I've done  there and, you know,
what we're trying to accomplish. So I think, you know,
at a high level I should say that, you know,

while I work in software I greatly envy musicians, writers, filmmakers, painters... These are all people who create things and 
can really be finished forever. You can record an album today and 
20 years later you can listen to that album and appreciate it just the same.

But software is never finished. You cannot write a piece of software today like write an app and 
then 20 years later just, you know,
enjoy that app in the same way because software is part of an ecosystem and
the ecosystem is moving.

The platform changes out from under it, networks evolve, security threats are  in constant flux, the UX language that we've all learned to speak and  understand together really sits still.

And as more money time and focus has gone into this entire ecosystem the faster the whole thing has begun to travel.

The  world is now filled with rooms that look like these in buildings that  look like these that are packed to the rafters with people who sit in  front of a computer for eight hours a day every single day. And 
all of the energy and the momentum behind that means that user expectations are evolving rapidly. And 
evolving rapidly is in contradiction with decentralization.

How  is that possible? What does that mean? After all the internet is  decentralized that seems like a dynamic evolving rapidly kind of place.  But when you really look at it like the fundamentals of the internet.  That's not always the case.

For instance if you look at like IP – you know
one of the fundamental protocols of the internet – how do we get you know
how have we done with that? Well we got to the first production version of IP and
we've been trying for 20 years to get to the second production version without a lot of success. 
You know, http, okay we got to version 1.1 in 1997 and we've been basically stuck there until now.

SMTP, IRC, XMPP, DNS – it's all the same – they're all frozen in time. Circa the sort of early 1990s. 
Because  once you decentralize a protocol, it becomes extremely difficult to  change. You put it out there in the world. There's like many different  clients, different implementations, different deployments and
so making any changes becomes extremely difficult.

Meanwhile centralizing protocols has been like a recipe for success you know.

It's what Slack did with IRC.
It's what Facebook did with email.
It's what WhatsApp did with XMPP.

In  each case the decentralized protocol is stuck in time but the people  who centralized them have been able to just iterate super quickly and  develop these products that are extremely compelling to people.

So the fact that something like email is decentralized is cool in the  sense that I host my own email. I have since 1996. I wouldn't really wish  it upon anybody but I still do it. But the fact that email is  decentralized is also what means that my email is not encrypted and 
never will be because it's too difficult to change at this point. It's out there in the world and 
making that change is probably not going to happen. You know, 
by contrast WhatsApp is centralized so I don't like run my own WhatsApp server I don't have my own you know
WhatsApp data store or whatever.

But it's end-to-end encrypted for billions of people by default and 
they were able to just, you know,
roll that out with a software update.

Um, so I think this is sort of the fundamental problem that we have to deal with, right? Which is so long as decentralization means spa
ces, while centralization means movement, that decentralized environments are going to have a lot of trouble competing with centralized environments. But you know, why do we want decentralization anyway? You know, like people talk about decentralization a lot, but what is it that we're actually after? I think when you sort of break it down, the partizans of decentralization are advocating for, you know, increased privacy, censorship resistance, availability and control. These are things that I think people who are into decentralization are really kind of looking for and and hope to get out of that world. So let's look at these in turn, because these are the things that I'm interested in as well and that I would like, you know, an app like Signal to provide so, you know, privacy. We've already seen that decentralized systems are not inherently encrypted. In fact, most decentralized systems in the world are not intended, encrypted by default. And there's nothing about decentralization that makes the things encrypted, you know? And so I think advocates of decentralization have a different take on privacy, which is one of data ownership. The idea that like you can, you know, run a service yourself and that you maintain ownership of that data and those people, you know, also point out that that includes metadata not just, you know, the contents of things like messages or something, but also the metadata about them. And so in a sense that, you know, that is better than just some kind of encryption solution. But in a lot of ways, I feel like this is somewhat of an antiquated notion that it's leftover from a time when computers were for computer people. You know this, you know, I think in the in the 1990s, the sort of general thesis for people working in the space was let's develop really powerful tools for ourselves and then teach everybody to be like us. And that's not really how the world developed. You know, at the time, we sort of imagined that the internet would look 
like this, that not only would everyone on the internet be both a producer and consumer of content, but also a producer and consumer of infrastructure. And neither of those things really bore out. In reality, the internet looks a lot more like this. You know that things sort of seem to naturally roll up and converge into these like super nodes that people are making use of that people aren't all producers and consumers of content or infrastructure. So, you know, given that world, while I host my own email, you know, since the world looks like this, I don't actually have any meaningful data ownership. Even though I run my own mail server, I don't actually have any kind of metadata protection or anything like that because every email that I send or receive has Gmail on the other end of it, even though I host my own mail server, I might as well just be a Gmail customer because they have a copy of basically every email that I ever send or receive. So given that I think that the world has developed in this direction, I I feel like real data protection is more likely to come from things like intent encryption than it is from data ownership, and that things like metadata protection are going to require new techniques and that those new techniques are more likely to evolve in centralized rather than decentralized environments because centralized environments are where things tend to change. So, for instance, you know, at Signal, this is an area that we've been working on a lot. So at Signal, you know, we have technologies like private groups, private contact discovery, sealed sender. These are things that mean that, you know, the signal service has no visibility into group communication or even group state or group membership information. No visibility into your contacts or even your social graph. And no visibility into who is messaging whom. Um, so you know, looking at something like private groups, the way that group state is usually maintained is, you know, on a server, 
you have a database. And in that database, you have a record for every group. And you know, the group needs to contain information like, you know, what's the group title? What's the group avatar? What's the membership? You know, who's in this group? What are their roles? Maybe someone's an administrator or somewhat, maybe some of the group creator they want someone's like a read only group member and then, you know, maybe some group attributes like a pinned message or something like that. And you know, you know, clients can acquire this database in order to render group information for the user. And you know, given that it seems unlikely that we're going to move into a world where everyone is like running their own servers. In addition to their own clients, that just merely like, you know, putting this plaintext database in the in the, you know, on everyone's individual servers is sort of unlikely. So. You know, one thing you might think about doing is just encrypting it right where you could just have this, uh, server side database and in the database, all of the entries are encrypted with a key that is shared among group members, but that the server doesn't have any visibility into. And so, you know, that seems like a straightforward solution. The problem is that you also need a server to be able to enforce access control and basic rules, right? Like the servers should be able to look at the members of a group and determine whether a member is authorized to make changes, like to change the title or to add another member to a group or to kick someone out of the group or anything like that. But if the data is encrypted, then how is the server going to do that? So it's signal we we developed a anonymous credential scheme that allows the server to store encrypted membership lists. So the server has a, you know, a record for some random group of its members. But each member is an encrypted so the server doesn't know who the members of the group are. And then, you know,
 let's say Alice wants to add someone to a group. Alice can construct a zero knowledge proof and authenticate to the server, proving that she has a assigned credential that matches the encrypted contents of one in the group, one of the group members, but without ever actually revealing what the contents of of that record are or who she is. And then once authenticated, Alice could, you know, add another member to the group like Frank? And then once Frank gets out of the group, you can come along and and do the same thing. Where he constructs the 09 was proof and is able to prove in their knowledge without revealing who he is or the contents of this record to the server that he is a group member. And he might request the membership list. The server transmits the encrypted values to him. Then he can decrypt them locally with the key that's shared among group members and determine who is in the group and display that to the user. So this is an example of some new cryptography that we developed in order to solve this problem. And it's again like new technique in order to to offer some privacy preserving technology in a space that I think is more likely to happen in places where we can just make these changes and roll them out super easily. All of this adds up to a world where I can publish the server side state for my signal account. There's nothing in it, really. You know, even the profile data is encrypted. The only real unencrypted values here are the last seen time in in the level of precision that I connected to the signal service. And when my account was created, there's no group information about like what groups I'm in. The titles of those groups to advertisers, groups, to the other group members are my contacts aren't stored there. My social graph isn't on the service. My even my profile data is investment visible to the service. And you know, when people message me or I message people on a server doesn't have visibility to that. Meanwhile, my email still isn't 
even Antenne encrypted and never will be. But even if we did live in this world where you know the internet looks differently and everyone is both a producer and consumer of infrastructure, this P2P P2P world is not necessarily privacy preserving in itself. For instance, when we first rolled out voice and video calling and signal, we designed it so that it did establish P2P connections between the both parties of a call. So, you know, if I call somebody, I would establish a direct connection to that device. But when we deploy that, people are like, Wait a second, wait a second. Does that mean that someone can just call me and learn my IP address? I don't want that, you know? What about all the metadata here that like, you know, my ISP or, you know, someone on Wi-Fi or whatever on the same network as me, you can see who I'm calling and who's calling me like, That's not what I want. Isn't there anything you guys can do about this? Yeah, we can just, you know, ran it through a server instead. And so that's what we do in many cases. So, you know, you know, thinking about privacy, I I kind of feel like that, um, decentralized systems aren't inherently going to give us the privacy properties that we necessarily desire and that it's more likely that we can develop technology to, you know, offer what it is that people want and centralized environments. Think about censorship resistance. This is another area where I feel like the idea of censorship resistance for decentralized environments is that many things are somehow more difficult to block than one thing that if you have, like many servers, that it's harder for a censor to block access to those than it is to block access once server. And again, I feel like this is sort of like an antiquated notion left over from a different time that in today's world, if something is user discoverable, that it's also going to be a sensor discoverable in a lot of ways. But the basic idea is that like if you're and such-and-such at someth
ing dot com and something dot com gets blocked, you could just switch to something else. That's something else dot com, you know, and you can just sort of keep moving around like that. The problem is that every time you do that, you blow up your entire social graph. So, you know, if you imagine a scenario where there's a bunch of different, you know, users who you know are affiliated with a bunch of different servers that one server gets blocked by a censor that the users who can no longer access that server can switch to different servers. But the problem is this as they do that they have to be rediscovered by everyone else in the network because now they have a different address. And it's more likely that if you know one server is blocked at any given moment that you know, all servers are going to be blocked in that moment and everyone has to switch to like a whole nother thing. And at that point, you've really blown up your entire social network. Everyone has to rediscover everyone from the beginning. You're basically playing a game of Whack-A-Mole that's that's very asymmetric because every day that, you know, censors take an action to block known servers is basically like the first day of your entire social network or you're starting over from scratch where everyone has to rediscover each other all over again. So, you know, to the extent that if your strategy is sort of like bouncing around, it's actually, I think, more effective to just have one centralized service with multiple ingress points. So, you know, if you have a service and there's a bunch of users who are using that service, that if access to that server gets blocked to just, you know, spin up another ingress point, you know, a proxy or even a VPN or something like that that everyone can switch to at the moment, the people switch there, you know, it's the same kind of thing where it's like the switching strategy, but you're not blowing up your social network. Everyone has the same address and can be
 identified if it's blocked. You know, you switch to another one. Etc., etc. So you're playing a game of whack a mole, but it's not as asymmetric because, you know, the switching cost is very low. This is the kind of strategy that apps like WhatsApp and Signal have used to resist censorship attempts in most times that they've been attempted. So, you know, they'll use strategies like domain printing, which basically, you know, when clients as a technique where like a client connects to a client that's operated by some large CDM provider and, you know, does a DNS and said I lost connection with one host like, you know, some large service like Google Maps or something like that. But then the HGTV host header includes specifies a different address, which is like, you know, a proxy. And so in order to block this, like the census of block access to, you know, some larger set of services rather than just one specific service or using techniques like proxy sharding, which is basically like you set up multiple ingress points and you shard access to them to different users. So, you know, only some users can discover some access points, which means that a sensor can't discover all of the access points very quickly. And as things get blocked, you, you know, keep shuffling around. These are the kind of things that require moving quickly that like, you know, as people are trying to block access to a service that you're moving very quickly to respond. And again, moving quickly is not necessarily something that is easy and the centralized environments. So again, when it comes to censorship resistance, I feel like you're sort of more likely to see effective censorship resistance and centralized environments rather than decentralized environments. And in many cases, that's what we've actually seen. Um, and then, you know, availability. So every time there's like an outage, people are like, you should decentralize, you know, you know, you wouldn't have as many outages. But I think the
 reality is that you would just have more outages, you know, like if it's, you know, if you think about it in terms of like you have a centralized service and you want it to move that centralized service into two different data centers, and the way you did that was by splitting the data up between those two different data centers. You just have your availability because the mean time between failure goes up since you have two different data centers, which means that it's more likely that there's going to be an outage and one of those data centers at any given moment. And since you've split your data between them, you have the availability of that data. So again, I don't think availability is necessarily something that you're more likely to see a better availability and decent decentralized rather than centralized variants. And then finally control. So I think this is a really. Interesting moment. The current sort of sentiment in the world today has changed a lot. Now people sort of feel that the internet is this terrible place. And where's that? I don't think people used to feel that the era of utopianism and this vision for, you know, technology providing a better and brighter future is coming to an end. And I think a lot of that comes down to a feeling that we have a lack of control. That technology is not actually serving our needs in the way that we want it to and that we don't have any control over or agency over how that is manifest. And so I think, you know, the strategies the partizans of decentralize environments have for manifesting that control is, you know, either through this like switching idea basically, so that it's like if you have a federated environment that different services could behave differently so that, you know, if you were a subscriber of one service and your provider started to behave in a way that you felt was inappropriate, that you could just switch to a different provider but not lose access to the entire network, which, you know, I 
think has a certain appeal. But, you know, if that is true, if that is, you know, a strategy worth pursuing. I think we have to ask ourselves, why do people still use Yahoo Mail? You know, it's, uh, hasn't been updated in like ten years. They had like, you know, a massive series of security incidents. Um, it's not clear who even owns it anymore, but people are still using Typekit Malik a lot of people are still using. Why y? Because changing email is hard. Um, and I think we're it's sort of this interesting moment where, you know, switching from Yahoo to email is actually harder than switching from WhatsApp to Telegram to Signal. Because again, every time you switch email providers, you basically blown up your social network. Everyone has to rediscover your new federal identifier and that if you use a nonfederal identifier like a phone number as the basis for your social network that you know, switching between, you know, different services that aren't actually connected with each other is is actually easier than switching between federated services and the sort of notifications on your device. Your desktop becomes like the federating bridge between those networks in a way that is in some senses more effective than the federated models everywhere. The other sort of strategy, I think, for maintaining or regaining control from decentralized environments is extensibility. So this is the idea that what we can do is develop a protocol that is designed to be extended so that different people can modify this technology in ways that it feels like meet their needs. And I think, you know, the best or the most well known example of this is a protocol like SMP, which was a protocol designed to be extensible. But you know, in the end, what we ended up was ended up with was this like morass of zaps, which were the extensions. And there wasn't ever like a feeling of strong consistency, which generated a lot of uncertainty among and within the user experience, right? So, you know, 
even today, it's like you want to send a video over SMP, like, you know, it's like there's a zip for that. Like, does the recipient support that we don't know you wanna send a GIF like, you know, that's a little dicey, you know, it's like, I'm sure, you know, and none of the extensibility that's built into the protocol could actually adapt to major changes that needed to be addressed like, you know, adapting to mobile environments. Um, so I feel like in the end, like the whole extensibility thing didn't really provide the control that people wanted because those zaps were of little value until they were adopted everywhere, which is hard to do. And then, you know, even in the like pseudo distributed kind of models like bitcoin, I think that the control that people have, it's sort of interesting that the control that people are seeking has manifested in the form of forks. You know, so that when there's a disagreement, people just, you know, start a new network, you know, like, you know, Bitcoin Cash or, you know, various altcoins that you know, people take like the existing code base and just start a different service. You know, ultimately, I think that has led to like a lot of confusion in terms of, uh, you know, users that are engaging with these networks. But to the extent that people are manifesting the control that they would like to see it. It's interesting to me that it doesn't seem to have much to do with the decentralized nature of these protocols, that it has more to do with the open source nature of these projects. That because these projects are open source, it's very easy for people to take what's there and just change it and, you know, redeploy it as something else. So in a sense, I feel like that, you know, open source is sort of the best of all that we have in terms of manifesting control. But even that, I think, is like, um, it's like a difficult task because if you know what we want is for technology to to better serve us. I think we have that. The l
arger problem in my mind is that if what it takes, if what technology demands is rooms that look like this and buildings that look like this full of people sit in front of a computer for eight hours a day every day forever that it's unlikely that we're going to see technology meeting our needs in the way that we want it to. You know, all the time people have these ideas where they're like, Well, what if there was like Uber? But it was decentralized so that like, you know, the money goes to the drivers, you know, wouldn't that be cool? I think that would be cool. But if what it takes to build that is rooms that look like this and buildings that look like this with people who sit in front of a computer for eight hours a day every day forever, guess where the money is going to go. It's. Is going to go to those places, you know? So I think if we're serious about, like, you know, changing technology so that it better serves us, to me, the best thing that we can do to make that happen is to make technology easier, to make the deployment and development of technology easier. And again, decentralized systems are not the first thing that popped into my mind. When I think of easy, you know, in a lot of ways, I feel like, you know, decentralized systems make everything harder in a world where we should be trying to make things easier for people to deploy. So, you know, on the whole, I feel like, you know, these are the challenges for decentralized systems that in a lot of ways, I think that they're, you know, we need to reimagine how it is that we're thinking about technology, even though the direction of the world has gone and that we can, you know, find the solutions to these problems and the things that we're looking for in ways that are perhaps more effective than building decentralized systems. So I'm not entirely optimistic about the future of decentralized systems, but I would also love to be proven wrong. However, I feel like anyone who's working on decentralized syste
ms today needs to do so without forgetting that the ecosystem is moving in the words of Marx. We can create our own history, but only under circumstances that aren't directly transmitted from the past. Thank you. All right. You can see eight microphones in that hall and also we take questions from the internet. So if you have a question, please line up on the microphones. And the first question goes to the internet, please. Twitter wants to know if you can comment anything about post-quantum security. So, for example, there was a thesis by in a at University of Tokyo about the post-quantum single protocol question. OK. Yeah, I don't. I haven't seen this this thesis, so I can't really say anything about it. But you know, the way that things are sort of headed is, is, you know, people are trying to develop post-quantum crypto exchanges and stuff like that. The situation today is that like as we develop those things, you know, we're developing our as people develop those things. You know, we're trying to develop an increase in confidence and those algorithms. There's also a little bit of uncertainty about like whether those are like pre quantum resistance in some ways, just because things are so new. So the way that things are going, you know, people are trying to, like, take a new post-quantum change stuff and mix them into, you know, pre quantum key exchange stuff so that it's like additive security property. So that if those things turned out to have problems even in the quantum world that you're not shooting yourself in the foot. So that's sort of the direction that things are going. And, you know, we'll probably start looking at the more as those things mature. OK. As we have a lot of questions, please keep your questions short. First question to microphone number four. I thank you for the talk. I was wondering in all this overview, how you perceive the efforts and on the standard of messaging layer security of providing this base layer of end to end encrypted com
munication, which is, to my knowledge, decentralized and in its thoughts. Yeah, OK. So I think, you know, we're not actually a part of the MLS process, and MLS is like focusing on one specific scenario, which is a specific scenario within just the group messaging. I think, you know, there that's like a whole other conversation that I think, you know, that there's a lot of challenges there that they may not be thinking through. But I think that the I mean, what's interesting is that it is a sort of unique scenario in that it's like a standards process among, you know, a number of entities that don't actually communicate with each other. So it's not it's not entirely clear what having a standard the value of having a standard is since there's no real plan for these entities to federate or, you know, have some merging of their networks other than just, you know, agreeing on a set of principles for cryptography that everyone feels like are, you know, a solid thing to adopt? OK, thank you. One question from microphone number one, please. Hi, right. Thanks for that thought provoking talk. You said so many things I disagree with. It's tough to pick a question, but the one I'm going to ask is the features you have about private groups and sealed sender. Those seem to be protecting data at rest for when the servers compromised. The data that's on it is less useful to the attacker. But if the server is already compromised, it's not really providing a traffic analysis. Protection Your metadata protection is effectively a pinky promise oriented architecture, and you've outsourced the keeping of the promise to a defense contractor owned by the richest man in the world. And so my question is how confident are you that Amazon is keeping the promises that you're making? Well, I mean, you know, the purpose of a project like Signal is to get to a place where it doesn't matter, you know, like where something is hosted or whatever, you know. And so, you know, you point out that you kno
w, what we're talking about here is stored data. And you know, it's like in attacking this, this, you know, in attacking this problem, you know, I think you have to start from one place and work until you end up where you want to be. And you know, right now, like, you know, the worst thing that you can have is data in a database, you know, because like what? You know, what tends to happen on the internet now, it's like when there's data on a database that it just becomes public. There's like a lot of data dumps out in the world. So like, that's the worst possible scenario. And, you know, by design, you know, most systems are set up so that in order to function, they need to have data in a database that is at great risk. I think of, you know, ending out in public, out in the world. And so, you know, the first thing you want to do is design your system so that you don't have to have data on database. And so, you know, then. You know, what you're talking about is like traffic analysis and, you know, things like that that, you know, people can, you know, look at traffic flows in order to figure out other like, you know, metadata properties. You know, there's things that users themselves can do today to help with that, you know, they can use Tor or they can use like VPNs or whatever like that in, you know, using these systems. And then that's also where we eventually want to go and still, like, you know, keep working up the stack in order to, you know, have something that is fully comprehensive. All right. We take another question from the internet, please. I ask, wants to know, what do you think of P2P peer-to-peer solutions that also hide participants e-mail IP addresses? Sorry, for example, by exposing them only through rendezvous points like Tor nodes? Yeah, I mean, that could be cool. I mean, I think the challenge is developing. You know, the challenge is developing a system like that that is actually scalable that, you know, you know, large number of people, large 
numbers of people can use. And that accounts for the fact that the ecosystem is moving, that you can develop a decentralized thing that you're able to iterate on quickly. And so I think that is, you know, in developing decentralized systems, I feel like that is the most important question for me just in terms of, you know, the time that I've spent in the space and the work that I've done there, that I'm like much more interested in, like unique approaches to solving that problem than I am like the specifics of IP address hiding with tornadoes or something like that. OK, another question from microphone number eight, please. Apart from the US government, what countries have you received data requests from and how did you respond? I don't. We've never. The only response that we've ever issued to any subpoena or governmental request is on our website. We have a section where we post all of the, you know, request that we respond to. I think a signal that our Big Brother. And so it's only one request that we've ever responded to. OK, one more question from microphone number three at the end, please. High signal has a very big reputation as being good and secure communication tool for activists. This is also being pushed in the global south. I have the honor to work with some global health organizations. They are very suspicious of the signal, especially due to the fact that you have to provide a phone number so your location can be tracked and all sorts of other problems that everyone here is fully aware of. I would like to know why. Why is that even still a thing for Signal to provide to make people provide phone numbers while still being hyped as a secure tool for activists? I think this contradiction is the important person. Yeah, I think that's a great question. It's it's a really complicated question. So, so you know, any any social network needs any social app needs a social network. So Signal is a social app and needs a social network. And so the social network th
at we've chosen to use is the network that exists on your device already. That's user owned. That's portable. The address book on your phone. And so there's a lot of cool things about that. You know, if that's your social network, it empowers the users on a lot of ways because you can move that network with you as you go from service to service. As I pointed out, you know, moving from WhatsApp to Telegram to Signal is easier than switching from Yahoo Mail to Gmail for that reason. On the other hand, there are a lot of people who don't want to um, they don't want to be a part of a portable network. You know that they want to, you know, be they want to use signal in a way where like people can't figure out how to contact them through other means for for legitimate reasons. The challenge is that if you're building your own social network, you need to store it somewhere. Well, I think there's two challenges. One is that if you're building your own social network, you need to start somewhere. So for instance, like you know, there, there are apps that have successfully built their own social network. If you look at an app like Snapchat or something like that, you know you can create a username and most people associated with a phone number, but you don't have to. But you know, you'll notice that like if you uninstall Snapchat and you reinstall it, your social network is still there. Where was it all at that time? You know, if you drop your phone in the toilet, you install Snapchat. You still have your social network. Where was it? It was on Snapchat server, right? They have a full copy of your entire social network, social graph, etc., etc. So that, you know, so the challenge for us because this is, you know, something that we would like to provide is that if we have this alternate social network, we would need some way to make that persistent. But it's bad enough that right now, when you lose your phone and reinstall signal, you lose all of your message data because it o
nly exists on your phone. But it would be even worse if you lose your entire social graph at that moment as well, and that you have to rediscover what everyone's identifiers are. And at the same time, we don't want to just store, you know, social graph and plain text that we have access to that entire social graph. And that if signal is compromised, you know that whoever compromised Signal also has access to your entire social graph. And so, you know, the challenges in developing something that's actually privacy preserving that allows us to maintain the social graph over time. So we recently published our technology preview of something called secure value recovery that is basically the first step in order to solve this problem. The other challenge, though, is that it depends on what you mean by not provide your phone number because you know there are plenty of applications that you can use where you like you. Some alternate identifier that isn't necessarily associated with phone number, but the sort of unfortunate reality is that, you know, in all of those cases, your client is to provide to the server, either an Eskom or APN identifier, which is used to send push notifications to your device. And that is does uniquely identify your device in ways that could probably use be used to identify your whatever your phone number is. So it sort of depends on what your your threat model is there. But OK, thank you very much. I know there are a lot of more questions, but unfortunately time is over. If you want to do speaker will be around later on. You can gather up here, but the talk is now done, so give a huge round of applause for Moxie Marlinspike.