> It's also important to realize that the backup includes your encrypted iMessage messages, and the key required to decrypt them. Meaning that if you have backups enabled, all the "end-to-end" encryption in iMessage is defeated. Apple and by extension the FBI can read your messages. This is documented by Apple here: https://support.apple.com/en-us/HT202303
> Even if you disable backups, whenever you correspond with someone that has backups enabled those messages are still accessible to Apple.
I'm not sure how E2EE came to be interpreted as to mean "totally secure against everything".
Your messages, phone book, pictures you share with others etc. are still 'readable' on the remote end and thus still get collected. And if you connect the dots when you have a large collections your personal data can be reconstructed from that.
If you have persons A, B, C and D in your phone book, but your phone book is 'secret', it doesn't prevent someone from knowing that you know A to D if those still have you listed.
> Even if you disable backups, whenever you correspond with someone that has backups enabled those messages are still accessible to Apple.
That last bit is not true. From Apple’s security PDF:
> When Messages in iCloud is enabled, iMessage, Business Chat, text (SMS), and MMS messages are removed from the user’s existing iCloud Backup and are instead stored in an end-to-end encrypted CloudKit container for Messages. The user’s iCloud Backup retains a key to that container. If the user later disables iCloud Backup, that container’s key is rolled, the new key is stored only in iCloud Keychain (inaccessible to Apple and any third parties), and new data written to the container can’t be decrypted with the old container key.
https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/app...
Majority of iPhone users have backup enabled so Apple can certainly access most iMessages.
If Apple wanted to they could make your phone send them whatever they want.
It's end-to-end encryption* with an asteriks as Apple controls both ends.
Send email bodies encrypted to base64 along with a public key fingerprint, then receiver's client would decrypt if it had the private key for that fingerprint
But this isn't compelling enough to get a network effect to topple in-browser gmail
Per published reports, they (and others) have exploits for many things, including many cryptography implementations.
All PGP does is encrypt the inner message body. All of the metadata that TLAs love to analyze is sent in the clear (at best inside a TLS connection, although the SMTP protocol unfortunately makes it incredibly easy for well-positioned network attackers to downgrade these connections to in the clear)
While not as popular as they once were networks of remailers are fairly easy to spin up.
Those solutions encrypt only the content and not the headers, which are just as important. Also, encrypting the content prevents some webmail services from functioning, such as search.
Email can't really be made secure.
There are implementations which encrypt the headers, for example Delta Chat, which says[0] in its FAQ:
'Many other e-mail headers, in particular the “Subject” header, are end-to-end-encryption protected, see also this upcoming IETF RFC.'
If you mean that the sender's server and the recipient's server can see the recipient's and sender's (respectively) addresses, then I would say that this is equivalent to most other "end to end encrypted" messaging apps, which usually rely on a trusted third party to connect the two ends.
In fact, I would argue that the situation with email is better, because although Alice and Bob's providers might know that they are communicating with each other, Carol's provider will have no record of this at all (and Alice and Bob may not know that Carol or her provider exists).
The situation with email could be made even better than that, though, since email servers could provide a dedicated "switchboard" address, such that Alice sends her email for Bob as an encrypted inner-message of an email sent to Bob's server's switchboard address. That way Alice's server wouldn't know who the intended recipient was, only their server address. Similarly Alice's server could rewrite the headers of her outer-message so that Bob's server doesn't know that Alice was the original sender. This would effectively implement a type of anonymous remailer.[1]
> encrypting the content prevents some webmail services from functioning, such as search.
You've shifted the goalposts here from "email can't be secure" to "webmail can't be secure". In any case, I disagree. It is possible to implement a client-side full text search[2], even if it means decrypting the index for every search, and re-encrypting the index whenever a new email is added to it.
[0] https://delta.chat/pt/help#how-does-delta-chat-protect-my-me...
[1] https://en.wikipedia.org/wiki/Anonymous_remailer
[2] https://lucaongaro.eu/blog/2019/01/30/minisearch-client-side...