This Week in Matrix 2023-03-31

31.03.2023 20:54 — This Week in Matrix Thib
Last update: 31.03.2023 20:26

Matrix Live

Dept of Status of Matrix 🌡️

uhoreg announces

Messaging Layer Security approved by the IETF

The IETF has approved Messaging Layer Security (MLS) for publication. MLS is an end-to-end encryption method designed for group messaging. We have been working on integrating a variant of MLS into Matrix. Keep an eye out for demos in the near future.

Dept of Spec 📜

Andrew Morgan (anoa) [GMT-8] says

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:

Closed MSCs:

  • No MSCs were closed/rejected this week.

Spec Updates

Last week we mentioned that we'd have more to share this week about an easier API for accessing rooms in Matrix, and while it was our intention to have an MSC out by now, our priorities shifted slightly after the MIMI working group session at IETF 116. Some exciting news on that front though: our proposed easier API, called Linearized Matrix (apologies to all the mathematicians), is very much in line with what the working group is thinking about. So much so that we're going through the effort of writing up Matrix as a series of proper Internet-Draft specifications.

We don't currently have an up-to-date document which covers Linearized Matrix completely, but the short version is it allows a server to support individual rooms being linear arrays instead of DAGs. This doesn't prevent a DAG-capable server from joining the room and speaking full-blown DAG either, which is particularly important for compatibility with the existing Matrix network. Currently our efforts on Linearized Matrix are in implementation rather than documentation, though once things are slightly more stable we'll be getting an MSC out there for everyone to review more easily. Watch this space for news.

Following IETF 116, we have an immense amount of work ahead of us to define Matrix as the standard for interoperable chat, but we're well on our way on getting through it all. Namely, we're going around and mapping Matrix's functionality onto MIMI's concepts, defining Matrix as a proper IETF standard along the way. The expected outcome of this for the implementation authors of Matrix is a spec that is significantly easier to follow, finally.

For an idea of what's ahead, here's what the SCT will be looking at over the next several months:

  • Linearized Matrix (implementation & MSC)
  • Extensible Events (at least the core types) - this will serve as the basis for an interoperable messaging format in our IETF drafts
  • Decentralized MLS & interoperability of crypto
  • Clarification gaps and bugs in the current spec
  • Pseudonymous user IDs and account portability
  • Almost certainly something that was missed when writing this list

Considering the above list, the Matrix 2.0 objectives (sliding sync, OIDC, native VoIP conferencing, and faster room joins), and the core team's work around mentions, abuse reporting, and more, the SCT will be a bit busy. That said, if you have MSCs you think we should be looking at, let us know in the #sct-office:matrix.org room. We've recently started doing our weekly planning in that room too, which should help give an idea for what the SCT is expecting to look at each week.

Random MSC of the Week

The random MSC of the week is... [WIP] MSC2966: Usage of OAuth 2.0 Dynamic Client Registration in Matrix!

This MSC provides a mechanism for implementing Dynamic Client Registration (RFC 7591) for OAuth 2.0 between Matrix clients and homeservers. Without this, homeserver admins would need to manually configure OAuth metadata (Redirect URIs, application names, client secrets, and more) for every Matrix client that wanted to connect to the homeserver. Since that doesn't really scale in an environment that allows anyone to use any client they like, dynamic registration is critical! Dynamic registration allows clients to communicate this metadata to the homeserver at the login/registration step.

MSC2966 is part of a series of MSCs that add first-class OpenID Connect (OIDC) support to Matrix. You can see an overview of the related MSCs (here) and https://areweoidcyet.com/ for the latest progress on integrating OIDC into the Matrix spec!

Continue reading…

Security releases: matrix-js-sdk 24.0.0 and matrix-react-sdk 3.69.0

28.03.2023 00:00 — Releases Denis Kasak

Today we are issuing security releases of matrix-js-sdk and matrix-react-sdk to patch a pair of High severity vulnerabilities (CVE-2023-28427 / GHSA-mwq8-fjpf-c2gr for matrix-js-sdk and CVE-2023-28103 / GHSA-6g43-88cp-w5gv for matrix-react-sdk).

Affected clients include those which depend on the affected libraries, such as Element Web/Desktop and Cinny. Releases of the affected clients should follow shortly. We advise users of those clients to upgrade at their earliest convenience.

The issues involve prototype pollution via events containing special strings in key locations, which can temporarily disrupt normal functioning of matrix-js-sdk and matrix-react-sdk, potentially impacting the consumer's ability to process data safely.

Although we have only demonstrated a denial-of-service-style impact, we cannot completely rule out the possibility of a more severe impact due to the relatively extensive attack surface. We have therefore classified this as High severity and strongly recommend upgrading as a precautionary measure.

We found these issues during a codebase audit that we had previously announced in an earlier security release of matrix-js-sdk and matrix-react-sdk. The earlier release had already addressed a set of similar vulnerabilities that were assigned CVE-2022-36059 / GHSA-rfv9-x7hh-xc32 and CVE-2022-36060 / GHSA-2x9c-qwgf-94xr, which we had initially decided not to disclose until the completion of the audit. Now that the audit is finished, we are disclosing those previous advisories as well.

This Week in Matrix 2023-03-24

24.03.2023 20:45 — This Week in Matrix Thib
Last update: 24.03.2023 20:33

Matrix Live

Dept of Spec 📜

Andrew Morgan (anoa) says

MSC Status

New MSCs:

MSCs in Final Comment Period:

Accepted MSCs:

  • No MSCs were accepted this week.

Closed MSCs:

Spec Updates

The Matrix.org Foundation (mostly Travis) are beavering away preparing for the MIMI meeting at IETF 116 this weekend! This is part of our continual work to contribute to a IETF standard that can be used for interoperable messaging between gatekeepers (large companies in the chat world) under the EU's Digital Markets Act. See our earlier blogpost for more context on this topic.

In terms of our previous proposals on this subject; it turns out that implementing full-scale DAGs is a bit difficult, particularly when aiming to achieve interoperability on a short timeline. So we've been working on building an API surface for Matrix which makes rooms easier to access/implement in chat settings. We unfortunately don't have much to share today, but keep an eye on next week's TWIM for details 👀

Random MSC of the Week

The random MSC of the week is... MSC3480: Make device names private!

This MSC proposes hiding device names from any other user, while still allowing your own devices to see the names of the others.

You may question why device names being shown to other users was considered a good idea at all in Matrix. Initially these being public was really useful for verifying the devices of other users! Back in the days before cross-signing (where you only need to verify another user once), you had to verify every one of your friend's devices from every one of your own devices. It was an n * m problem, whereas if you had 4 devices, and your friend had 5, you'd need to do 20 verifications! And 4 more if your friend got a new phone!

So having device names back then were handy, but today any justification is moot and they're just a metadata leak. So we should get rid of them!

This MSC is blocked on a proven implementation. I actually wrote one up for Synapse a little while ago, and I plan to polish and merge it soon. Anyone else is free to do so in the meantime as well (just let me know first if you plan to do so in Synapse :).

Here's to improved privacy by default in Matrix!

Continue reading…

This Week in Matrix 2023-03-17

17.03.2023 20:53 — This Week in Matrix Thib

Matrix Live

Dept of Spec 📜

Andrew Morgan (anoa) reports

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 merged this week.

Closed MSCs:

Spec Updates

The Spec Core Team has started to publish their weekly list of MSCs to focus on reviewing in the Office of the Spec Core Team room. The list consists of the MSCs that are ready for immediate review, and would most help advance the Matrix protocol on any given week. This used to happen internally (they started out as weekly ping by a bot, and then slowly became curated by our resident human, Travis). But the idea to publish the list both allows people to easily follow along with what they're doing on a weekly basis (much like these posts, but in real time!), as well as helps push subsequent discussion to public channels.

Otherwise, Travis continues to be hard at work integrating Matrix into the IETF process. MSC3923 - initially published in November 2022 - was proposed for FCP this week (and has nearly passed!). Additionally, MSC3977 was published this week and talks about how Matrix is a great fit for the goals of the IETF's MIMI working group.

This is all ahead of the IETF 116 event which starts on March 26th. The Matrix.org Foundation will be attending remotely.

Random MSC of the Week

The random MSC of the week is... MSC3735: Add device information to m.room_key.withheld message!

This MSC proposes adding a new field, from_device, to m.room_key.withheld messages. This to-device message type is used to inform devices why a megolm session was not sent to them after they requested it.

Devices can request megolm sessions from multiple devices at once, but upon receiving a m.room_key.withheld message from one of them is currently unable to tell which of the devices responded with that message.

The proposed from_device field should not be added to m.room_key.withheld messages that are sent outside of key request flows.

Continue reading…

The DMA Stakeholder Workshop: Interoperability between messaging services

15.03.2023 00:00 — General Matthew Hodgson

A few weeks ago we found ourselves in Brussels to participate in the second stakeholder workshop for the Digital Markets Act (DMA).

The DMA is new antitrust/competition regulation from Europe which came into force in November, whose objective is to make digital markets more competitive by forcing gatekeepers (i.e. large tech companies) to reconsider some of their anti-competitive or self-preferencing practices. Gatekeepers are defined as companies which have a clear position of influence in a given market (based on revenue / market cap / number of users thresholds), and “an entrenched and durable position”. The process for designating which companies count as gatekeepers will start in May 2023.

The DMA touches upon different key topics, from self-preferencing behaviour to app store management practices - but most importantly includes interoperability for “number-independent interpersonal communication services” (NIICS), otherwise known as chat and voice/video calling and conferencing services (social media was left out for now).

This particular workshop was focused on the latter: interoperability between messaging services, with the aim of getting the different stakeholders of the industry in the same place to discuss how the legislation could be implemented. The whole idea is to figure out a practical way in which WhatsApp could interoperate with iMessage, Google Messages and others, creating an interoperable communication network where users are no longer locked into communication silos and pick their preferred service provider without compromising on who they can talk to.

About 900 people participated online, and around 80 people were present in person: the maximum the room could hold. It was particularly fun to see representatives from the whole industry turning up in person, including folks from XMPP, MIMI (the new IETF working group on messaging interoperability), MLS, us from Matrix obviously (alongside Matrix ecosystem representatives from Beeper and NeoChat!) - all together with the Body of European Regulators for Electronic Communications (BEREC), civil society representatives (like the Federation of German Consumer Organisations (VZBV) and European Digital Rights (EDRi)), mobile network operators, local network agencies, and obviously some of those who are likely to be designated as gatekeepers, such as Meta, Apple and Google.

Continue reading…

This Week in Matrix 2023-03-10

10.03.2023 20:36 — This Week in Matrix Thib

Matrix Live

Dept of Spec 📜

Andrew Morgan (anoa) says

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:

  • No MSCs are in FCP.

Accepted MSCs:

Closed MSCs:

  • No MSCs were closed/rejected this week.

Spec Updates

Review this week from the SCT focused on the future of OIDC and logging in via a QR code (MSC3906) - a feature other platforms have and one I would love immensely. Fixing notifications (MSC3966, MSC3873, MSC3758, MSC3952, MSC3958) as per last week, as well as trying to finally get MSC2677 (spec'ing the current state of Annotations and Reactions) into FCP.

Random MSC of the Week

The random MSC of the week is... MSC3972: Lexicographical strings as an ordering mechanism!

While there already is an MSC for a top-level ordering of Spaces in use across some client implementations today (MSC3230), the algorithm recommended for clients to implement apparently has some consistency flaws, leading to edge cases. MSC3972 attempts to address this by providing a different algorithm that does not have these flaws. A real-world implementation of the algorithm is also available today in Kotlin at https://github.com/Dominaezzz/MatrixSort.

Neither of these algorithms have been merged to the spec yet, but this new MSC may finally push this conversation forwards! I recommend client developers give it a read and leave their feedback as Pull Request Review comments on the MSC.

Continue reading…

This Week in Matrix 2023-03-03

03.03.2023 00:00 — This Week in Matrix Thib

Matrix Live

Dept of Spec 📜

Andrew Morgan (anoa) announces

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!

Continue reading…

This Week in Matrix 2023-02-24

24.02.2023 00:00 — This Week in Matrix Thib

Matrix Live

Transcription (Community made): https://en.miki.community/wiki/Matrix_Tutorial_7

Dept of Spec 📜

TravisR announces

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

Merged MSCs:

Closed MSCs:

MSCs in Final Comment Period:

  • No MSCs are in FCP.

New MSCs:

Spec Core Team

In terms of Spec Core Team MSC focus for this week, we've been aiming to get the requirements for MSC3952: Intentional Mentions landed as well as discussing MSC3952 itself, in addition to planning out what the next few spec releases are expected to look like.

Watch this space for progress on the Matrix 2.0 MSCs and other critical path items :)

Curated MSC of the week

This week's random chosen MSC is MSC3575: Sliding Sync! It's one of the largest (or is the largest?) MSCs we've ever had, and dramatically changes how clients actually get updates from the server. It's worth the read if you're a client developer, though the team working on it is ironing out some bugs. Let us know what you think on the MSC :)

The Chart

It seemingly was okay with being generated this week again, so here it is:

Continue reading…

This Week in Matrix 2023-02-17

17.02.2023 23:33 — This Week in Matrix Thib
Last update: 17.02.2023 20:28

Matrix Live

Thib was away this week, Matrix Live is finally coming back next week!

Dept of Status of Matrix 🌡️

Gitter

madlittlemods (Eric Eastwood) says

If you didn't already catch it this week, Gitter has fully migrated to Matrix! 😎

We brought over all of the historical Gitter content to the gitter.im homeserver and gave everyone free rein over it via app.gitter.im, a Gitter branded Element instance.

Of course, since it's Matrix, you can use whatever client you want to access your public, private and one to one (now DM) conversations!

You can read about the full details in the blog post: https://blog.gitter.im/2023/02/13/gitter-has-fully-migrated-to-matrix/

Happy chatting! 🤠

Dept of Spec 📜

TravisR reports

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

Merged MSCs:

  • No MSCs were merged this week.

MSCs in Final Comment Period:

New MSCs:

Spec Core Team

The Spec Core Team has been busy working away at Matrix 1.6 (released earlier in the week) and aiming to get MSC3925: m.replace aggregation with full event, MSC3952: Intentional Mentions, and MSC2677: Annotations and reactions and all of their dependencies through the spec process. These are all MSCs the SCT has been asked to help get through the process - if there's an MSC we should be looking at, please let us know in #sct-office:matrix.org.

IETF/MIMI/DMA

With the Extensible Events Core (MSC1767) being accepted last week, the focus now turns to all the other extensible event MSCs for images, files, etc. How does extensible events relate to IETF/MIMI/DMA, you ask? In our mission for having Matrix be the standard for interoperability, we need a content format that works for everyone. Events prior to MSC1767 could work with enough effort, though MSC1767's system makes things a lot easier when representing arbitrarily complex messaging features.

Stay tuned to TWIM for progress in this area. It's a relatively slow process, but we're working through it.

Random MSC of the week

This week's random MSC is MSC2785: Event notification attributes and actions! This is effectively a replacement for the push rules system we have today, and a super interesting one (how do you even design a notifications system?). Focus has shifted a little bit since this MSC was first opened, though its ideas still comes up frequently when aiming to make smaller changes to push rules today.

The Chart

The chart has been giving us a bit of grief when trying to be generated, but today it seems agreeable enough to include - enjoy :)

Continue reading…