cross-posted from: https://beehaw.org/post/20989376

Where Soatok goes over why checklists are meaningless when trying to figure out if something is private or just for comparisons in general.

  • moonpiedumplings@programming.dev
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    3 days ago

    So Soatok advocates for signal as pretty much the “gold standard” of e2ee apps, but it has a pretty big problem.

    1. Having signal be the distributor of the app, sorta breaks the threat model where you trust the app to encrypt data and hide it from the sever

    2. Signal is hostile to third parties packaging and distributing signal

    The combination of these problems is suppose to be fixed with reproducible builds, where you can ensure that any user who builds the code will get the same binaries and outputs. Soatok mentions reproducible builds and the problems they solve on another blogpost

    But signal’s reproducible builds are broken.

    The problem is that the answer to Soatok’s second question “Can you accidentally/maliciously turn it off” is YES if you are using packages directly from the developer without signing to verify their identity and reproducible builds. They could put a backdoor in there, and you would have no way to tell. It’s not fair to pretend that signal doesn’t have that flaw, while dissing OMEMO

    To understand why this is true, you only need check whether OMEMO is on by default (it isn’t), or whether OMEMO can be turned off even if your client supports it (it can)

    (Although there is an argument to be made that having e2ee always on by default would minimize user error in improperly configuring it).

    Now, I still think signal is a great software choice for many things. It’s basically the best choice as a replacement to text messaging, universally.

    But some people need something more secure than that, if you’re seriously concerned about certain entities compromising the signal project, than you must have the ability to install clients from third party distributors and developers, even though they can have security issues, which Soatok notes in a post about Matrix (see the heading “Wasn’t libolm deprecated in May 2022?”).

    I thought the whole point of choosing Matrix over something like Signal is to be federated, and run your own third-party clients?

    Yes Soatok. Depending on your threat model you may need to be able to choose from more than client implementation, even if all of them are trash except for 3. (Although I wouldn’t recommend Matrix as a private messeger due to metadata like users/groups being public, but it’s shaping up to be a great discord clone with PM feature. Is the crytography as secure as signals? No. But it checks the box of “Discord but doesn’t sell my data” (yet ofc, Matrix is VC funded).).

    Anyway, it’s frustrating how he seems to have become more of a hardliner about this. It used to be that these were the bar to clear to become a signal competitor. Now these standards are the bar to clear to be recommended entirely (see the main section about “How do experts recommend secure messaging apps”), even though Signal itself doesn’t clear them.

  • Sophocles@infosec.pub
    link
    fedilink
    arrow-up
    4
    ·
    4 days ago

    My lithsmus test for a good checklist is how they rate the Brave browser, Telegram, and popular VPNs. All three have marketed themselves as privacy friendly and secure, but all three are absolutely terrible if you do your homework on them. I’ve seen Brave or Telegram in the top tier on so many lists it isn’t even funny

    • Lime Buzz (fae/she)@beehaw.orgOP
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      2
      ·
      4 days ago

      Yeah, more tech and privacy enthusiasts should really look into things before declaring them secure or private. Even those that market themselves as such. Like, a lot of them hark on about SimpleX without really understanding that it’s not a good choice.

        • Lime Buzz (fae/she)@beehaw.orgOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          4 days ago

          Well, it’s not exactly about privacy. But it does need a lot more time to develop before it is ready for ‘mainstream’ use, right now it’s very niche, they haven’t figured out how to get the same profile on multiple devices, there’s no proper ipad support and because it’s niche only tech people use it and thus I’m not interested in it until the average user can and will use it easily as I like all my friends etc to be on things I use.

          Plus it doesn’t have as many audits, as say, signal, so that’s a big hmmm in my book. Yes, it’s not been around as long, so that might not be fair, but it has a lot of things to fix before it’s worth using.

          Also, it really needs more ‘fun’ features, like signal has before most average people will use it. I think it also needs to figure out things like calling, especially group, but I cannot remember if that’s still accurate or not.

          Oh, also, I remember there was a big concern about funding because they went commercial instead of doing the right thing and starting a foundation or some such.

      • Sophocles@infosec.pub
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        4 days ago

        I actually do endorse SimpleX. While it does lack a lot of user features you might enjoy in other messengers, it does do the security/privacy part right. While not having as many auditors as signal, there have been enough to form an opinion. The fact that it is foss in the first place gives an advocate for their transparency. It’s also double ratchet E2E enrypted, comletely anonymous, practices perfect forward secrecy, and even offers Tor proxies; which is more to be said than most messengers.

        The only good argument I’ve seen against it is that it isn’t federated or P2P, which is a discussion on the centralization of power rather than a security/privacy issue outright

        • Lime Buzz (fae/she)@beehaw.orgOP
          link
          fedilink
          English
          arrow-up
          3
          ·
          edit-2
          4 days ago

          A big thing they could do to convince more of us is to set up a transparency report like Signal has, so we can see any requests for information or legal orders they get, and their replies.

  • XLE@piefed.social
    link
    fedilink
    English
    arrow-up
    2
    ·
    4 days ago

    I’m surprised this article doesn’t mention privacytests.org by name, but it reaches a conclusion that may as well:

    If you see a dumb checklist trying to convince you to use a specific app or product, assume some marketing asshole is trying to manipulate you. Don’t trust it.

    Thankfully there’s a good recommendation in the very next paragraph for all things (messaging apps, browsers, etc):

    If you’re confronted with a checklist in the wild and want an alternative to share instead, Privacy Guides doesn’t attempt to create comparison tables for all of their recommendations within a given category of tool.

    Also: shots fired at XMPP throughout, as the poor protocol limps along trying desperately to catch up to the encryption baseline that was set over a decade ago by the first versions of Signal.

    Ultimately, both protocols are good. They’re certainly way better choices than OpenPGP, OMEMO, Olm, MTProto, etc.

    Why OMEMO is “bad” is indirectly answered earlier:

    The most important questions that actually matter to security:

    • Is end-to-end encryption turned on by default?
    • Can you (accidentally, maliciously) turn it off?

    If the answers aren’t “yes” and “no”, respectively, your app belongs in the garbage. Do not pass Go.

    Similar discussions have skewered the federated Delta Chat for having an even worse version of this issue.

    • moonpiedumplings@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      3 days ago

      If the answers aren’t “yes” and “no”, respectively, your app belongs in the garbage. Do not pass Go.

      Please see my comment about this issue. Signal does not pass this test due to not having (working) reproducible builds.