4 ms·

This is exactly why I wish we had more decentralized software that runs only on the client. It's the only way to truly lock yourself out of your users' data. E

This is exactly why I wish we had more decentralized software that runs only on the client. It's the only way to truly lock yourself out of your users' data. Even so-called zero-knowledge centralized software like iMessage is only a centrally mandated update away from turning their backs on their privacy policy.

shalmanese 11y ago
If I try to send you a message and your phone is off and my phone is off by the time you turn your phone on, where does the message live until you turn your phone back on? It has to live somewhere not controlled by either of us if we don't want unacceptable degradations in usability.
- chatmasta 11y ago
  can't it just live on the sender's device until the receiver is online? think about sending an iMessage on the subway... "undelivered" doesn't mean that your message is sitting on Apple servers somewhere. it means it's still on your phone and you can try sending it again when you have a better uplink.
  - shalmanese 11y ago
    When you can't reach Apple, it's undelivered. But there's also the case where you can reach Apple but Apple can't reach the recipient. Then, the message sits on Apple's servers until the recipient can be reached.
- Natanael_L 11y ago
  Encrypted on the server, TextSecure / Signal has solved that already with 3DH + axolotl.
  - shalmanese 11y ago
    Right, but that's not software that runs only on the client. There's still a server sitting in the middle. iMessage theoretically also does this. The difference is how key exchange is handled, with iMessage preferring a more usable but potentially less secure approach.
    - Natanael_L 11y ago
      The real problem with iMessage is that public keys are unverifiable. The apparent lack of PFS is also a negative. And the iCloud backups in plaintext (although optional). Signal have none of those particular problems.
- lewisl9029 11y ago
  Yes decentralized messaging does come with that as a serious usability penalty. But I'm not calling for all communications to be decentralized. I'd like to see more viable options in this space for communications that truly need to be confidential, both in terms of content and metadata. Centralized services can only provide the former for as long as the centralized provider has not been compromised, and simply cannot provide the latter at all.

shalmanese 11y ago

If I try to send you a message and your phone is off and my phone is off by the time you turn your phone on, where does the message live until you turn your phone back on? It has to live somewhere not controlled by either of us if we don't want unacceptable degradations in usability.

chatmasta 11y ago
can't it just live on the sender's device until the receiver is online? think about sending an iMessage on the subway... "undelivered" doesn't mean that your message is sitting on Apple servers somewhere. it means it's still on your phone and you can try sending it again when you have a better uplink.
- shalmanese 11y ago
  When you can't reach Apple, it's undelivered. But there's also the case where you can reach Apple but Apple can't reach the recipient. Then, the message sits on Apple's servers until the recipient can be reached.
Natanael_L 11y ago
Encrypted on the server, TextSecure / Signal has solved that already with 3DH + axolotl.
- shalmanese 11y ago
  Right, but that's not software that runs only on the client. There's still a server sitting in the middle. iMessage theoretically also does this. The difference is how key exchange is handled, with iMessage preferring a more usable but potentially less secure approach.
  - Natanael_L 11y ago
    The real problem with iMessage is that public keys are unverifiable. The apparent lack of PFS is also a negative. And the iCloud backups in plaintext (although optional). Signal have none of those particular problems.
lewisl9029 11y ago
Yes decentralized messaging does come with that as a serious usability penalty. But I'm not calling for all communications to be decentralized. I'd like to see more viable options in this space for communications that truly need to be confidential, both in terms of content and metadata. Centralized services can only provide the former for as long as the centralized provider has not been compromised, and simply cannot provide the latter at all.