Dear viewer, these subtitles were generated by a machine via the service YouTube and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/3036 Thanks!
[Music]
all right thank you very much it's
really a full house today thank you for
coming so in this talk we're going to
talk about end to an
encryption and my name is Rafael this
Conrad uh I've been working on the MLS
protocol since the beginning I'm one of
the co-authors of the protocol and
Conrad is one of the main contributors
and also did his
PhD uh about secure protocols and has
been heavily involved also uh with an
open source implementation of
MLS so we're going to start um with a
bit of an over viw like a historical
overview of different enter and
encrypted protocols just uh to set the
stage to give you an idea why we need
MLS now why this whole thing was even
developed
um so this is a very coarse
timeline of what happened in that space
it's it's very much oversimplified of
course um so I don't need to present pgp
to this Crow I'm
sure um Email encryption and turn
encryption uh
I suspect quite a few of you still
remember the year of the record protocol
OTR um which was quite
popular the signal protocol also does
not need an introduction
anymore um and now we're talking about
MLS let's look a little bit at the the
security properties that were added to
these protocols over
time so if we start again with with
email and an encryption pgp but there
derivatives of that of course what we
had in terms of security properties was
confidentiality which essentially just
means stuff is encrypted you cannot
decrypted unless you know the secret key
and also authenticity which means you
know who encrypted something for you and
you also know to whom you encrypt
something so that's very much the
Baseline in terms of security properties
for any kind of entn encryption
the after record protocol went a lot
further um by introducing much more fine
grain security
properties uh and we're going to go into
them in detail later on so this is just
an overview at this
point forward secrecy you might have
heard of that also in the context of
Transport encryption
TLS post compromise security it's a
relatively new term for something that
is not that new um but there is a very
crisp academic definition of it
now again we're going to go into detail
of of what that means um deniability has
also been something that was introduced
with OTR as a uh more concrete
notion and then of course what you know
as the signal protocol these days but
initially that was called axotal and
then double
ratchet um so what did that do that
essentially took all these relatively
modern security properties from OT R and
made them usable in asynchronous
communication so what that means is that
OTR was a session based protocol if you
recall the old days of Skype where both
sides had to be online at the same time
for a message to go through um then OTR
would have been you know the perfect
protocol for this kind of sessions
between two PCS essentially but these
days we have smart phones and they go
offline a lot um so what we need is a
synchronous communication where we don't
don't have to rely on the other side to
actually be online uh we want the
message to arrive as soon as the other
side comes online but um the initial
sending s could be offline so this is
essentially what the signal protocol did
really really well and and brought the
the modern properties of OTR uh to
smartphones so what's missing because we
already have a lot
um what's missing is more versatility to
cover more use cases in which ENT
encryption could be used um particularly
large group chats so the the current
status quo is that entn encryption works
very well for onet toone communication
but not so much for groups they're they
exist of course you've all been using
group chats in andry Messengers but
they're essentially uh an ABS
construction on top of um one to one
channels it would also be nice to have a
fully specified standard um for inter
encryption that was the case for OTR but
not so much for signal I mean there's
some documentation but it doesn't have
the uh the level of a you know fully
specified standard you can read and then
just you know implement it and have
something that is binary compatible with
a signal
protocol um and also it would be good to
have open source implementations that
are permissively licensed um and that
can be used you know in in any kind of
setting so
um going back to the scaling and we're
going to be talking about that a lot uh
today
um if we have a graph and on one axis we
sort of you know measure how well stuff
scales and on the other one how modern
the security actually is and we have uh
Email encryption at the lower left
corner we have client fan out like
signal and like derivatives of the
signal protocol like M from Matrix and
proteos from wire Etc Al to some degree
IM message the security properties are
much more modern but it still doesn't
scale very well so um in order to make
end encryption compatible for the masses
what popular apps like WhatsApp and
messenger and also different Matrix
clients did was to use some sort of a
trade-off where the security is still
you know a bit better but not perfect uh
and it also scales a bit better but it's
it's also not perfect in terms of
scaling so what would be nice of course
would be to have something um that is
you know great in terms of security but
also scales really
well so a bunch of folks came together
uh who all had the same thoughts about
that so a lot of you know industry uh
leaders uh a lot of folks from
Academia and uh so they they you know
the industry folks brought a lot of
experience um Academia you know brought
the the precise knowledge that it's
necessary to actually build something
secure uh and that's essentially how
uh MLS was
born quickly going over functional
properties um so we want things to be
asynchronous uh unlike the OTR protocol
that is important if you cater for
smartphones and you most probably do we
want group messaging to be supported
especially for larger groups so that
they scale well we also want
Multi-Device support we no longer live
in a world where everybody has at most
One desktop PC at home we we all have
several devices these
days we want a protocol to be extensible
so that it can be adapted to different
use
cases um it should also be able to
degree at least to support Federation
and
decentralization at least to the degree
that you know it wouldn't stand in the
way of
that and last but not least it really
needs to be usable so it's no good if we
just construct something that's you know
academically is great looks fantastic on
paper but then you cannot use it because
it it forces user
um to adopt a new user experience
they're not used to at
all so going back to the MLS security
properties
um we start with what OTR and Signal
introduced and then we try to go a bit
beyond it so confidentiality and
authentication just like pgp that's the
Baseline forward secrecy post compromise
security we'll get to that in the next
slide I
think but also um um it would be good to
have something that really caters for
groups and introduces something new um
sounds a bit clunky agreement on group
State what that means is that every
member of a group of a group chat if you
will um has the same view on the list of
members for example than everybody else
that sounds very trivial um but that's
not the case typically for Signal or
Matrix or others um there's no
cryptographic guarantee that you
actually see the same people in the
room and then one more rather informal
uh property which I say informal because
it's not really uh property of the
protocol as such but if you use a a
server to relay messages that behaves
honestly you can also have something
that is very close to transcript
consistency and what that means is that
when somebody sends out a message
everybody sees the same message and a
malicious Insider cannot trick you know
people into seeing different messages
why do I mention that that's again not
the case with a protocol like signal or
OTR where you can effectively send
different messages in a group uh without
the server being able to detect that and
without users being able to detect
it so finally getting back to Ford
secrecy and post compromise security
what does that mean so um with entn
encryption in the context of messaging
we have really really long sessions as
opposed to you know TLS where you have
really short sessions of maybe seconds
or minutes at most hours here we could
have years um between two users uh same
as with pgp and with pgp if your key
leaks your encryption key um that is a
bit of a problem because then the
attacker can decrypt potentially years
worth of you know past messages and also
if the compromise is not detected as
it's often the case um you can also
stealthily decrypt going forward so we
sort of have to assume that you know
stuff can leak if we look at years so um
and we need to fix the protocol here so
that the the blast radius of such an
endpoint compromise is not too big and
that gives us these two properties like
forward secrecy means that even if there
is a compromise you cannot really go
back all the way in time you can only go
back to a certain extent and then
there's post compromise security which
is now just the temporal opposite of
that meaning uh when the compromise is
over like the key has leaked but there
is no long-term compromise of a device
then actually the device should be able
to heal itself and that property is a
lot harder to tackle because you need to
come up with new key material and you
need to send that to everybody in a
group to you know whoever you're
messaging
with so you could say that MLS is really
great when it comes to post compromise
security PCS um it it makes it so that
it actually scales well uh compared to
other protocols and because you know
that's such an important thing we made
that a sticker you can find them you
know all across the venue maybe you've
seen them
already and finally so you know with all
this sort of wish list you know how how
do we cook up a protocol what happened
there it all started with something
called asynchronous ratcheting trees and
um the idea there was to use a binary
tree uh to model group messaging and
make that much more efficient so that
was an initial idea and then um it was
refined over time the whole thing was
brought to ITF as a standardization body
which was a good pick um as a you know
as a forum to get both industry and
Academia
together and the idea was also that we
sort of mimic what tls1.3 did uh in
terms of how the development process was
approached um so uh the you know ITF
works with draft documents and
intermediary drafts were then given to
Academia for
analysis and uh which is good because
then you get some feedback and you
should actually also listen to the
feedback which is even better um so we
we went through multiple iterations
there uh so you could say we really
worked hand inhand with Academia and
that's how you should actually design a
modern security
protocol all right that was it for the
introduction and now hand it over to
Conrad who's going to talk a bit more
about the
details okay um so I want to talk a bit
about how MLS achieves the the
scalability that ra has talked about um
but before I start with that I want to
um Talk a bit how MLS um slots into your
architecture and the ecosystem um a bit
more broadly and we start with a
protocol that most of you are familiar
with um TLS and TLS slots quite nicely
between a transport layer uh TCP UDP or
UDP if you want to use dtls and um the
application layer where you have your
HTTP SMTP protocol what have you and
then in the in between you can slot in
TLS if you want to secure your PL text
on The Wire and the traffic is going to
be U authenticated using an x509
certificate which in turn is
authenticated use some using some sort
of um public key
infrastructure um and MLS is quite
similar to that it also slots into the
stack uh this time between uh the
transport encryption and if you want you
can have additional layers on top of
that so for example could be TLS and
then HTTP and then you can start in MLS
MLS in turn is authenticated using uh
credentials um which are in turn
authenticated using an authentication
Service which I'll talk about uh in a
minute and then on top of MLS you can
send your um application messages and in
contrast to TLS MLS of course doesn't
just protect the messages in the wire
but uh in an end-to-end
fashion so in terms of architecture MLS
requires two additional Services one of
them I've already just mentioned the
authentication Service and the other one
is the delivery service the
authentication Service is there to
authenticate the credentials which are
each individual MLS client uh uses to
sign MLS messages and authenticate them
to the uh to other MLS
clients and these services are less if
you think of service you can think of a
server that's running somewhere on the
network and it's doing things but in
this case the service is more of an
abstract thing where parts of the
service could also be on the client so
for example in for the authentication
Service uh this could be much like
signal where you just have public keys
and the only way you authenticate them
or do you verify them is by scanning a
QR code on the phone of your contact on
the other hand it could also be um much
more infrastructure heavy thing uh you
could use x509 uh certificates and a pki
with uh Casa and and all the bells and
whistles so both things work with MLS
MLS doesn't really care much uh what the
credential actually looks like and then
on the other hand there's the delivery
service and the job of the delivery
service is of course to deliver messages
but more crucially to ensure that all
MLS clients involved in a specific group
agree on the order of the messages that
they receive and again this could be um
uh a client side thing where you have
some sort of distributed algorithm that
allows the clients to agree on the order
of uh the agree on the order in which
they received the messages um or it
could be a server that's just in the
middle of of everyone and that takes the
message as they come and uh ensures that
everyone distributes them in a uh ensur
that everyone gets them in a specific
order okay so now let's let's see how
MLS actually achieves this scaling
properties and again we start with a
with a baseline where we construct we we
don't look at MLS yet we look at a group
messaging protocol that's built naively
out of one toone channels for example
signal channels and this is going to be
a bit simplified right I'm not going to
go too much into the details in the
interest of time uh but it looks roughly
like that as Rafael just mentioned if
Alice wants to update her uh achieve
post compromise security recover from a
compromise what she needs to do is
update her key
material and so she updates her key
material and then she needs to send the
updates to all of the other group
members in this case Bob Charlie and
Dave and um because these are one to1
channels Ellis needs to send the update
uh n times where n is the number of
members in the
group so this causes n encryption
operations and N times the cipher text
upload so if we look at MLS MLS also has
the participants in the bottom row just
like in the previous case but it also
has the support structure of additional
public keys on top such that they form a
binary tree and these um public keys
that we have in addition to the public
keys of the indiv individual members
allow us to achieve these scaling
properties so if Alice um sorry I should
go back and one crucial property of this
tree is that each participant in the
leaf knows the private key material to
all the public keys in the nodes from
the leaf of the participant to the root
of the
tree and so if Alis wants to update her
key material she doesn't have to send
the updates to to uh or encrypt the
updates to Bob Charlie and Dave
individually and instead she can encrypt
the message to the um to some of these
intermediary notes in the tree so in the
case of Bob she has to send it to Bob
directly but in the case of Charlie and
Dave she can actually send the update or
encrypt the update to the root of the
sub Tree in which Charlie and Dave are
and you can imagine if we have a much
bigger tree then um the the effect is
quite a bit more uh
pronounced okay so in in with that in
mind let's look at a bit slightly B
bigger example this is of course a bit
exaggerated but um this is kind of just
to show um what this looks like with
this one:1 based group messaging you
have a linear increase in the overhead
that you get in terms of encryption
operations and uh upload of Cipher texts
so if you have a group with 100,000
members you have 100,000 encryption
operations and Cipher Tex uploads each
time you want to update your key
material if you use something like MLS
where you have this nice binary tree
structure um it sces logarithmically and
so you end up with just 17 operations of
course this is a bit exaggerated so
let's look at a slightly more realistic
example um but in this Cas let's make it
a bit more interesting Ina if we want to
use uh a postquantum secure uh Cipher
Suite so we have a slightly more
realistic group size let's say a th and
let's say we want to use the freshly
standardized uh kyber uh 768 algorithm
to uh encrypt our key material as a cam
key encapsulation mechanism and the
cipher text size for kyber is about 1
kiloby so group size 1 1,000 1 kilobyte
update size so if you have this one to
group based on one to one channels you
have a linear fan out um payload size
and that is is uh 1 megab to upload for
each update for the participant that
sounds doable but then if you imagine a
group of thousand people and everyone
doesn't update then you also have to
download all the updates from the other
participants and you end up with a
gigabyte of download if everyone doesn't
update once and then if you want
somewhat frequent updates say everyone
updates their key material once a week
you end up with a gigabyte for a week
and if you imagine that on a smartphone
with a meted connection it's no
fun um and then if you use MLS uh in
contrast you still have to it's still
relatively expensive in terms of a
wireless connection so it's 10 K kiloby
to upload for an update but it's only 10
megabytes to download for each uh group
member if everyone does an update so
it's still not great but it's a lot more
bearable than a
gigabyte okay let's go back to uh MLS
and the tree and MLS supports a number
of operations and clearly we need the
the basic operations you need to remove
group members you need to add group
members you need to update the key
material as you as you've just seen how
it roughly works in the tree and then
you need to send application
messages and the application messages
are essentially just encrypted using you
can think of it as using the the key on
the top of the tree that everyone
knows and
um if we uh look at a remove operation
so let's say Ellis wants to remove or
has removed um Charlie then what what
happens is that the the the nodes in the
tree to which Charlie knows the key
material need to be removed from the
tree to ensure that Charlie doesn't
really cannot read messages in the
future anymore right this is another
instance where we actually need post
compromise security not just in an
adversarial scenario but just in a basic
group operation
scenario and so when we blank these
nodes that of course also means there
are no public Keys anymore and in this
way unfortunately the efficiency of the
whole thing suffers a bit I'm not going
to go into detail on how this affects
exactly the how you encrypt uh the the
updates um but you can think of it as
like the fewer of these intermediary
nodes you have the less efficient the
group
becomes luckily these uh blanked nodes
fill up again once someone like in this
case for example if Dave uh updated uh
his key material the group The sorry the
node will be filled again with a new
public key and then if we wanted to add
someone the the added uh participant
Edith would be fitted in the first empty
leaf or indeed if all the leaves are
full the tree would just be extended uh
to the right and you have again a full
binary tree with most of the leaves
being blank but again that fills up as
soon as the newly added people do update
operations and then I pass it back down
to
Rafael
[Applause]
thank
you yeah so now that you know everything
about MLS um what's next um so I
mentioned implementations
earlier um and and that's crucial if you
know if we want people to use
MLS currently we have implementations in
Rust and in C++ that are compati able
with the RFC that came out in June or
July this
year um we have been involved with one
that is called open MLS it's written in
Rust it's permissively licensed under
the MIT license and the idea behind that
was on one hand that it started very
early alongside the the development of
the protocol just to check that stuff
actually works uh and these days the
idea behind it is that it is some sort
of a community
project that is you know as useful as
possible to as many projects as possible
and we've received quite a bit of uh
code contributions already uh and it's
it's being uh used and tested uh in
different
applications uh at the same time there's
more that is in the works I think
there's a Java implementation a go one a
ruby one an fstar one uh for those who
are familiar with
that um so we think that at some point
there will be several implementations
you can pick
from what
else so um DRC is there and the MLS
working group at the ITF is currently
working on
extensions uh to the protocol so we
already talked about postquantum
resistance um that was the first one of
the first extensions that was add
um we are also looking at more efficient
um Multi-Device
support um which you can already do with
MLS as it is but there are things you
can still
optimize um and we are also looking into
um other security properties that are
not necessarily uh important in the
general setting but for more specific
applications like for example
deniability but there other things that
we're looking at so there is some
ongoing work essentially um Beyond this
Baseline that we now have with
MLS there's also a new it of working
group that recently emerged that is
called Mimi more inent messaging
interrupt um on the backdrop of the
European digital markets act um that
incentivizes uh different Messengers to
become
interoperable and um
so the idea behind that working group is
uh to standardize some of the technology
for that and MLS is one of the building
blocks um specifically for the
encryption
obviously we've also been working and by
we in conard and I uh at Phoenix R&D on
trying to see how we can build uh
privacy preserving architecture for MLS
so obviously with large groups MLS is
super useful for corporate messaging
because that's why you tend to have a
lot of large groups but not only um we
think that it would be nice if we can
embed the whole thing in an architecture
that really gives you you know uh a
reasonable degree of metadata protection
Etc so this is ongoing work I'm not part
of this
talk um but it's something that's coming
up so where can you actually see MLS or
experience MLS already um WebEx from
Cisco was the first large deployment of
MLS and actually they deployed a version
that was pre RFC um so if you've been
using webx there's an option to enable
and to an encryption and that is using
MLS um so that was a really nice um test
at scale to see how well MLS works and
then also quickly after the RFC was
published Google committed to using MLS
going forward for for Google
messages and um RCS which is
this uh yeah successor of SMS and MMS
for those who have never heard the term
so this is nice because that means there
might be very large deployments uh we
know that other large Messengers are
testing it currently but these things uh
tend to be a relatively secretive and be
mve slowly um but there might be some
news at some point
all right that's the end of the talk and
um so we'll be taking some uh questions
after that if you want to contact us
there's an email address you can also
call our colleague Julian on a decked
phone and yeah don't forget about the
stickers thank you very
[Applause]
much yeah yes don't forget about the
stickers very good call to action okay
thank you very much for your
presentation so uh there's a bit of time
for questions line up at the microphones
and there will be a bit of a bias for
the internet because they cannot be here
so we start off with the signal angel
please uh what is the current state of
adoption by matrix or
xmpp um Matrix has been looking into it
I think they even have a dedicated
website for that that is called rmls
yet.com
and so that's where they publish
updates and with
xmpp um there were talks I don't know
how far along that
is okay microphone one yes thank you for
your talk um in one of your slides you
mentioned that you took inspiration from
uh the way they did it in TLS 1 1.3 and
I'm a bit curious what that means and uh
what you have done to overcome the the
the hurdles with the yeah the
flexibility and things with the protocol
such as
TLS do you want to take that yeah I mean
so I think the first thing that was
inspired by TLS is just procedurally it
was also an ITF protocol uh a good few
people who were involved in the ITF
sorry in the TLs standardization were
also involved the the MLS one also uh
TLS 1.3 has been a success story as
Rafael mentioned in terms of how
industry and Academia have collaborated
and how there's been a back and forth
how Academia has analyzed protocol
drafts and that has influenced the whole
protocol design and the security of
course so that was one thing how it's in
one way in which is it's it's inspired
and um where MLS uses the the on a
technical level MLS uses the TLs
presentation language uh the the
serialization for for example um we
also but but and also the the the
credentials it does support x509 So in
that way it's somewhat compatible I
guess you could emulate TLS 1.3 using
MLS as a 1 to one connection but um I
think that's where the similarity ends I
don't know if you want to yeah I think
that covers it pretty much we we had the
benefit of not having these backwards
compatibility issues so we have to pass
through middle boxes and all that stuff
so
um we're lucky in that yeah I guess it's
important yeah this is about you know
TLS 1.3 and not the Odo versions
obviously that were highly problematic
for different
reasons okay thank you thanks okay is
there another question from the internet
yes uh isn't the the wire Communicator
actually a proper and compliant
implementation of the MLS
standard um you mean the the wire
messenger um I think they
committed to using mls in the future I
don't think it has been fully rolled out
yet they I mean historically um I work
there for for disclosure wi has been
using um Proteus which is very similar
to the signal protocol um
yeah okay microphone 2 please uh yeah
thanks for the talk um you talked a bit
about sending key updates uh how would
Ellis for example authenticate herself
after her key leak like authenticate the
the key update messages
that that's a good question um MLS uh
kind of punts a lot of the
authentication stuff to the uh to the
application or to the layer above if you
will that's on the one hand it's just so
it's more modular but on the other hand
it also means
that it's hard to answer the question it
really depends on how the application
chooses to manage authentication key
material so for example what you could
do in a similar way that MLS rotates uh
or or or you do these encryption key
updates using MLS you could also do
authentication key updates and refresh
your authentication key I mean that
leads to other operational uh questions
but that's kind of independent from MLS
um the authentication key management but
yeah what's within MLS of course is
signatures so MLS uses signatures to
authenticate messages but the management
of the signature Keys is out of the
scope
thanks okay how's internet doing uh yes
do you know any implementations of mls
in python or other languages and do you
encourage people to start implementing
them so I'm not aware of any
implementation in Python um I mean of
course people you know should uh
Implement that if they're up for it it's
it's always good to have you know
different
implementations um um that being said
it's also great to have really mature
implementation so as you know with you
know security protocols it's great if
they're audited and you know have uh
stood the the test of time for a bit
before you deploy them but yeah so what
I showed on one of the slides is what
I'm aware of at this point um that was
Java go
Ruby I think that's it and if anyone
wants to implement mls in python or has
implemented it uh we have an active uh
interoperability um dialogue just send
an email to the mailing list um multiple
groups are coordinating how to exchange
test vectors we have a um uh a whole um
what's it called a harness like an
interoperability harness where you can
plug in different implementations and
test how they interoperate and stuff so
if there's anyone who wants to do that
just come talk to
us okay microphone four
please yeah uh thanks for the talk um in
the slide about fan out in MLS you said
that the PCS updates uh would send to
some uh to the lowest common uh mhm uh
nodes in the tree yeah why don't just
send the PCS update to the root of the
tree that's that's a good question um if
you look at the threat model for post
compromise security with these State
snapshot compromises um then you have to
assume that the adversary so if if Alis
is compromised and Alis knows all the
secret key material up to the root
including the root
then the adversary also knows this key
material so if Ellis encrypts the new
key to the key in the root then the
adversary can just decrypt it so the
Ellis needs to encrypt the key to the
keys that Ellis herself doesn't really
know or didn't know so it needs to be
off of Ellis's path it's the what we
call the co path um okay but yeah that
that would make life a lot easier but
unfortunately doesn't quite work thank
you okay uh microphone one please uh
thank you for your great work I one
question about PCS um you mentioned that
there's this event of the compromise key
material um is it that the rotation is
only triggered when there's a non event
of compromisation or is it like
automatically done regularly and is this
this um the frequency is it bound to the
implementation of the client or is it
built in the protocol and if yes how
often is the rotation done so basically
how long is the um forward secrecy
ensured basically after the compromise
event so um yeah the the assumption is
that you cannot always detect the
compromise so the result from that is
you should do it automatically um and
that is entirely up to the application
in that sense like the protocol just
offers a possibility to do it
um but beyond that the applications
should you know Define some policy how
frequently that should be done and that
will depend a lot on you know the
constraints of the clients in what
environment that is being deployed Etc
um how much bandwidth that's going to
consume so you can sort of you know
fine-tune it and and find a trade of
that that works for you uh of course
from a security perspective uh the more
often you do it the better um is is that
kind of a best practice or some kind of
guidance that you give to
implementations like is it done hourly
daily weekly monthly so what can we
expect typically uh there is another
protocol in the working group called the
architecture document and I think there
is uh a little bit of guidance you know
in there but ultimately it's hard to you
know to give good advice in that sense
because it really depends on what you
want to achieve for some applications
it's great to do it hourly for others it
might be good enough to do it weekly um
it's hard to come up with a general rule
of thumb here okay thank you and I mean
you you're free to scale it however you
want right so if you have a big group
where updates are expensive then you say
okay it's a big group so like it's very
possible that the the content might leak
in some other way you know it's a lot of
compromise surface so it might not not
be worth updating that frequently also
because it's expensive and in smaller
groups where you have maybe more
secretive conversations I don't know
then you might update more regularly
yeah it's up to you essentially thank
you okay another question from the
internet please how is MLS Collision
resistant if multiple key updates are
sent at the same time
that's a very good question so in
general these control messages like
update add remove Etc um they have to
happen in a certain order that is the
same order for everybody in an MLs group
uh and this is uh the duty of the
delivery service to ensure this ordering
essentially um so the delivery service
has to either do that in real time and
then you know if if two members send an
update at the same time then there is
one winner one loser
or if there is no delivery service that
can do that in real time you need to
apply some logic um to you know come to
the same ordering you know offline
asynchronously so that stuff is being
applied and obviously then you you still
need to discard some of the messages so
it's it boils down to you know one of
the hard problems of distributed systems
um that you know MLS doesn't solve
obviously okay last quick and concise
question from microphone 2 please hi do
you have any interesting Insight or an
opinion about the recent Revelations
about push messages that went through
Google and apple and they turned out to
be like uh passed through to
intelligence
agencies uh yeah well we were involved
with that um there's no direct
connection to MLS uh however um so happy
happy to talk about it um it's probably
the wrong stage for it but thanks for
bringing
up okay this concludes this session
thanks again Conrad and
[Music]
Rafael