Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.
MSC Status
New MSCs:
MSCs in Final Comment Period:
Accepted MSCs:
- No MSCs were accepted this week.
Closed MSCs:
Spec Updates
Other than spec text fixes in the matrix-spec repo, the Spec Core Team has mainly been focusing on push notifications, push rules and generally improving notifications across Matrix. This includes improving behaviour such as accidentally notifying someone when you mention their name, accidentally notifying people when you reply to a message, accidentally notifying when you edit a message and so on. The relevant MSCs are MSC3958, MSC3873, MSC3966 and MSC3758.
In addition, review of MSC3575 (Sliding Sync) and other sliding sync MSCs saw some in-depth review from Nico.
Random MSC of the Week
The random MSC of the week is... MSC3013: Encrypted Push!
When you get a push notification for a new message on your phone, you may wonder how that message travels from your homeserver to you. Typically it isn't done directly - instead, when you receive a message that should notify you, your homeserver will generate a push notification specifically for you, and send this off to a Matrix Push Gateway. That Push Gateway is then configured to send your notification off to a service which knows how to route it to your device. This is usually Apple's Push Notification Service in the case of iOS devices, or Google's Firebase Cloud Messaging service in the case of Android devices (though FCM supports iOS devices too!). Your phone's OS will keep a consistent connection to one of these services if an app has registered for push notifications, and thus you can receive notifications from apps even when your Matrix client is not running.
But doesn't that leak all of your message notifications to Apple or Google? 😱 Not quite. While clients can choose to include all contents of a message in a push notification, most instead opt for only including the event's ID. When the push notification containing that event ID reaches your phone, it wakes up a small portion of your Matrix client which goes and fetches the full message content from the homeserver (plus encryption keys if the message needs to be decrypted). This way, you can still get a notification without your Matrix client needing to be open all the time. However, some metadata (such as when you are getting a notification) is still leaked to Apple/Google. Since the third-party service knows the event ID, it can correlate which users are in the same room by cross-referencing event IDs in notifications across multiple users.
It's also a bit of a resource drain that the client needs to go and talk to the homeserver to fetch the full event content. Ideally we'd just include it all in the notification - but then we end up sharing too much information with the push provider!
This MSC proposes a solution; encrypt the message content and send that in the notification! Message contents are encrypted using a public key provided by the client to the homeserver when registering for push notifications. The ciphertext passes through the Push Gateway (which may be run by a separate entity to your homeserver) and the Push Notification service (run by Apple, Google, etc.) and then finally down to your client where it is decrypted without the need for a web request as the private key will just be stored in the client.
And since a separate encryption key is being used per-device, ciphertexts of the same event will differ when encrypted for different users - eliminating the Push Gateway/Push Notification Service from being to correlate notifications across users (timing attacks are still possible, but this can be reduced by introducing a small amount of jitter into when notifications are sent out).
Anyhoo, if you're big on privacy (or security against those running Push Gateway/Notification Services), check out this MSC!
