Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/1258 Thanks!
All right.
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 to ecosystem
is moving challenges for distributed
and decentralized technology by Moxie
Marlinspike. Have fun.
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, here's something of
the barn and it 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, Yeah,
and you know, the farmers like, Oh,
there's a Cat America, 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 Wolf.
And I was like, Oh, OK, and it's like a
dog in there.
And so, you know, the farmer starts
looking at the third potato sack.
And as it gets closer, the kid inside
says potatoes.
All right.
I'm like the Potato Kid right now, and
all those 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 in like six last
night.
I just couldn't stay up any later.
And I was like half asleep.
You know, I felt like I 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 slept all night.
This is great. You know, like, I'm waking
up at 7:15 in the morning.
That's why I like got up.
I'm like brushing my teeth and shit, you
know? And eventually you realize it's
7:15 at night.
Still.
I slept for an hour and 15 minutes, you
early.
OK, 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.
So I want to talk a little bit about
decentralized systems from the
perspective of the time I've spent
at Signal on 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 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 sit
still and has 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's 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.
And 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.
OK, we got to version one point one in
nineteen ninety seven and
we've been basically stuck there until
now.
SMTP, I.R.S.
exempt 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
I.R.S.. It's what Facebook did with
email. It's what WhatsApp did with AMP.
In each case, the decentralized
protocol is stuck in time.
But the people have 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,
and in the sense that I host my own
email, I have since
nineteen ninety six.
I wouldn't really wish it upon anybody.
Um, but I still do
it. Um, but
the fact that emails to centralize
there's 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 it's out there in the world
and making that change
is probably not going to happen.
Um, 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 not an encrypted for billions
of people by default,
and they were able to just 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 spaces, 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 something 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 larger 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 systems 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 communication, 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 know, 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 that 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 only 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.