All that security, and then by default Apple literally just sends themselves a copy of your encryption keys to store in iCloud backup, the only cloud backup solution Apple allows you to use. "to help you recover your data" [1] (oh and also to send law enforcement your message history in plaintext on request, but we don't talk about that).
1. That their messages won't be lost when they migrate between devices.
2. That their messages won't be lost when their device is stolen and they set up the new one from nothing but a password.
3. That Apple's password recovery flows work like any other password recovery flows, AKA that forgetting your password is a minor inconvenience, to be overcome at the Apple Store at worst, not a data loss disaster.
4. That they don't have to spend $$$ on some strange device called a "Yoobby Key", which they don't understand and will lose anyway.
There's no way to satisfy those demands and have your desired level of security, hence why iCloud backup encryption is a strictly opt-in feature.
There are tradeoffs to be made here, and Signal made different tradeoffs, which makes it significantly more secure but also significantly more annoying to use for somebody whose main life interest isn't figuring out why tech works the way it does. Apple does the best it can under the constraints they are given.
Apple has the opportunity to add “extra security” features like disappearing messages, or to treat certain chats the same way they treat your web history (back this chat up, but require my passcode.) For the latter feature one can argue that it’s too advanced for the ordinary Apple user. But disappearing messages are a common security feature in virtually every messaging app, and Apple still won’t deploy those.
I used to think this was because they were intimidated by law enforcement, but they claimed otherwise. The recent UK attempt to backdoor Advanced Data Protection has made me believe them a bit less.
I think the story around privacy and security in general has become diluted in marketing talk. Every single default on both iOS and macOS effectively makes one’s data, well, accessible and not private.
The gap between perception and reality when it comes to Apple as a “privacy champion” has never been so big as it is today.
Most customers do want it this way, but Apple still allows to exchange comfort for privacy, if you want to. I actually think it's a pretty sensible approach to capture both the big segment of people who don't care, and those who do and know which knobs to tweak.
You can still turn everything compromising off and end up with a device secured to paranoid levels. That's definitely more than an empty promise, or what other vendors provide.
> Most customers do want it this way, but Apple still allows
I don't believe this is the case. Apple generally prefers to diminish the importance and risks of specific actions unless they have some monetary advantage. e.g. Apple is happy to warn you (multiple times) that an alternative marketplace is "dangerous" and yet iMessage iCloud Backups are just a click away with a friendly "so your messages are available everywhere".
Another example is Photos - Apple has no problem activating features that collect "anonymized" information from my pictures. Yes, there is an opt-out, but having all that on by default is not in the spirit of a privacy-minded operation.
And about the choice - someone already pointed out in other comments, there really is no way to replace iCloud with anything else for backups and app data sync. So the choice is not really a choice.
> Most customers do want it this way, but Apple still allows to exchange comfort for privacy […] more than an empty promise, or what other vendors provide.
That’s pretty much exactly what all the other vendors in the market provide: insecure and spying by default.
I don’t really understand why Apple should somehow get good points for their stance on privacy when they are actually doing pretty much the same thing than everyone else.
While I'm not on the Apple bandwagon, there is a difference between insecure by default and active spying. Even as a Pixel user, I'm fairly confident that my data would be (ab)used less on the Apple side.
Users want convenience, and security always brings inconveniences (e.g., inter-client sync, no chat data before a client logged in first time, etc.).
Some vendors might provide convenience because they want to have your data. Others might provide you the convenience because you as a user want it, but see the resulting data as nothing but a liability.
Some providers are known to have the majority of their business be based around such data, whereas others might have little to no presence in that field.
iOS is a second class operating system platform, with Android not far behind. iMessage has been the subject of multiple device takeover zero days, no user intervention required. "20 zero-days patched by Apple in 2023".
Unlike Google's comparable backup encryption feature, ADP is off by default. And ADP protects your messages from Apple only to the extent that everyone you message also turns on this non-default option; otherwise your messages are still Apple's to read as they please with no notification to you.
> the only cloud backup solution Apple allows you to use
Not quite. You can still have automatic local backups set up for iOS and macOS devices to your own NAS. And that NAS can then do cloud backups of whatever is on it in any way you want. It's certainly more effort than the stock iCloud solution, but it's still an option.
via USB (or possibly local Wi-Fi) and your computer.
iTunes (or Mac OS's built-in iPhone sync) is the recommended way to do this, although the protocol has been reverse-engineered to hell and back and third-party software exists for it. iMazing is the most notable one, although there are probably others, and you could hack something on top of libimobiledevice if you really wanted to.
Getting those backups from your computer to the NAS is an exercise for the reader.
What about the “Advanced Data Protection” end to end encryption? Or by “sending copy of keys to iCloud” you mean those? It even says that “Apple will not be able to help you recover if you switch to End to end advanced data protection”.
The more charitable interpretation is that for most people losing their photos and messages is a bigger threat than the government spying on them. For those who might have a different tradeoff there is Advanced Data Protection.
I'm glad ADP exists now, but you have to make sure everyone you message has it enabled too, or your messages are still Apple's to read whenever they choose. Meanwhile Google's equivalent backup feature (whatever other faults it may have) has been end-to-end encrypted by default for everyone since long before ADP was even available at all. The risk of losing access is practically nonexistent because the password is your screen lock code, the same one you enter on your lock screen literally every day.
Also, is government spying the only reason Apple decrypts messages? We don't know. They don't disclose that they do it for the government, but we know they do from other sources. What other purposes might they not be disclosing?
The concern is if you lose your devices with E2EE enabled then you are locked out permanently. Grandma won't know how to use a Yubikey (which is the alternative Apple provides for this eventuality with ADP enabled) and will be out of luck.
This is not a requirement with Google's solution. After losing all your devices you only need your lock screen code to decrypt your backup, as I said. This is achieved using a secure element on the datacenter side to protect against brute-force attacks on the screen lock code.
You mean the one that by default is a 4 digit number and therefore trivially brute forcable?
And neither android hardware nor the google servers have any kind of secure element enforcing brute force protections like '3 tries then we wipe the keys'.
I'm not sure how different devices implement it, but the security chip can simply count the time it was powered on, it doesn't have to rely on wall clock time.
(Relying on wall clock time caused a bug in an early iOS version of this feature, where it would show a really long delay when the clock was reset, and there was no way to set the clock correctly)
So now you just need to fake a cell tower and a GPS constellation so that the phone gets a new time on power cycle. Which would be about 60s minimum, to boot and acquire.
And that’s with a power cycle, so 14,000 a day? I’ll not going to assume the button will last more than 100,000 presses, so I don’t see many combinations being tried.
> ADP is a total joke if it doesn't also disable plaintext backups for the people you're talking to
Do you consider all security to be a joke then? If you send me a message, how will you actually guarantee that I do not make a copy of it once it's on my own computer?
There's no guarantee, but some apps intended for security actually make at least a minimal effort to be excluded from plaintext backups, rather than intentionally sending their encryption keys to the backup service that just happens to be run by the same company...
Ok. So you concede that there is no way for you to ensure that messages you send me, that I can decrypt, are left unreadable by anyone but me.
So what secure communication system should we be using given that none of them can guarantee that the recipient doesn't leak information to another country by choosing to use a compromised version of the client?
My complaint is not about guarantees, it's about defaults. Default non-e2e-encrypted backups of message encryption keys are the problem here. No system can guarantee absolute security, but that doesn't mean they're all equivalently bad. Some are definitely more secure than others, and defaults have a lot to do with it!
You are attacking a straw man. The risk is the your correspondent does not have ADP enabled, as it is not on by default, and not even offered in some authoritarian countries like the U.K., so even without their cooperation they can still get their key. I don’t know if iMessage implements Perfect Forward Secrecy, but at the very least they will be able to read all your messages moving forward.
Yes, your backup is e2e encrypted after you enable the off-by-default ADP. But some of your friends probably didn't enable ADP, and the keys to decrypt your messages to them are stored in their backups which Apple can read at will.
There are some fundamental different between two ecosystems.
On Google, the Google Drive and Photo are encrypted to a key owned by google.
On iCloud, the iCloud Drive and Photo are encrypted to your account key. In which, without ADP, this key is shared with Apple. When ADP is enabled, Apple does not store this key. iCloud Backup is stored with the same technology as iCloud Drive.
When it comes to lost password account recovery:
- Google can just reset your password, and your drive and photo are still accessible. All barrier are procedural, not technical.
- iCloud (with ADP), they can still reset your password, but then your icloud drive and icloud photo are loss forever.
There are some trade off ..:
- Lost password recovery experience. _Some_ user will lost their password anyway. How high should the bar be?
- Cloud first? or local device first with cloud backup?
- Are you giving the cloud data same protection as local device?
In google's solution, they put the google drive data at risk...
In apple's solution, it need extra steps to ensure you have proper account recovery flow covered.
That's all fine, but tangential to my complaint, which is about iMessage specifically. iMessage, as a system that strongly promotes e2ee as a core feature, should not be backing up its encryption keys to non-e2ee iCloud backup in any scenario. Messages should fall in the same category as keychain passwords and (yes!) Memoji, backups of which are always end-to-end encrypted even when ADP is not enabled.
In fact I would say calling iMessage an e2ee system is false advertising until this is corrected. Reasonable people would assume that an Apple system advertised as e2ee would make an effort to prevent Apple servers from having the keys to decrypt most iMessages, while the reality is with these defaults it's likely that a large majority of iMessages can be decrypted by Apple servers at will.
You aren't understanding the point being made in OP. Everyone here understands the crypto for ADP vs non-ADP, there's no need to explain it.
The simple fact of the matter is that if I have ADP enabled, my chats should be excluded from the backups of those I'm communicating with (it should be as an opt-in basis at the very least).
Not having this renders ADP useless for the purpose of its stated threat model.
Actually it is the opposite. If you have Messages in iCloud, they do not store messages in "iCloud Backup" but keep it separate with some client-side device-to-device encryption key (UPDATE: which they also store a copy of inside iCloud backup unless ADP is on; thanks to 'modeless). If you enable iCloud Backup and Messages in iCloud is turned off, it will backup all your messages in a way visible to Apple servers. Of course, that is unless you enable Advanced Data Protection (the thing that UK hates).
The fact that this is so unintuitive that I had to explain it and I am only 95% sure I got it right is precisely the problem.
Yes but when Messages in iCloud is enabled that "client-side" encryption key is itself included in your iCloud backup (that Apple can read), as disclosed. So Apple can read your messages regardless of whether you enable or disable Messages in iCloud. The only things that prevent it are disabling cloud backups entirely, or enabling ADP. But even those don't really prevent it because unless everyone you message also does the same, Apple can still read your messages.
Good to know, hence my 95% certainty. Fortunately for me, each new device starts with DFU restore and installation of my own Configuration Profile which supervises the device, disable automatic pairing with new devices, disables useless apps like Game Center, and most importantly disables iCloud Backup entirely, etc.
Perhaps I should document it and link to it in detail but basically you use Apple Configurator to create a profile and set its restriction flags accordingly and keep it somewhere you can redeploy with ease and simply DFU restore the iOS device so that it gets the latest clean iOS image. After that you don’t activate it by going through the setup screen. Instead you use the connected Mac with Apple Configurator to “Prepare” the device and the computer activates it and pairs it with your “organization” public key and you can add the profiles you created in the previous steps to apply the configuration restrictions. It’s like having an enterprise MDM except you don’t need a server just the local profile is enough.
No, that's not what it means. The key is stored on their server, but you still need to provide a password to unlock the key. In the same way that you can password protect an SSH key.
It's also the same way ProtonMail encrypts their email. They have to store the private key for you to be able to use the email on any browser.
It is extremely simple, actually. Don’t use “Messages in iCloud” and don’t backup your Messages app to iCloud, and Apple cannot see your message content at all. Luckily these are the defaults.
This is false. If you turn off the "Messages in iCloud" feature then your messages are included in your regular iCloud backup which Apple has the keys to decrypt, as disclosed.
Of course iCloud backup is itself optional. But Apple gives you and the people you're messaging no other option for cloud backups. ADP actually encrypts your backups, but since it defaults to off your messages are almost certainly still readable by Apple thanks to the keys stored in other peoples' backups.
> If you turn off the "Messages in iCloud" feature then your messages are included in your regular iCloud backup which Apple has the keys to decrypt, as disclosed.
No, if you do not use “Messages in iCloud” then your iMessage private key does not leave your device.
If you turn off Messages in iCloud then the messages are instead stored in your iCloud backup and encrypted "In transit & on server" with key storage by Apple, not just on your devices, as specified in the fourth row of the "Data categories and encryption" table in the Apple support article I linked. "In transit & on server" means not e2ee. That is, Apple can decrypt the messages at will without notice or consent.
If the messages were still protected by e2ee with key storage only on your devices then it would specify that in the table. Some other data types like keychain passwords and Memoji are in fact protected by e2ee even when ADP is not enabled, and the table reflects that. Messages do not fall in the category of e2ee without ADP.
And of course ADP is off in the U.K., where I live. And iMessage sometimes randomly falls back to unencrypted SMS/MMS even when you ticked the checkbox disallowing this in System Settings.
Nice! That way you can chat with yourself at all times! I mean, everyone else will continue using a different messenger, but they don't have anything interesting to say anyway!
Not OP, so I don't have to bear the snark, but also, let's not pretend that iMessage is some virtuous and ethical standard worth recommending in general. It's nothing but a tool by the monopolist Apple to execute vendor lock-in and subjugate its users into a closed ecosystem. Of course, that says nothing about the quality of said ecosystem (or that of XMPP, for that matter), only about a well-placed sense of priorities that I find laudable.
[1] https://support.apple.com/en-us/102651#:~:text=in%20iCloud%2...
1. That their messages won't be lost when they migrate between devices.
2. That their messages won't be lost when their device is stolen and they set up the new one from nothing but a password.
3. That Apple's password recovery flows work like any other password recovery flows, AKA that forgetting your password is a minor inconvenience, to be overcome at the Apple Store at worst, not a data loss disaster.
4. That they don't have to spend $$$ on some strange device called a "Yoobby Key", which they don't understand and will lose anyway.
There's no way to satisfy those demands and have your desired level of security, hence why iCloud backup encryption is a strictly opt-in feature.
There are tradeoffs to be made here, and Signal made different tradeoffs, which makes it significantly more secure but also significantly more annoying to use for somebody whose main life interest isn't figuring out why tech works the way it does. Apple does the best it can under the constraints they are given.
I used to think this was because they were intimidated by law enforcement, but they claimed otherwise. The recent UK attempt to backdoor Advanced Data Protection has made me believe them a bit less.
The gap between perception and reality when it comes to Apple as a “privacy champion” has never been so big as it is today.
You can still turn everything compromising off and end up with a device secured to paranoid levels. That's definitely more than an empty promise, or what other vendors provide.
I don't believe this is the case. Apple generally prefers to diminish the importance and risks of specific actions unless they have some monetary advantage. e.g. Apple is happy to warn you (multiple times) that an alternative marketplace is "dangerous" and yet iMessage iCloud Backups are just a click away with a friendly "so your messages are available everywhere".
Another example is Photos - Apple has no problem activating features that collect "anonymized" information from my pictures. Yes, there is an opt-out, but having all that on by default is not in the spirit of a privacy-minded operation.
And about the choice - someone already pointed out in other comments, there really is no way to replace iCloud with anything else for backups and app data sync. So the choice is not really a choice.
That’s pretty much exactly what all the other vendors in the market provide: insecure and spying by default.
I don’t really understand why Apple should somehow get good points for their stance on privacy when they are actually doing pretty much the same thing than everyone else.
Users want convenience, and security always brings inconveniences (e.g., inter-client sync, no chat data before a client logged in first time, etc.).
Some vendors might provide convenience because they want to have your data. Others might provide you the convenience because you as a user want it, but see the resulting data as nothing but a liability.
Some providers are known to have the majority of their business be based around such data, whereas others might have little to no presence in that field.
Does it really? There is no option to use my own hardware/software for backup storage. I mean what would usually go to icloud.
That i would really trust.
So to me the answer is no.
Just wish we had more options…
https://www.infosecurity-magazine.com/news/apple-update-extr...
https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zer...
Same reason FileVault isn't on by default on macs.
Would be a shame if they claimed they can’t decrypt but an old back up had the keys to the kingdom
I can't sign into Apple Music on Android because it doesn't support security keys – small price to pay.
Not quite. You can still have automatic local backups set up for iOS and macOS devices to your own NAS. And that NAS can then do cloud backups of whatever is on it in any way you want. It's certainly more effort than the stock iCloud solution, but it's still an option.
macOS yes, but iOS?
iTunes (or Mac OS's built-in iPhone sync) is the recommended way to do this, although the protocol has been reverse-engineered to hell and back and third-party software exists for it. iMazing is the most notable one, although there are probably others, and you could hack something on top of libimobiledevice if you really wanted to.
Getting those backups from your computer to the NAS is an exercise for the reader.
Also, is government spying the only reason Apple decrypts messages? We don't know. They don't disclose that they do it for the government, but we know they do from other sources. What other purposes might they not be disclosing?
You mean the one that by default is a 4 digit number and therefore trivially brute forcable?
And neither android hardware nor the google servers have any kind of secure element enforcing brute force protections like '3 tries then we wipe the keys'.
I don't know why you would say this when it is obviously false. https://security.googleblog.com/2018/10/google-and-android-h...
One can't implement brute force protections without such a UI...
"You need to wait 5 minutes" isn't sufficient for a 4 digit pin...
https://www.reddit.com/r/samsung/comments/13nnphc/delete_pho...
Otherwise you can simply say "yeah, we power cycled you and now the year is 100,000, can I have another guess?"
I don't see any mention of that functionality in any public documentation.
(Relying on wall clock time caused a bug in an early iOS version of this feature, where it would show a really long delay when the clock was reset, and there was no way to set the clock correctly)
And that’s with a power cycle, so 14,000 a day? I’ll not going to assume the button will last more than 100,000 presses, so I don’t see many combinations being tried.
The Titan M chip is present on all Pixel devices:
https://grapheneos.org/faq#encryption
Do you consider all security to be a joke then? If you send me a message, how will you actually guarantee that I do not make a copy of it once it's on my own computer?
So what secure communication system should we be using given that none of them can guarantee that the recipient doesn't leak information to another country by choosing to use a compromised version of the client?
That's great, naming those would have been better though since it would have actually answered the question.
> With Advanced Data Protection, the number of data categories that use end-to-end encryption rises to 25 and includes your iCloud Backup,...
> iCloud Backup (including device and Messages backup) (3)
> (3) .... Advanced Data Protection: iCloud Backup and everything inside it is end-to-end encrypted, including the Messages in iCloud encryption key.
On Google, the Google Drive and Photo are encrypted to a key owned by google.
On iCloud, the iCloud Drive and Photo are encrypted to your account key. In which, without ADP, this key is shared with Apple. When ADP is enabled, Apple does not store this key. iCloud Backup is stored with the same technology as iCloud Drive.
When it comes to lost password account recovery:
- Google can just reset your password, and your drive and photo are still accessible. All barrier are procedural, not technical.
- iCloud (with ADP), they can still reset your password, but then your icloud drive and icloud photo are loss forever.
There are some trade off ..:
- Lost password recovery experience. _Some_ user will lost their password anyway. How high should the bar be?
- Cloud first? or local device first with cloud backup?
- Are you giving the cloud data same protection as local device?
In google's solution, they put the google drive data at risk...
In apple's solution, it need extra steps to ensure you have proper account recovery flow covered.
In fact I would say calling iMessage an e2ee system is false advertising until this is corrected. Reasonable people would assume that an Apple system advertised as e2ee would make an effort to prevent Apple servers from having the keys to decrypt most iMessages, while the reality is with these defaults it's likely that a large majority of iMessages can be decrypted by Apple servers at will.
The simple fact of the matter is that if I have ADP enabled, my chats should be excluded from the backups of those I'm communicating with (it should be as an opt-in basis at the very least).
Not having this renders ADP useless for the purpose of its stated threat model.
The fact that this is so unintuitive that I had to explain it and I am only 95% sure I got it right is precisely the problem.
Would be very interested in this.
It's also the same way ProtonMail encrypts their email. They have to store the private key for you to be able to use the email on any browser.
Of course iCloud backup is itself optional. But Apple gives you and the people you're messaging no other option for cloud backups. ADP actually encrypts your backups, but since it defaults to off your messages are almost certainly still readable by Apple thanks to the keys stored in other peoples' backups.
No, if you do not use “Messages in iCloud” then your iMessage private key does not leave your device.
If the messages were still protected by e2ee with key storage only on your devices then it would specify that in the table. Some other data types like keychain passwords and Memoji are in fact protected by e2ee even when ADP is not enabled, and the table reflects that. Messages do not fall in the category of e2ee without ADP.
https://eprint.iacr.org/2024/1395