Comment on Proton is transitioning towards a non-profit structure | Proton

• Asudox@lemmy.world ⁨4⁩ ⁨weeks⁩ ago

  That simplicity introduces lots of security and privacy issues.

  source

  • sudneo@lemm.ee ⁨4⁩ ⁨weeks⁩ ago

    Introduces some risks in terms of security. Privacy concerns are extremely minimal, because in any case you don’t control the setup of your other interlocutor(s).

    Considering that the realistic alternative is not using anything at all and the fact that you have both options with Proton, it’s a win-win scenario.

    source

    • Asudox@lemmy.world ⁨4⁩ ⁨weeks⁩ ago

      One of the biggest risks is when someone knows your password. Your PGP encrypted emails that you want noone to see will be available to the attacker. Whereas if no such thing happened, the attacker wouldn’t be able to decrypt the PGP encrypted emails even if the attacker gained access to your account. Manually encrypting your stuff is better than having some random do it for you. It’s really just a tradeoff. Convenience or security? It’s not even hard to manually encrypt emails.

      source

      • sudneo@lemm.ee ⁨4⁩ ⁨weeks⁩ ago

        One of the biggest risks is when someone knows your password.

        Just a curiosity. How do you think every password for every online service works? The service “has” your password. It is hashed, but if this doesn’t matter (similarly for encryption) to you, then you should be panicking about basically everything.

        In the case of Proton an attacker has basically these options:

        • Option 1: Attack you, try to compromise your device. If this is the case, your local keys are going to be taken, one way or another, even if you have them locally and encrypted. The only way you might save yourself in this scenario is if you store them on an hardware device (like a yubikey).
        • Option 2: Attack proton. Once the infrastructure is compromised, the JS code that does the crypto operation needs to be backdoored, you need to use the service while the JS is compromised, and the attacker will obtain the keys and the messages.
        • Option 3: Compromise the sender/recipient for the emails (this is in cleartext in any case).

        In the case of a manual solution:

        • Option 1 is identical.
        • Option 2: Attack the software you use (let’s say, mutt). Once you gain access to the repository, push a backdoored update and wait for you to install the new version. Incidentally, compromising this tool also allows the attacker to compromise your whole machine (unlike what happens with JS code, which runs at least in the browser sandbox).
        • Option 3 is identical.

        So the tradeoff is really that:

        • With Proton an update is going to be pushed quicker and without your explicit interaction, but
        • compromising Proton is going to be much, much harder than compromising the laptop/repository for the handful of maintainers that generally have the keys to push updates for the software you are most likely going to use. We are talking company with security department + SOC vs maintainers with whatever security practice and no funding.

        It’s not even hard to manually encrypt emails.

        Yeah, and this is why 99.9% of the people have never and will never touch GPG with a 10-foot pole. The tradeoff is a complete no-brainer for the vast majority of people, because the reality is that for most, either someone else does the key discovery, management, signing, encryption, decryption, or nobody does. We can sit here and pretend that it’s easy, but it’s not. Managing keys is hard, it is painful, especially on multiple devices, etc…

        source

        • -> View More Comments