3 ms·

You are correct to identify that end to end encryption without control of the software is not perfect. However, you have reduced the attack surface to the orga

You are correct to identify that end to end encryption without control of the software is not perfect. However, you have reduced the attack surface to the organisation distributing a signed and compromised version of their software to your phone. This is much less likely than any admin in the company looking at your stuff, or anyone who can hack into the company. Don't let the perfect be the enemy of the good.

mort96 4y ago
That's not a bad point. That moves the conversation from "which organisations must we trust" to "which individuals in the organisations must we trust". After thinking about it for a bit, I find that argument rather convincing in the case of Signal: very few people would be in a position to add code to the distributed binary without it ending up in the git repo. So with E2EE, we still have to trust the organisation overall, but we don't have to trust any individuals with access to the servers, and the open-source nature lets us avoid trusting any of the individual app developers other than the person/group responsible for producing the final binaries. It's slightly less convincing in the case of WhatsApp or this GMail thing though. You don't have to avoid a back-door ending up in the git repo, you just have to make it past code review. So in that case, with E2EE, we still have to trust the organisation overall, we have to trust the individuals with access to the app source-code, but it lets us avoid trusting any individuals with access to the back-end. Still a win I suppose. Just a pretty far cry from how I usually see it advertised, which is more like "thanks to E2EE you don't even have to trust them".
- godelski 4y ago
  Just beware that there are Signal forks where people do have modifications like being able to ignore delete commands. That's the downside of open source, that people can easily modify programs. This is also why Signal keeps a tight control over their servers. I'm happy that Signal has things open source, I think it is the better option, but I want to point this out because we need to recognize that the problem itself is over-constrained and there are not globally optimal solutions. It then becomes easy to justify several solutions and have us fight and go nowhere because we are arguing with different weighting criteria than the person we're arguing with. Those discussions are fruitless because we're speaking different languages despite being able to understand one another. And just to be clear, Signal says that they try to reduce the trust on them to as little as possible. Not zero trust/trustless. They sell "low trust" instead.
  - mort96 4y ago
    I don't really see modified clients as having any impact on the security aspects. From a security perspective, once you have sent something, it is sent. There is no un-sending. A recipient running a completely unmodified client might have simply been on their phone at the time and seen the message notification come up, or the notification might not have disappeared when the message was deleted (this seems to happen with Telegram IME, notifications for deleted messages sometimes linger), or the recipient might have set up a computer to screenshot every incoming message with an unmodified client. I don't understand what "low trust" means. It makes sense to talk about removing trust for individual employees in the organization, but when we're using a client distributed as a binary with no way to verify the source code used to compile it, we're forced to place 100% of our trust in Signal as an organization. Is that "low trust"?
    - godelski 4y ago
      > I don't really see modified clients as having any impact on the security aspects. Your messages are only as secure as the least secure part of the network. In an absurd example, that other client could take your messages and publish all conversations straight to Twitter in the public. Effectively rendering the encryption pointless. While this is an absurd example, there are things people do that aren't drastically different, including unencrypted plain text backups. > I don't understand what "low trust" means. Trust isn't a binary option of: I trust this person/thing/group vs I don't trust it. There is a spectrum. The question is not "do you trust x?" but "how much do you trust x?" This is more obvious with people you deal with in your daily life. There are people you trust with some things but not others. I am willing to bet that you don't have two sets of people in your life: those that you're a complete open book with and those you are a closed book with. You share different pages with different people and this is okay. Signal's mission is to read as little of that book as possible while maximizing your security and privacy. That is low trust. I'm actually not even aware of a zero trust system in existence. All the ZKPs I know still require a trust in the setup process, so aren't completely trustless. Either way, you still need to trust that things aren't improperly implemented. Even if you check it yourself, you have to trust that you yourself didn't make a mistake. Trust is not binary, but a spectrum. There is no global optima and we need to be aware of the trade-offs being made.

mort96 4y ago

That's not a bad point. That moves the conversation from "which organisations must we trust" to "which individuals in the organisations must we trust". After thinking about it for a bit, I find that argument rather convincing in the case of Signal: very few people would be in a position to add code to the distributed binary without it ending up in the git repo. So with E2EE, we still have to trust the organisation overall, but we don't have to trust any individuals with access to the servers, and the open-source nature lets us avoid trusting any of the individual app developers other than the person/group responsible for producing the final binaries. It's slightly less convincing in the case of WhatsApp or this GMail thing though. You don't have to avoid a back-door ending up in the git repo, you just have to make it past code review. So in that case, with E2EE, we still have to trust the organisation overall, we have to trust the individuals with access to the app source-code, but it lets us avoid trusting any individuals with access to the back-end. Still a win I suppose. Just a pretty far cry from how I usually see it advertised, which is more like "thanks to E2EE you don't even have to trust them".

godelski 4y ago
Just beware that there are Signal forks where people do have modifications like being able to ignore delete commands. That's the downside of open source, that people can easily modify programs. This is also why Signal keeps a tight control over their servers. I'm happy that Signal has things open source, I think it is the better option, but I want to point this out because we need to recognize that the problem itself is over-constrained and there are not globally optimal solutions. It then becomes easy to justify several solutions and have us fight and go nowhere because we are arguing with different weighting criteria than the person we're arguing with. Those discussions are fruitless because we're speaking different languages despite being able to understand one another. And just to be clear, Signal says that they try to reduce the trust on them to as little as possible. Not zero trust/trustless. They sell "low trust" instead.
- mort96 4y ago
  I don't really see modified clients as having any impact on the security aspects. From a security perspective, once you have sent something, it is sent. There is no un-sending. A recipient running a completely unmodified client might have simply been on their phone at the time and seen the message notification come up, or the notification might not have disappeared when the message was deleted (this seems to happen with Telegram IME, notifications for deleted messages sometimes linger), or the recipient might have set up a computer to screenshot every incoming message with an unmodified client. I don't understand what "low trust" means. It makes sense to talk about removing trust for individual employees in the organization, but when we're using a client distributed as a binary with no way to verify the source code used to compile it, we're forced to place 100% of our trust in Signal as an organization. Is that "low trust"?
  - godelski 4y ago
    > I don't really see modified clients as having any impact on the security aspects. Your messages are only as secure as the least secure part of the network. In an absurd example, that other client could take your messages and publish all conversations straight to Twitter in the public. Effectively rendering the encryption pointless. While this is an absurd example, there are things people do that aren't drastically different, including unencrypted plain text backups. > I don't understand what "low trust" means. Trust isn't a binary option of: I trust this person/thing/group vs I don't trust it. There is a spectrum. The question is not "do you trust x?" but "how much do you trust x?" This is more obvious with people you deal with in your daily life. There are people you trust with some things but not others. I am willing to bet that you don't have two sets of people in your life: those that you're a complete open book with and those you are a closed book with. You share different pages with different people and this is okay. Signal's mission is to read as little of that book as possible while maximizing your security and privacy. That is low trust. I'm actually not even aware of a zero trust system in existence. All the ZKPs I know still require a trust in the setup process, so aren't completely trustless. Either way, you still need to trust that things aren't improperly implemented. Even if you check it yourself, you have to trust that you yourself didn't make a mistake. Trust is not binary, but a spectrum. There is no global optima and we need to be aware of the trade-offs being made.