Matrix Metadata Problem: the server sees everything except your messages

People pick Matrix because of end-to-end encryption. But E2EE only protects message content — everything around it is plaintext.

The server sees:

  • Your ID, IP, client type and version, device you use
  • Your presence, typing status, read receipts
  • Which rooms you join and when you join/leave
  • Who else is in those rooms → your entire social graph
  • Room names, topics, avatars (all plaintext state)
  • For every message: who sent it, which room, a millisecond timestamp, type, size

And federation copies most of that to every other server whose users are in the room. Your “social footprint” isn’t one copy — it’s as many as there are servers.

  • fruitycoder@sh.itjust.works
    link
    fedilink
    arrow-up
    0
    ·
    2 months ago

    I wonder if there is a more practical solution of having matrix servers just be encrypted message routers. Maybe even encrypt the specific users address by the home server and then have federated servers just build routing tables for each other.

    So my client sends an unencrypted header saying “send this to server A” with the specific user address being encrypted with Server A’s public cert, the message content stays encrypted by the users pub cert. The message gets routed over to there distant server, user address decrypted on server, content decrypted on client.

    Have server data like rooms, typing status, etc just be private messages ment for users sent by the distant server it’s self. Home server only sees the rooms it’s managing then.

  • stratself@lemdro.id
    link
    fedilink
    English
    arrow-up
    0
    ·
    2 months ago

    Federation never sees your client IP and device details. The same problem applies to most messaging services and protocol anyways. Do you have any better offerings?

    Although that SynExtract tool in the linked paper could be nice.

    • verifytheposter@leminal.spaceOP
      link
      fedilink
      arrow-up
      0
      ·
      2 months ago

      Signal is free from this disaster, and client version and device details are only visible to the main server — not to mention the avatar, name, and many more items listed above being in plain text.

      • stratself@lemdro.id
        link
        fedilink
        English
        arrow-up
        0
        ·
        2 months ago

        Kindly find me proof that the Matrix protocol explicitly sends a user client’s version and device details towards another server when engaging in federation.

        Do note that Matrix and open protocols are federated, and requires some amount metadata to actually process+route stuff.

    • ghost_laptop@lemmy.ml
      link
      fedilink
      arrow-up
      0
      ·
      2 months ago

      without that metadata you’d get a pretty bare bones experience. encrypting metadata adds another layer of complexity, not everyone wants that.

        • ghost_laptop@lemmy.ml
          link
          fedilink
          arrow-up
          0
          ·
          2 months ago

          signal? the one that requires a phone number to registar? the one that has a centralized server that you can’t self host basically?

          • verifytheposter@leminal.spaceOP
            link
            fedilink
            arrow-up
            0
            ·
            2 months ago

            Matrix can expose your device name and device details to other homeservers through federation. Profile information such as your avatar and bio can also be queried remotely. A client version is not a dedicated federation field, but it can leak through the device name. Signal at least has Sealed Sender, which hides the sender’s identity from its own service in supported cases.

            This is about metadata, not centralisation, self-hosting, or phone-number registration. Those are separate issues, not trade-offs.

            • Aria@lemmygrad.ml
              link
              fedilink
              arrow-up
              0
              ·
              2 months ago

              Those are absolutely trade-offs. Do you want the app to positively ID you and tie you to your passport, or do you want the app to broadcast your set name and set identity strings to those you opt in to share it with?

              • verifytheposter@leminal.spaceOP
                link
                fedilink
                arrow-up
                0
                ·
                2 months ago

                You haven’t explained why I have to choose between these two trade-offs. I want neither: I want strong metadata protection without being forced to link my account to my real-world identity.

                • Aria@lemmygrad.ml
                  link
                  fedilink
                  arrow-up
                  0
                  ·
                  2 months ago

                  I’m replying to your statement. You proposed Signal as a point of comparison, so those are the apps to compare. They’re both less than perfect if your only metric is anonymity, but their shortcomings are very different, and the shortcomings of Signal are fundamentally de-anonymising whereas Matrix is just metadata rich. But you can set your own client string, your username, your avatar, it’s all information you inputted (either as a user or app developer). With Signal, the data that’s shared is all controlled by Signal.

                  I’m not defending Matrix. If the design decisions of Matrix aren’t what you want, then there’s room to ask for or build an alternative. If Matrix or discourse around Matrix is misleading about what is shared then that’s a good thing to highlight.

                  What I meant with my reply was to contrast it with Signal and communicate that Signal isn’t a valid alternative. It’s not the same class of service. Matrix exists to facilitate chatting with friends and Signal exists to conduct surveillance on you and your friends.

                  You don’t have to choose between these two trade-offs. I’m not saying a third system can’t be better. But any third system wasn’t being evaluated in the thread I replied to.