iMessage doesn't store your decryption keys on Apple's servers unless you opt into iCloud backup which is a whole different service and security concern.
> Apple does not have the ability to read your messages.
iCloud backup is an Apple service and it has the ability to read most of your messages even if you don't use it, which makes this statement categorically false.
That I may have given Apple my private key through a different message in no way affects that end-to-end encryption, because it is trivial to decide not to give Apple that key.
You can decide not to give your keys to Apple, but you can't decide for all your friends to not give their keys to Apple, and the result is the same: Apple can read your messages.
And the marketing is so misleading that hardly anyone knows that Apple can read most iMessages.
Here is another article from 2016, which shows that Apple patched iMessage to prevent attackers who don't have access to Apple's servers from reading the messages but still kept the ability to read the messages themselves. https://blog.cryptographyengineering.com/category/imessage/
Apple was aware that people knew it could decrypt iMessage messages this entire time, but Apple made no changes that would fix that. That should give you some idea of whether Apple intends to ever fix that.
E2E encryption simply means that messages are only decrypted at the endpoints. That certainly isn't true of iMessage in China, and it might not even be true for some users in the US — we have no way of knowing because the protocol makes no guarantee against it.
"If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices."
What we know is that they can and do decrypt iMessages from iCloud backups in response to law enforcement requests[1]. This proves that they hold the keys, if their own support pages weren't enough evidence for you.
[1] https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
> > iCloud isn't some separate entity from iMessage. It's all Apple.
> Got any sources for that? Sounds a lot like FUD.
You don't use a password to encrypt your iCloud backups... They're specific to the hardware your backing up. If you have an itouch for example it's backups are separate from your phone.
So now you have these backups in the cloud and you lose your iPhone, you remote wipe it.
Now your new one arrives and you restore from backup... Your iMessage private keys are available to apple unencrypted .... Because you didn't need to provide a second factor of authentication for unlocking the backup you were just asked which one to use.
Apple and any reputable nation-state can read your iMessages with a subpoena ... If you use iCloud backups and not local backups with a password.
I wish this meme of trying to sound fancy by misusing the term "nation-state" would die.
2) What about your iCloud account and password that are required to encrypt, store, access, and decrypt the backups there? Is that not a factor worth consideration?
This is why WhatsApp for example notifies users when the key of the recipient changes, and they give you a way of verifying that the both keys at both ends are identical.
https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
https://threatpost.com/apple-imessage-open-to-man-in-the-mid...
"If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices."
Ultimately, it's false to equate iMessage's encryption scheme, which is end-to-end, to an encryption scheme that requires a server to relay decrypted data.
Utterly false. Real end-to-end encryption would encrypt the backup with a key that is not available to the backup service (e.g. derived from a passphrase not sent to the server).
Of course this system has better usability, which is why Apple does it. But it's still a farce to call a system where Apple has the ability to decrypt the majority of messages "end-to-end" encrypted. The fact that it's through the backup servers instead of the iMessage servers makes no difference.
What's more, it's possible to do better without sacrificing usability. For several years Android has been end-to-end encrypting backups using the user's lock screen passcode, with protection against brute force attacks provided by hardware secure elements. https://security.googleblog.com/2018/10/google-and-android-h...
It makes a big difference. If I print out the texts I receive, it doesn't change whether the texting program is end-to-end encrypted. The same goes for backups. An unencrypted system-level backup doesn't mean that the program being backed up is failing at security.
It's bad that Apple doesn't let you encrypt your backups properly, but it's a separate issue.
> An unencrypted system-level backup doesn't mean that the program being backed up is failing at security.
iOS programs can choose how their data is backed up. iMessage isn't just getting its data stolen by iCloud accidentally. These backups are a feature of iMessage as much as iCloud. And besides, iCloud is made by the same company, it's not a separate entity.
> iOS programs choose how their data is backed up.
Well desktop apps don't. Would you say that no desktop app that saves its key can ever qualify as end-to-end encrypted?
> And besides, iCloud is made by the same company, it's not a separate entity.
I'm not convinced that's relevant to whether the encryption is end-to-end or not.
I would say that no app can qualify as end-to-end encrypted if a large fraction of users send their data to the maker of the app in a form that can be decrypted by the maker of the app, regardless of the reason.
Have you considered that some people trust Apple but don't trust Zoom? At some point you have to trust somebody, right?
> At some point you have to trust somebody, right?
It's possible to use an actual end to end encrypted app that doesn't have the keys to read your messages stored on their servers.