Interoperability without sacrificing privacy: Matrix and the DMA(matrix.org)
matrix.org
Interoperability without sacrificing privacy: Matrix and the DMA
https://matrix.org/blog/2022/03/25/interoperability-without-sacrificing-privacy-matrix-and-the-dma/
28 comments
The reason to re-encrypt and inject the bridged messages into Matrix is that they are then persisted serverside in a standard e2ee manner, which you can then get at from any client that speaks Matrix (or is bridged in turn to Matrix) without that client or bridge having to know anything about the original network.
So, in pidgin, you are stuck with pidgin’s UX whether you like it or not in order to access the remote network (unless you use a different multihead client). Whereas with a matrix bridge, running either serverside or clientside, you can then connect to the bridged conversations using any UX you like (of which there are now hundreds of Matrix apps of different flavours). Moreover, each chat’s history gets decentralised across any other Matrix servers whose users are participating in that conversation.
The architecture is more like bitlbee, for those who know it - but using Matrix rather than IRC as the protocol between the client and bitlbee, so the richness of the comms is preserved (rather than flattening everything to IRC).
So, in pidgin, you are stuck with pidgin’s UX whether you like it or not in order to access the remote network (unless you use a different multihead client). Whereas with a matrix bridge, running either serverside or clientside, you can then connect to the bridged conversations using any UX you like (of which there are now hundreds of Matrix apps of different flavours). Moreover, each chat’s history gets decentralised across any other Matrix servers whose users are participating in that conversation.
The architecture is more like bitlbee, for those who know it - but using Matrix rather than IRC as the protocol between the client and bitlbee, so the richness of the comms is preserved (rather than flattening everything to IRC).
Ah yes, having the client push messages back to the matrix network for later retrieval on other devices makes sense. It would however mean that the device running the bride should be either running most of the time, or that the hypothetical API of that proprietary service must be ready to be accessed from multiple clients at once, in case my home and work laptop are running at the same time, and both have a client side bridge, because usually only one of them is online.
Realistically I'd run a dedicated bridge on a home server or vps then, but I guess not everyone wants to do that.
But one step at a time I guess :)
Realistically I'd run a dedicated bridge on a home server or vps then, but I guess not everyone wants to do that.
But one step at a time I guess :)
> It would however mean that the device running the bridge should be either running most of the time
Typically a client-side bridge would run on your current device, so if it can't connect to the server, then you're probably out of connectivity anyway so it's not a disaster.
> or that the hypothetical API of that proprietary service must be ready to be accessed from multiple clients at once
I'd expect that the gatekeeper's API would allow access from multiple clients, just as the normal clients would.
> Realistically I'd run a dedicated bridge on a home server or vps then, but I guess not everyone wants to do that.
The problem is that if you run a dedicated bridge to an E2EE messenger like WhatsApp from a VPS, then that VPS becomes a massive attack target. Hence looking for safer places to run it - e.g. buried inside your phone, where if the phone is compromised, you're already toast.
Typically a client-side bridge would run on your current device, so if it can't connect to the server, then you're probably out of connectivity anyway so it's not a disaster.
> or that the hypothetical API of that proprietary service must be ready to be accessed from multiple clients at once
I'd expect that the gatekeeper's API would allow access from multiple clients, just as the normal clients would.
> Realistically I'd run a dedicated bridge on a home server or vps then, but I guess not everyone wants to do that.
The problem is that if you run a dedicated bridge to an E2EE messenger like WhatsApp from a VPS, then that VPS becomes a massive attack target. Hence looking for safer places to run it - e.g. buried inside your phone, where if the phone is compromised, you're already toast.
> I'd expect that the gatekeeper's API would allow access from multiple clients, just as the normal clients would
I'm just cynical enough to believe those gatekeepers would totally accidentally make their API as cumbersome to use as possible while still technically meeting the requirements. ;)
> The problem is that if you run a dedicated bridge to an E2EE messenger like WhatsApp from a VPS, then that VPS becomes a massive attack target.
The usual cautionary disclaimers when self-hosting apply. But probably still a less juicy target than the hypothetical bridge provider TFA outlines. Someone offering Whatsapp bridging as a service is quite a nice attack target.
I'm just cynical enough to believe those gatekeepers would totally accidentally make their API as cumbersome to use as possible while still technically meeting the requirements. ;)
> The problem is that if you run a dedicated bridge to an E2EE messenger like WhatsApp from a VPS, then that VPS becomes a massive attack target.
The usual cautionary disclaimers when self-hosting apply. But probably still a less juicy target than the hypothetical bridge provider TFA outlines. Someone offering Whatsapp bridging as a service is quite a nice attack target.
I think WhatsApp would need something equivalent to the dehydrated device on Matrix so that you could receive messages even if you're offline on all devices, I guess they're need to provide an open API for that as well?
I think overall you're mostly correct here, though you may be overlooking the fact that protocols may include features outside of the raw "send [encrypted or not] messages" and that in some cases access to those additional features is going to require support for protocol "translation"/bridges/etc.
I think they are saying a clientside bridge will relay the messages to the Matrix server, so the messages only need to be received from the external provider once, and can then be accessed on any device that's signed into the same Matrix account.
Technically, the Matrix server could also be running clientside - i.e. it could be P2P Matrix (https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix). At which point you could almost think of the architecture as being a multihead messenger, but with the protocol-specific bits decoupled from the rest of the app... and with your chat history encrypted and magically decentralised over the various participating devices.
One consequence of the DMA seems to be that people will finally be able to choose to have just one account on the one messaging service they like, and use that to connect to anyone else, no matter what services those contacts use.
Does P2P Matrix take things a step further, though, potentially allowing people to have zero accounts, and just having a private key file on their device (or synched between multiple devices) and a display name of their choosing?
Does P2P Matrix take things a step further, though, potentially allowing people to have zero accounts, and just having a private key file on their device (or synched between multiple devices) and a display name of their choosing?
> potentially allowing people to have zero accounts, and just having a private key file on their device (or synched between multiple devices) and a display name of their choosing
Isn't that what an "account" ultimately is? You need a way to tell the server – "route all messages to and from me using this identifier". That ID can be a display name, or a phone number (like WhatsApp), or email or whatever else. And the server has to persist that ID on their end and associate it with your current session.
Isn't that what an "account" ultimately is? You need a way to tell the server – "route all messages to and from me using this identifier". That ID can be a display name, or a phone number (like WhatsApp), or email or whatever else. And the server has to persist that ID on their end and associate it with your current session.
Yes, but I think I was imagining a world without servers.
For example, you could update your IP address (for people to contact you at) by sending a signed message to a global DHT, or, for more privacy, put the address of your current rendezvous server in the DHT instead. The rendezvous server would be responsible for forwarding incoming connections to you, which you could refuse based on the public key of the initiator.
If the rendezvous server only stores a lookup between your public key and IP address, perhaps only in memory, for a few hours, before you switch to a different rendezvous server, that doesn't feel like having an "account" on a server.
For example, you could update your IP address (for people to contact you at) by sending a signed message to a global DHT, or, for more privacy, put the address of your current rendezvous server in the DHT instead. The rendezvous server would be responsible for forwarding incoming connections to you, which you could refuse based on the public key of the initiator.
If the rendezvous server only stores a lookup between your public key and IP address, perhaps only in memory, for a few hours, before you switch to a different rendezvous server, that doesn't feel like having an "account" on a server.
yup :>
The biggest question mark in this entire DMA ruling is identity federation. If I am using a messaging app, and want to connect with someone who may be on any other service, is there going to be a reliable way to broker this initial exchange or will I have to specify an explicit (service, user identifier) pair, with each service managing their set of users on their own?
No? Why? Identity is as non-issue as it gets. Of course you will have to specify a service and user identifier pair. Why on earth would anyone ever want it any other way?
Decentralized identities are messy. They only work in cryptobros' dreams. You can't rely on an average person to store a private key. In real life, account recovery is a hard requirement for an identity system, as is the ability to revoke access for someone who has broken into an account.
Decentralized identities are messy. They only work in cryptobros' dreams. You can't rely on an average person to store a private key. In real life, account recovery is a hard requirement for an identity system, as is the ability to revoke access for someone who has broken into an account.
It's like an email address. I've used pidgin, trillion, meebo. I had to know what service a friend was on, generally they'd ask if I had whatever client they originally used to talk to people online with, and went from there.
I may have misread your intent, but honestly I don't see how "user directory" and "privacy" interoperate. What matrix does is maybe prove that you're talking to someone who has access to the same hardware, if not the same person, when you message the same user.
I don't shill for matrix, but I also try to use mastodon to have regular human conversations and I couldn't tell you what service everyone is on...
I may have misread your intent, but honestly I don't see how "user directory" and "privacy" interoperate. What matrix does is maybe prove that you're talking to someone who has access to the same hardware, if not the same person, when you message the same user.
I don't shill for matrix, but I also try to use mastodon to have regular human conversations and I couldn't tell you what service everyone is on...
imagine if we were discussing email today. "how can you know beforehand the email id exists and is owned by the intended person" ? then we would be forced to set up a "to contact with this person, click this link to confirm the secure channel" and other shenanigans
Yeah. this is the elephant in the corner of the room. One solution could be to use logically centralised but physically decentralised identity mapping servers (a bit like DNS root servers, or X.509 root CAs) - like the ones Matrix already runs: https://matrix.org/legal/identity-server-privacy-notice-1#2-... - but these end up being a massive toxic stash of personal data. On the other hand, it's not much worse than the current identity databases that Facebook etc maintain.
Another bet could be to let the owner of the identifier (your phone provider, in the instance of a phone number) track what service that identifier points to - like ENUM DNS. But that falls foul of political problems (and risks becoming centralised too).
Federated/decentralised identity is a problem we're actively working on at Matrix, and the DMA will only act to speed up the process, as it's indeed an important piece for this to work well in practice.
Another bet could be to let the owner of the identifier (your phone provider, in the instance of a phone number) track what service that identifier points to - like ENUM DNS. But that falls foul of political problems (and risks becoming centralised too).
Federated/decentralised identity is a problem we're actively working on at Matrix, and the DMA will only act to speed up the process, as it's indeed an important piece for this to work well in practice.
> Federated/decentralised identity is a problem we're actively working on at Matrix
Is there a good place to follow this?
Is there a good place to follow this?
Forcing open APIs for messaging services is a great thing. Let’s hope it won’t be as gimped as PSD2 ended up being for open banking APIs.
Out of the suggested options the client-side bridge sounds best to me! It wouldn’t necessarily be always on when used on mobile devices (background apps tend to get shut down) but at least it could sync once you open the app.
And a home computer bridge that’s mainly on (or VPS/lambda for more advanced users) would be great too and in sync most of the time.
Exciting stuff for Matrix.
Out of the suggested options the client-side bridge sounds best to me! It wouldn’t necessarily be always on when used on mobile devices (background apps tend to get shut down) but at least it could sync once you open the app.
And a home computer bridge that’s mainly on (or VPS/lambda for more advanced users) would be great too and in sync most of the time.
Exciting stuff for Matrix.
Would be nice if E2E stuff was more like OTR, then there would be zero re-encryption needed.
Then you would be stuck with it only covering text message bodies (or binary blobs), rather than arbitrary structured content (voip signalling, location share data, reactions, etc). You’d also have to figure out how to map the key management and crypto identity over somehow, which would then be equivalent to forcing (say) WhatsApp to throw away their current key management in favour of an OTR like thing. At which point you might as well go the whole hog and just speak something like Matrix natively.
Does the DMA cover more than text message bodies? Do you really have to protect something like presence end to end? Would arbitrary translation of every possible type of information be possible?
I think implementing just the e2ee part of the WhatsApp protocol (which happens to be the Signal protocol with open-source libraries available) client-side and have a server-side bridge transport the encrypted messages over to WhatsApp and vice-versa is a sensible option not mentioned in that blog post. Yes, worst-case it means that for interoperability you have to create a bunch of message encryption routines. But we are effectively talking about iMessage and WhatsApp - Facebook Messenger doesn't do e2ee and no other company that built a widely used personal IM system is big enough to be covered by DMA.
Regarding moderation and spam: I think a company with €7.5B yearly revenue should be reasonable able to build something such that moderation and spam prevention are also possible with federation. Google already does a pretty decent jobs in spam filtering with e-Mails, I guess they should be able to do something similar with IM.
Regarding moderation and spam: I think a company with €7.5B yearly revenue should be reasonable able to build something such that moderation and spam prevention are also possible with federation. Google already does a pretty decent jobs in spam filtering with e-Mails, I guess they should be able to do something similar with IM.
The post did mention this:
> We could run the bridge somewhere relatively safe - e.g. the user’s client
What is the advantage of having a server-side bridge then? Just do everything client-side.
> We could run the bridge somewhere relatively safe - e.g. the user’s client
What is the advantage of having a server-side bridge then? Just do everything client-side.
Clientside bridges are hard to run as mobile OSes don’t like background apps due to the risk on battery life. So if you installed a little shim WhatsApp client which speaks to the newly open WA APIs and relays everything back and forth to Matrix, getting it to run reliably could be fun.
The complexity of a whole protocol and running a client for it (which is effectively what you are doing when running bridges locally) is much higher than just doing the necessary part (e2ee) on the client.
Also, you might be unable to run such bridge in a web client because the protocol is not based on cors-enabled http/websocket APIs.
I see, thanks.
At that point, why even re-encrypt? Passing messages from one process to another, or maybe even within the same process probably doesn't require re-encryption. You could even cut out the whole protocol translation and just write a multi-protocol client like pidgin, trilian et al back in the day. Or am I missing something obvious here?