[messaging] Matrix.. is Federation at odds with Privacy?

Matthew Hodgson matthew at matrix.org
Thu Apr 16 07:36:23 PDT 2015

On 16/04/2015 13:18, carlo von lynX wrote:
> What I consider relevant to this mailing list concerning
> Matrix is the way it sticks to the old server-based
> federation model.  I have collected some criticism about
> federation in
> 	http://about.psyc.eu/Federation
> and dare to assert that Federation is by definition at
> odds with Privacy, in particular metadata privacy. All
> of these technologies should look at ways to shift the
> power away from the large surveillance honeypots called
> servers towards the many harder to infiltrate private
> devices and home systems.
> Matthew stated that federation is necessary in order to
> be backwards compatible to legacy 3rd party systems such
> as XMPP, IRC, Google or Facebook. I highly doubt both
> the idea that backwards compatibility is a goal worth
> abandoning metadata privacy for and that a distributed
> system using anonymous routing would not be able to run
> a few commodity gateways to legacy infrastructure, maybe
> reducing the quality of anonymity in the process - but
> never as much as throwing it to the bin in the first place.

To try to clarify my side of this a bit more: in the current incarnation 
of Matrix we have indeed not tried to solve the metadata privacy problem 
at all.

We very consciously sat down in the initial design sessions in May 2014 
and descoped it, with the attitude that folks who want a 
pervasive-surveillance-proof solution should use a system designed to do 
just that - e.g. GNUnet/PSYC2, Tox, or whatever.  Our concern was more 
about providing a pragmatic solution that could be used to defragment 
today's current populous communication silos: Facebook, WhatsApp, 
Hangouts, the PSTN, Lync, all the emerging WebRTC-based comms solutions, 
IRC, XMPP, SIP, IAX, etc.  This is why Matrix is called Matrix: it's 
trying to matrix together all the existing comms silos into a relatively 
decoupled higher-order network.  And at each foreign network interface, 
we have no choice but to expose metadata.

This said, I am not convinced that Matrix is undermining projects like 
GNUnet/PSYC2 - and it could in fact act as a way of letting users 
migrate more easily to fully surveillance-proof systems in future.  For 
instance, one could run Matrix servers on top of an anonymous-routing 
overlay network and switch to obfuscating/decentralising conversation 
metadata from individual servers.  Those rooms could be configured not 
to federate, thus providing a secure enclave for those who want it.  Or, 
more likely, one could devise a decentralised migration system to move 
chatrooms from Matrix into actual GNUnet/PSYC2 or similar (at the 
expense of 3rd party federation).

I suspect the problem here essentially boils down to a philosophical 
one: Matrix doesn't dictate usage patterns for users - we believe in 
giving users/developers choice.  If you want to store unencrypted data 
in Matrix, that's fine.  If you want to use e2e crypto, that's fine too 
- you configure your room to lock out folks from clients or foreign 
networks who can't speak the right e2e dialect.  If you want to to be 
immune to metadata surveillance, then use something that does that 
(perhaps bootstrapping from Matrix into GNUnet/Tox/whatever, or were 
Matrix to ever support metadata-privacy itself, using a room which is 
locked down by its very nature to native-Matrix clients in a 
metadata-private enclave).

Expecting that users should jump directly into a new 
total-privacy-secure ecosystem with little interoperability/federation 
with current technologies feels well-intentioned but impractical.  Just 
as the world might be a significantly better place if everyone suddenly 
started speaking Esperanto, in practice it's just not going to happen. 
So in the short/medium term, at least, we should invest some time in 
considering evolutionary approaches as well as considering the utopias 
of the future.


Matthew Hodgson

More information about the Messaging mailing list