Signal is aware of the blocks.

“Signal is being blocked in Venezuela and Russia. The app is a popular choice for encrypted messaging and people trying to avoid government censorship, and the blocks appear to be part of a crackdown on internal dissent in both countries…”

  • Lemongrab@lemmy.one
    0·
    3 months ago

    Matrix doesn’t protect metadata, which is arguably just as (if not more) important than message data. Signal by contrast does protect metadata and proper implements Perfect Forward Secrecy for all chats. I do think Signal’s centralized design and phone number requirements problematic, but Signal still has many merits. Such as its massive user base for a AGPL-only project.

    • poVoq@slrpnk.net
      0·
      3 months ago

      for a AGPL-only project.

      Citation needed. It is undisputed that the software that runs on their servers is not identical to the code they release; if they release at all because sometimes they just stop for a year, until people complain 🫠

      • Lemongrab@lemmy.one
        0·
        3 months ago
        • AGPL-only is a license, I didn’t want to misrepresent the license by being general. I was just trying to say that it is surprising that a fully open source application like signal has a large user base.
        • PFS isnt enabled by default for group chats and generally feels messy as the end user to deal with. I was unaware that they have properly implemented it for group chats as well.
        • My point about metadata still stands. Matrix still does not protect metadata (one eg: reactions to messages are in unencrypted).
        • ReversalHatchery@beehaw.orgEnglish
          0·
          3 months ago

          PFS isnt enabled by default for group chats and generally feels messy as the end user to deal with. I was unaware that they have properly implemented it for group chats as well.

          Isn’t it? Maybe I’m misunderstanding something, so let’s start from the definition. PFS is when future joined users can’t read messages sent before they have joined, right?
          In that case, it is not just implemented, but cannot be avoided and is a major hassle to deal with. In my understanding when someone joins, all members start a new olm session, meaning they now encrypt future messages with a new key. The old keys are not being sent to the joined users, not even if the room has been set up to allow reading history, and this results in them only seeing undecryptable messages, and all the metadata you’re taking about (except when the client hides these to reduce new user’s confusion).

          Former keys are not shared among clients for now because there’s no mechanism (for now, but this is planned) to verify that a new member is actually a legit member, not just someone popped in by the server admin by DB editing or whatever.
          Earlier there was a workaround mechanism, where with element clients, when you have invited someone, your client has sent keys to all the previous messages which it had, to the invited user. That was not (yet?) reimplemented in their new crypto library, but apparently they’re working on it.

          But the point is, that afaik PFS is on and cannot be disabled for encrypted rooms, new rooms are encrypted by default, you have to toggle that off by yourself if you don’t want it, and it can’t be toggled off after room creation.

          My point about metadata still stands. Matrix still does not protect metadata (one eg: reactions to messages are in unencrypted).

          That’s right. I don’t think that’ll ever change, but it’s for sure that it’ll not change for a long time, because fundamental changes would be needed.
          But! For when that is a concern, you are not entirely unprotected. For example you can set up a room to never federate, or only federate with specific homeservers. If your group runs their own, on owned real hardware, information can’t really leak from your control.