[HN Gopher] A Formal Analysis of Apple's iMessage PQ3 Protocol [...
___________________________________________________________________
A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]
Author : luu
Score : 143 points
Date : 2025-05-09 02:54 UTC (20 hours ago)
(HTM) web link (www.usenix.org)
(TXT) w3m dump (www.usenix.org)
| modeless wrote:
| 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] https://support.apple.com/en-
| us/102651#:~:text=in%20iCloud%2...
| ls612 wrote:
| 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.
| modeless wrote:
| 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?
| ls612 wrote:
| 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.
| modeless wrote:
| 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.
| londons_explore wrote:
| > the password is your 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'.
| modeless wrote:
| > neither android hardware nor the google servers have
| any kind of secure element enforcing brute force
| protections
|
| I don't know why you would say this when it is obviously
| false. https://security.googleblog.com/2018/10/google-
| and-android-h...
| londons_explore wrote:
| do they actually enforce these limits? I couldn't find
| any google UI which says "2 tries left or your data will
| be permanently erased".
|
| 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...
| jjcob wrote:
| The waiting time increases after failed attempts.
| londons_explore wrote:
| In general that isn't secure unless the security chip has
| access to a secure time server to know that the required
| amount of time has passed.
|
| 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.
| FireBeyond wrote:
| 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.
| __turbobrew__ wrote:
| You can spoof GPS with a hackrf so this is not actually
| that crazy, I wouldn't be surprised if certain 3 letter
| agencies have tried this already.
| jjcob wrote:
| 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)
| ewoodrich wrote:
| I can't speak to Pixels personally but every Samsung
| phone I've owned that I can remember has exactly that.
|
| https://www.reddit.com/r/samsung/comments/13nnphc/delete_
| pho...
| DaSHacka wrote:
| > And neither android hardware nor the google servers
| have any kind of secure element enforcing brute force
| protections
|
| The Titan M chip is present on all Pixel devices:
|
| https://grapheneos.org/faq#encryption
| firecall wrote:
| I don't believe that on Android or iOS it defaults to
| 4-Digits anymore, does it?
| xvector wrote:
| ADP is a total joke if it doesn't also disable plaintext
| backups for the people you're talking to
| Jtsummers wrote:
| > 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?
| modeless wrote:
| 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...
| Jtsummers wrote:
| 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?
| modeless wrote:
| 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!
| Jtsummers wrote:
| > Some are definitely more secure than others, and
| defaults have a lot to do with it!
|
| That's great, naming those would have been better though
| since it would have actually answered the question.
| fmajid wrote:
| 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.
| j16sdiz wrote:
| https://support.apple.com/en-us/102651
|
| > 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.
| modeless wrote:
| 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.
| unloader6118 wrote:
| 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.
| modeless wrote:
| 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.
| xvector wrote:
| 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.
| joshstrange wrote:
| Why does your desire for complete privacy and _control_
| outweigh mine to keep a complete history of my
| communications?
|
| Why can you reach into my phone and wipe data you sent to
| me?
|
| Why are _you_ the final arbiter?
|
| Once you send a message it is _out of your hands_. You do
| not own that message. You do not have the right to
| dictate to others what they can do with what you send to
| them. That's life, that's reality.
|
| If you want to be able to delete your sent messages from
| other's devices, there are many apps out there that can
| provide it to you and both you and the person you are
| talking to can go in "eyes wide open" to what you
| agreeing to (I can delete messages I sent to you and you
| have no record).
|
| The potential for abuse of this is high and the vast
| majority of users would _not_ want this feature. The same
| way that mostly people probably shouldn't use ADP due to
| the risks, this type of feature will cause way more
| issues IMHO. It doesn't take much imagination to get to
| "Grandpa pressed the wrong button and deleted years
| (decades) of conversation from everyone's phone".
|
| I am not interesting my normal conversations potentially
| disappearing. That was not the agreement that we had and
| changing the rules later on that is gross to me. If you
| want disappearing chats or the ability to wipe all the
| messages you've sent there are other apps (with their own
| pitfalls, what if I keep my phone offline and never get
| the update to clear out your conversations?).
| IceHegel wrote:
| Digital feudalism is the norm today. We're all subjects, of big
| tech + the security state. Maybe it had to be this way.
|
| Just wish we had more options...
| fsflover wrote:
| Speak for yourself. Sent from my Librem 5 GNU/Linux
| smartphone.
| Hilift wrote:
| 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".
|
| https://www.infosecurity-magazine.com/news/apple-update-
| extr...
|
| https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-
| zer...
| snowwrestler wrote:
| Only if you have "Messages in iCloud" turned on, which is
| optional.
| modeless wrote:
| 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.
| fmajid wrote:
| 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.
| snowwrestler wrote:
| > 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.
| modeless wrote:
| 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.
| tgma wrote:
| 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.
| modeless wrote:
| 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.
| tgma wrote:
| 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.
| gU9x3u8XmQNG wrote:
| How are you achieving this? I'd like to know more. Thanks
| in advance.
| tgma wrote:
| 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.
| ronnieboy493 wrote:
| > Perhaps I should document it and link to it in detail
|
| Would be very interested in this.
| tgma wrote:
| Feel free to send me a note to the email in the profile.
| I will make sure to link to you when I get to documenting
| this.
| crazymalhavoc wrote:
| Yes please, document this, this sounds great!
| bouke wrote:
| How do you make backups of your data; e.g. Photos, Notes
| and Messages?
| renmillar wrote:
| I keep "optimized storage" turned off for Photos and back
| up directly from the filesystem. The photo library sits
| in $HOME/Pictures with all originals and the SQLite
| database intact - any regular backup solution works fine
| with this.
|
| For Notes, I've migrated to Obsidian since I couldn't
| find a reliable backup method for Apple Notes.
|
| Messages is tricky - I just screenshot anything important
| since it's so tightly integrated with Apple's ecosystem.
| Most of my important conversations happen on WhatsApp
| anyway, which lets me export anything I need to preserve.
| renmillar wrote:
| For Apple Notes, you can technically export using
| Shortcuts with a loop for entire folders, but it's quite
| limited. From my experience, it doesn't work with
| locked/encrypted notes at all - just returns blank pages
| when you try to access those. That's one of the reasons I
| switched to Obsidian.
| tgma wrote:
| You could always sync and backup (make sure it has a
| password so that keychain data is stored in the backup)
| your iPhone to your Mac since the dawn of iPhone OS. You
| can still use iCloud _sync_ for contacts and notes if you
| choose to for convenience, but I absolutely do not want
| iCloud _backup_.
| EduardoBautista wrote:
| 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.
| tgma wrote:
| This is demonstrably false: you can restore an iCloud
| backup on a new device without the original device
| password. Only with iCloud credentials which can be reset
| by Apple.
|
| Only enabling ADP, disabled by default and unavailable in
| UK, makes it like you describe.
| snowwrestler wrote:
| 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.
| modeless wrote:
| It is definitely not the default to exclude iMessage from
| iCloud backups.
| conradev wrote:
| Not if you have "Advanced Data Protection" turned on:
| https://support.apple.com/en-us/108756
| modeless wrote:
| 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.
| commandersaki wrote:
| To be clear, ADP default on would mean a massive influx in
| support requests for people that lose their data because
| they don't have the recovery key.
|
| Same reason FileVault isn't on by default on macs.
| matthewdgreen wrote:
| On the one hand: yes. On the other hand, the ADP setting
| is located in the moral equivalent of the bottom of a
| locked filing cabinet stuck in a disused lavatory with a
| sign on the door saying 'Beware of the Leopard.'
|
| Apple could do a lot to promote this feature to more
| advanced users, but they don't. I don't believe for a
| second this decision is unrelated to the government
| pressure they've been receiving from the UK.
| conradev wrote:
| It requires two physical security keys. You can promote
| the hell out of it, but having to buy and set up security
| keys is going to stop most people.
| qyckudnefDi5 wrote:
| You don't need security keys to enable ADP. You need to
| setup a Recovery Contact or create a Recovery Key.
| matthewdgreen wrote:
| This is not correct.
| tpmoney wrote:
| Is "Settings -> iCloud -> Advanced Data Protection"
| really the "moral equivalent of the bottom of a locked
| filing cabinet stuck in a disused lavatory with a sign on
| the door saying Beware of the leopard"? Where else would
| you put it? I could see an argument for putting it in
| "Settings -> Privacy and Security -> Advanced Data
| Protection" but that to me feels like a "six if one, half
| dozen of the other" change.
| matthewdgreen wrote:
| You could suggest it during initial setup. You could
| advertise the feature beyond a weirdly named setting at
| the scroll-down portion of the iCloud page. You could
| call it something more descriptive like "end to end
| encrypted iCloud", which would distinguish it from other
| security features. You could periodically ask users to do
| checkups, and verify that their backup contacts are still
| active and available -- even if they're not actively
| using ADP.
|
| The best analogy I can give is the way Apple gradually
| raised MFA from an optional feature with 1-2% adoption to
| a recommended feature that had majority adoption (even if
| it was not required.) They did this by heavily
| encouraging users to turn the feature on during setup,
| and then bugging them about it after setup. Apple is
| capable of encouraging and advertising security features
| it cares about, even when there's risk.
| charliebwrites wrote:
| Do we have any guarantee that enabling ADP utilizes a new key
| that isn't already in a previous non-ADP back up?
|
| Would be a shame if they claimed they can't decrypt but an
| old back up had the keys to the kingdom
| conradev wrote:
| You're trusting a whole lot of trust in the first place.
| But I imagine that they did not do that.
|
| I can't sign into Apple Music on Android because it doesn't
| support security keys - small price to pay.
| ThePowerOfFuet wrote:
| Not if you live in the UK.
| joshstrange wrote:
| I'm not sure how that, specifically, is Apple's fault.
| Maybe I'm missing something obvious but I think disabling
| that in the UK was Apple's least abhorrent option. They
| also put down their foot rather firmly on not providing a
| backdoor.
|
| Maybe people think that was all for show but I'm struggling
| to think of other examples of massive companies saying that
| so publicly/firmly. See also, all the times the
| police/FBI/etc have complained or even tried to force Apple
| to provide a backdoor.
|
| All that said, I guess a, very legitimate, argument could
| be made that if Apple provided ways to swap out iCloud for
| whatever service you wanted then there might be an escape
| hatch of sorts even if iCloud was compromised/limited.
| isodev wrote:
| 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.
| 9dev wrote:
| 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.
| StopDisinfo910 wrote:
| > 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.
| arghwhat wrote:
| 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.
| StopDisinfo910 wrote:
| > that my data would be (ab)used less on the Apple side.
|
| Honest question, apart for the marketing, why?
|
| Does Apple collect your data? Yes. Does Apple operate an
| advertising platform and give itself a large amount of
| rights on your data for advertisement purpose? Yes. Is
| Apple an American company and therefore subject to the
| non sensical and draconian USA spying laws? Yes.
|
| I don't really see how Apple is better than Google here.
| Both are pretty much equally bad.
| arghwhat wrote:
| None of your points is about whether or not the company
| spies or not. You also conflate the malice of the country
| they are in with the malice of the company itself.
|
| Google's primary business is and have always been ads,
| and they practically invented the kind of global tracking
| we have all come to know and hate. Google actively tries
| to expand tracking and ad exposure to their own benefit.
| See the Google TV Streamer home screen as an example of
| their ad behaviors.
|
| Apple has a miniscule ad business, and from the estimates
| I can find, the money in that is just a fraction of the
| Google search sponsorship they get (which counts towards
| the revenue of the same "services" bracket as their own
| ads). Apple actively tries to limit tracking, pissing
| other ad companies like Meta off. See the Apple TV home
| screen as an example of their ad behaviors.
|
| In general, having access to data and using it are
| entirely orthogonal, and many companies that _have_ your
| data consider it a liability they would much rather be
| without - it 's just sometimes hard to provide a service
| _without_ data passing through, and not everything can
| reasonably be E2E (either for technical or UX reasons).
| fsflover wrote:
| > Apple has a miniscule ad business
|
| They're expanding it:
| https://www.axios.com/2024/11/19/apple-news-ads-direct-
| sales...
|
| > many companies that have your data consider it a
| liability they would much rather be without - it's just
| sometimes hard to provide a service without data passing
| through
|
| Apple collects much more data than needed for the
| service. They also make it practically impossible to use
| the phones without giving a ton of personal information:
|
| https://news.ycombinator.com/item?id=39927657
| arghwhat wrote:
| There's a big difference between "expanding miniscule
| business unit" and company whose entire identity is that,
| so much so they're willing to pay the first company
| several time the revenue of _their_ ad business every
| year just to decide a default setting that might boost
| their ad business.
|
| And once more, you're conflating access to information
| and spying.
| znpy wrote:
| > Apple still allows to exchange comfort for privacy, if
| you want to.
|
| 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.
| iamkonstantin wrote:
| > 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.
| int_19h wrote:
| > 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.
| ysleepy wrote:
| How? Genuine Question, this is something I really want.
|
| macOS yes, but iOS?
| miki123211 wrote:
| 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.
| bayindirh wrote:
| You can remove said keys from your backups and devices, if you
| want, at least when you're outside UK.
| miki123211 wrote:
| Most users demand:
|
| 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.
| matthewdgreen wrote:
| 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.
| trollbridge wrote:
| You can set messages to auto-delete. (I do this so I won't
| get into the bad habit of relying on finding ancient
| messages.)
|
| But it's all or nothing and has to be applied to the entire
| account.
| fsflover wrote:
| > There's no way to satisfy those demands and have your
| desired level of security
|
| Google provides it:
| https://news.ycombinator.com/item?id=43933626
| modeless wrote:
| > There's no way to satisfy those demands and have your
| desired level of security
|
| False. Google has done it with their backups. And Apple
| already does it too! Keychain passwords, health data, and a
| lot of other stuff is end-to-end encrypted in backups even
| when ADP is disabled, with recovery options if you lose your
| devices, no yubikey required. They simply _choose_ not to
| apply the same solution to message data.
| tgma wrote:
| > Signal made different tradeoffs
|
| To some degree sure, but the real issue with Signal is the
| app UX royally sucks, not having to do much with security
| trade-offs per se.
| dostick wrote:
| 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".
| modeless wrote:
| ADP is overkill. Apple already end-to-end encrypts keychain
| passwords, health data, and other stuff even if you don't
| enable ADP. They need to do the same with iMessage, or
| otherwise they need to stop falsely advertising iMessage as a
| strong e2ee system when it literally uploads its encryption
| keys to Apple by default.
|
| Also, even if you enable ADP Apple can likely still read the
| vast majority of your messages in other people's default-
| non-e2ee backups. The bad default is the problem here.
| eddyg wrote:
| More people need to watch Ivan Krstic's Black Hat presentation
| to understand the efforts Apple goes through to ensure
| sensitive data (like the User Escrow Keys which get stored in
| Apple's Cloud Key Vault) is protected from adversarial
| attacks... even from inside Apple.
|
| https://www.youtube.com/watch?v=BLGFriOKz6U&t=26m50s
|
| (Be sure to watch through the section from 34m to 36m...)
| dogleash wrote:
| The problem isn't that the technical challenges aren't
| addressed. The problem is that no amount of tech can un-do a
| design that forces in a "just trust me bro" control
| relationship.
|
| For some people it isn't a concern and _that 's fine_, just
| so long as we acknowledge that it is a real and legitimate
| concern for other people, and _that 's also fine_.
| rasz wrote:
| > even from inside Apple
|
| sure, reminder 'Apple pays millions to woman after explicit
| photos posted online'
|
| 'Technicians posted the private photos and video from her
| iPhone after she sent it to Apple for repair, according to
| legal documents'
|
| https://www.telegraph.co.uk/business/2021/06/06/apple-
| pays-m...
| modeless wrote:
| Rogue insider threats are far from the only thing e2ee
| protects against.
| jwr wrote:
| You can turn it off.
| contact9879 wrote:
| This is a revision of a paper that first appeared as an eprint
| back in September when PQ3 was announced.
|
| https://eprint.iacr.org/2024/1395
| dang wrote:
| Related. Others?
|
| _iMessage with PQ3 Cryptographic Protocol_ -
| https://news.ycombinator.com/item?id=39453660 - Feb 2024 (267
| comments)
___________________________________________________________________
(page generated 2025-05-09 23:01 UTC)