• notabot@lemm.ee
    link
    fedilink
    arrow-up
    6
    arrow-down
    1
    ·
    4 months ago

    Whilst I absolutely agree it’s correct to be skeptical about it, the ‘sealed sender’ process means they don’t actually know which account sent the message, just which account it should be delivered to. Your client doesn’t even authenticate to send the message.

    Now, I’m just going on what they’ve published on the system, so either I could be completely wrong, or they could be being misleading, but it does look like they’ve tried to address the very issue you’ve been pointing out. Obviously it’d be better if they didn’t have your phone number at all, but this does seem to decouple it in a way that means they can’t build a connection graph.

    • ☆ Yσɠƚԋσʂ ☆@lemmy.ml
      link
      fedilink
      arrow-up
      4
      arrow-down
      2
      ·
      4 months ago

      The problem is that there is no way to verify any of this. You’re just putting trust into people operating this service. That’s not how security is supposed to work.

        • ☆ Yσɠƚԋσʂ ☆@lemmy.ml
          link
          fedilink
          arrow-up
          3
          ·
          4 months ago

          I’d argue that this is part of the overall protocol design. The e2e encryption aspect of the protocol seems sound, but the system as implemented overall is problematic.

      • notabot@lemm.ee
        link
        fedilink
        arrow-up
        3
        arrow-down
        1
        ·
        4 months ago

        Strictly you’re having to trust the build of the client rather than the people running the server. If the client doesn’t send/leak the information to the server, the people running the server can’t do anything with it. It’s definitely still a concern, and, if I’m going to use a hosted messaging app, I’d much rather see the client built and published by a different group, and ideally compile it myself. Apart from that I’m not sure there’s any way to satisfy your concerns without building and running the server and client yourself.

          • turmoil@feddit.org
            link
            fedilink
            arrow-up
            1
            arrow-down
            1
            ·
            4 months ago

            The government can then know you use Signal. This may be problematic in heavily autocratic regimes, but besides those, what threat scenario are you arguing for here? The Sealed Sender concept disallows building a social graph. However, you can utilize a VPN to mask your point of origin or, if necessary, even use a burner number. Under the worst case scenario that the US gov takes over the whole AWS infrastructure and tries to correlate connections to users, there’s still very high information entropy. At that point, we’re talking about the US gov as a targeting threat actor. If that’s your opponent, you shouldn’t use everyday customer electronics or applications anyway. That’s some spy shit, even domestic activists won’t fall under that much scrutiny.

            • ☆ Yσɠƚԋσʂ ☆@lemmy.ml
              link
              fedilink
              arrow-up
              2
              ·
              4 months ago

              The government can know you use Signal, and know who your contacts are, and can correlate all the data they have on your and your contacts to see if any of it makes your whole group of contacts of interest. So, yeah it’s pretty concerning for people living in autocratic regimes like the US. Meanwhile, the sealed sender concept is just trust me bro because nobody aside from people who are actually operating the server know what it’s doing. The fact that people in this thread have so much trouble understanding that any data that gets leaked has to be assumed to be in the hands of a bad actor is phenomenal. Signal is proof that vast majority of people don’t understand the basics of privacy and security, and they don’t actually care. It’s just pure ideology for them.