Matrix Proposals need to be Encryption-First

Posted on 2021-04-17

I’m a fairly new member of the Matrix community and I have spent most of my effort reviewing Matrix Spec Change (MSC) proposals. Overall I think the proposals have been of a high quality. I have mostly left minor feedback to avoid unnecessary complexity, clarify sections, point out unspecified edge cases and simply to improve the prose of the MSC. However I have seen a (small) handful of MSCs that propose changes that do not work with Matrix’s End-to-End Encryption (E2EE), either because they require the server to see the data or leak metadata that is not acceptable to leak in E2EE rooms, without a fundamental reason. I think that these proposals would be harmful to the Matrix ecosystem if accepted without E2EE support.

I don’t mean to call anyone out. I purposely haven’t linked to any MSCs where I have raised these concerns. I simply want to write down my thoughts in a coherent manor so that I have a strong argument to reference in the future. I also hope that this will bring attention to this concern.

While E2EE is an optional feature in Matrix I think it should be a first class feature in nearly all spec changes. There are a number of reasons for this.

Why E2EE-first is Important

Privacy and Authenticity are Important

I don’t think this needs to be explained further, it is why Matrix supports E2EE in the first place. We also can’t expect users to understand which features provide strong privacy. Every feature that doesn’t support E2EE is a land mine that users will stumble upon, and usually won’t even realize that they are exposing themselves. This is harmful to users and the Matrix brand.

Features not Available in E2EE Seriously Hamper the Adoption of E2EE

While many features will “work” in E2EE rooms, but leak private information, some features outright don’t work in encrypted rooms. These are harmful in different ways.

• If a feature is available in unencrypted rooms there is less incentive to create a new specification for the same feature in encrypted rooms, slowing the rollout of features that support E2EE.
• Enabling E2EE on a room is a one-time, irrevocable operation. Once E2EE is enabled it can not be turned off. This means that users will be incredibly upset when they realize that their favourite feature is no longer available. This will lead users to either:
  1. Never enable E2EE out of (possibly justified) fear.
  2. Leave Matrix for closed ecosystems when their chat room “breaks” after an upgrade.
  3. Feel betrayed when new features don’t work in the room that they were encouraged to enable E2EE in.

Features That Work with E2EE Usually Work Without It.

In nearly all cases if a feature works with E2EE it seamlessly degrades for unencrypted rooms. For example if your feature adds content to the media store it will need to be E2E encrypted. In unencrypted rooms you can still encrypt the data and just always pass the key along with the URL. This is generally the case, the unencrypted version is just passing the key alongside the encrypted data. If desired the encryption can be skipped in unencrypted rooms but it usually isn’t necessary. In fact it may be preferred to retain the encryption. (For example currently the media store never deletes content, but a redacted message containing the key may be deleted.)

Furthermore each feature added to the spec without encryption support will require a follow-up feature implementing the same feature with E2EE support. This means that there will be multiple protocols for the same feature, encrypted and unencrypted, not only does this require more time to spec out but it also raises implementation cost and complexity for clients and servers. If we are lucky we can deprecate and eventually remove the unencrypted protocol, but now we have just wasted time and effort and while harming the Matrix experience in the meantime.

What Should We Do About It?

I think we should explicitly disallow MSCs that don’t support E2EE but could. That is every MSC should either fully support E2EE or provide a rationale why that can’t be done. Deferring E2EE support to a later MSC should not be allowed. (For example an MSC adding push rules based on message content can’t be supported with E2EE so is perfectly fine. However an MSC that allowed users to share their live location can support E2EE so it must.)

I think we should add a “Privacy Considerations” section to the MSC template. There is already a “Security Considerations” section but I think that it is a good idea to explicitly call out information leaks. I think it is important to document all new information that a MSC is exposing to a user’s homeserver and third-party homeservers. This may be seen as too explicit by some but I think that duplicating this info from the main MSC body focuses attention and helps ensure that all leaks are intentional. It breaks the “You appear to be leaking this information to the homeserver and I don’t think that is acceptable” argument into two distinct steps, “I think you are leaking this information” and “I don’t think this information leak is acceptable” leading to more focused discussions.