Matrix: a new specification for federated realtime chat [LWN.net]

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 15:04 UTC (Thu) by droundy (guest, #4559)
In reply to: Matrix: a new specification for federated realtime chat by Arathorn
Parent article: Matrix: a new specification for federated realtime chat

> We do have good support for decentralised ACLs however - we absolutely stop unwanted users from joining private discussions, by supporting invite semantics, and decentralised ACLs where users must quote the historical events that prove that they have permission to join a room (or do some privileged action in the room). This is all relatively mature now, but is a very seperate problem from encrypted messaging.

How does this work without ecrypted messaging? I.e. how do you prevent a user from running his own federated server that lets him read the messages in private rooms? Or are you only saying that you can prevent unauthorized users from chatting in a private room? That seems much less important to me than unauthorized listening.

to post comments

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 17:51 UTC (Thu) by Arathorn (guest, #101018) [Link] (2 responses)

Currently messages are stored in plaintext (or plaintext-equivalent) on servers, so yes, it's trivial for a malicious server admin to sniff conversations. Just like IMAP or or NNTP. It's worth noting that the conversations are 'only' stored on the servers which participate in a given room and aren't replicated arbitrarily (unlike NNTP, for instance).

To actually secure your conversation, you either need to use application-layer crypto (like PGP or OTR), or wait for us to define our 'official' end-to-end encryption semantics (using something like Axolotl). Obviously proper privacy guarantees are critical to Matrix's success, but whilst we've considered it in the design from day 1, we just haven't implemented it yet.

Seperately from the encryption question we have decentralised ACLs to stop users 'breaking into' private rooms and reading their history, as already discussed. The distinction is between protecting against inappropriate access to private data through legitimate channels (i.e. the Matrix HTTP APIs), which is a relatively hard problem in a decentralised world - and then seperately protecting against inappropriate access to private data through compromised/malicious servers (which is what end2end crypto is for).

Matrix: a new specification for federated realtime chat

Posted Feb 16, 2015 9:16 UTC (Mon) by gmaxwell (guest, #30048) [Link] (1 responses)

I think building a new communications tool which doesn't integrate end to end encryption with the participants -- (even just 'authorized channel users', in the context of channels where participants may be ambiguously defined) is really unwise and maybe even arguably unethical.

> Obviously proper privacy guarantees are critical to Matrix's success

Glad to hear it, but that it isn't in there from day one suggests that you believe that other functionality is more critical. I hope to see improvement in this area.

Matrix: a new specification for federated realtime chat

Posted Feb 16, 2015 9:28 UTC (Mon) by Arathorn (guest, #101018) [Link]

In the end it's a matter of pragmatism. We have designed the whole system to support e2e crypto (i.e. the servers never nake any assumptions about being able to read inside oayloads for routing/filtering/etc) . We just haven't got around to defining the implementation yet. (patches welcome!)

In the end, we want Matrix clients to be as trivial and tiny as possible - eg IoT connected devices talking trivial HTTP. That simply means not mandating HTTPS on the client/server API. Obviously one will be able to define rooms which are E2E only, and then you get best of both worlds.

I sympathise with the idea that "creating an unencrypted protocol in this day and age is unethical". But in the end I also like choice. If you as a user want to mandate crypto (once e2e has landed), you can. And if you as a user want to support lobotomised clients at the expense of privacy, you can too. Everybody wins.