[HN Gopher] Interoperability without sacrificing privacy: Matrix...
___________________________________________________________________
Interoperability without sacrificing privacy: Matrix and the DMA
Author : vanburen
Score : 101 points
Date : 2022-03-25 17:35 UTC (5 hours ago)
(HTM) web link (matrix.org)
(TXT) w3m dump (matrix.org)
| iforgotpassword wrote:
| > There's a bunch of work going on already in Matrix to run
| clientside bridges, so that your laptop or phone effectively
| maintains a connection over to iMessage or WhatsApp or whatever
| as if it were logged in... but then relays the messages into
| Matrix once re-encrypted.
|
| 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?
| Arathorn wrote:
| 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).
| iforgotpassword wrote:
| 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 :)
| Arathorn wrote:
| > 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.
| iforgotpassword wrote:
| > 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.
| SheinhardtWigCo wrote:
| 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.
| Arathorn wrote:
| 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.
| dane-pgp wrote:
| 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?
| paxys wrote:
| > 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.
| dane-pgp wrote:
| 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.
| Arathorn wrote:
| yup :>
| clmay wrote:
| 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.
| larma wrote:
| 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 EUR7.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.
| paxys wrote:
| 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?
| Arathorn wrote:
| 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.
___________________________________________________________________
(page generated 2022-03-25 23:00 UTC)