Proton: “We’re consolidating our social media presence due to limited resources and no longer posting on Mastodon. Follow us on Reddit for the latest updates”

  • DreamlandLividity@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    12 hours ago

    It is nuanced, but having the ability to selectively serve malicious javascript stealing keys to specific people only on one access is considerable issue in practice, compared to distributing binary where you would generally have the same binary for everyone and you are able to archive and analyse it. Especially if you use third party distributions, like github releases or flatpaks.

    • loudwhisper@infosec.pub
      link
      fedilink
      English
      arrow-up
      1
      ·
      11 hours ago

      Well, yes-ish.

      An organization with resources to coerce or compromise Proton or similar wouldn’t have trouble identifying individual users “well enough” (trivially, IP address). At that point there is absolutely nothing stopping a package distributor to serve different content by IP. Not even signatures help in this context, as the signature still comes from the same party coerced or compromised.

      Also most people won’t (or are unable to) analyze every code change after every update, which means in practice detection is even more unlikely for OS packages than it is for web pages (much easier to debug code and see network flows). The OS attack surface is also much broader.

      In general anyway, this is such a sophisticated attack (especially the targeted nature of it) that it’s not relevant for the vast, vast majority of people. If you deal with super sensitive data you can build your proton client directly, or simply use the bridge (which ultimately is exactly like other client-side tooling), so for those very rare corner cases where this threat is relevant, a solution exists. Actually, in those cases you probably don’t want to use mail in general. So my question is, who is the threat actor you are concerned about?

      All in all I think that labeling “insecure” the setup for this I think is not accurate and can paint a wrong picture to people less technically competent.

      • DreamlandLividity@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        11 hours ago

        Bridge did not exist back then.

        As for it being sophisticated attack, I think it is relative.

        Regardless, if Proton said it did not matter to most people, I would respectfully disagree and move on. They did not. They claimed it is not at all less secure than a native app, which is BS.

        • loudwhisper@infosec.pub
          link
          fedilink
          English
          arrow-up
          1
          ·
          10 hours ago

          I can see a threat model already from 2014.

          Anyway, I think it’s a tradeoff that it’s hard to assess quantitatively, as risk is always subjective. From where I stand, the average person using native clients and managing their own keys has a much higher chance to be compromised (by far simpler vectors), for example. On the other hand, someone using a clean OS, storing the key on a yubikey and manually vetting the client tool can resist to sophisticated attacks better compared to using web clients.

          I just don’t see this as hill to die on either way. In fact, I also argue in my blog post that for the most part, this technical difference doesn’t impact the security sufficiently to make a difference for the average user.

          I guess you disagree and that’s fine.

          • DreamlandLividity@lemmy.world
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            6 hours ago

            doesn’t impact the security sufficiently to make a difference for the average user.

            I think it is borderline. I am not advocating for PGP, I like the Signal model where you trust signal for introductions but have the ability to verify, even in retrospect. Trust but verify. Even a few advanced users verifying Signal keys forces Signal to remain honest or risk getting caught.

            I think the lack of meaningful verification for proton is a significant security weakness, though average user probably has bigger things to worry about.

            • loudwhisper@infosec.pub
              link
              fedilink
              English
              arrow-up
              1
              ·
              6 hours ago

              I think I can agree with that. Unfortunately PGP is the only alternative we have for emails (i.e., the client-side tools would still be doing PGP encryption), which is also the reason why it shouldn’t be used for really delicate communication. The fact that - whatever setup you use - there will always be metadata showing that person X communicated with person Y alone is a nonstarter for certain types of communication.

              Signal would be my recommendation.

              • DreamlandLividity@lemmy.world
                link
                fedilink
                English
                arrow-up
                1
                ·
                edit-2
                5 hours ago

                Yeah, we should just ditch email for sensitive communications.

                Anyway, my point was that I lost trust in Proton back then over this and went to Tuta that has native clients. It makes no difference to my security since I don’t think I ever sent or received a single mail that was actually e2e encrypted. But Tuta’s more serious approach to e2ee made me slightly more confident in it as a company.

                Now it kinda looks like it was the right choice.