This sounds like a violation of the CFAA per unauthorized use of computer resources. Think Apple would be held liable for it?

What computer resources are being used without authorization?

They gave Apple authorization to access their phone (the phone is not Apple property) in order to copy certain things into the cloud.

They uploaded new software and downloaded data they were not authorized to download without getting permission first.

I'm sure there is some cover your ass clause in the EULA that tries to protect them when they (accidentally or on purpose) violate the CFAA, but, in this case, they pretty clearly did things that exceeded their authorization.

The relevant part of the CFAA is a.1 (I removed the bits that are irrelevant):

> (a) Whoever—

> (1) having knowingly accessed a computer without authorization or exceeding authorized access, and by means of such conduct having obtained ... restricted data, as defined in ... causes to be communicated, delivered, or transmitted, or attempts to communicate, deliver, transmit or cause to be communicated, delivered, or transmitted the same to any person not entitled to receive it ...

https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act

That definition quickly becomes absurd. If I run "cat a.txt b.txt" but only give it authorization to read a.txt, does that mean Richard Stallman (or whoever wrote the program) is breaking the law? You might say consent is implied in that case but:

1. I thought implied consent was out of fashion these days

2. What if it's something like an IDE that reads the surrounding directories? VS code does that and I certainly didn't know that feature even existed before I first opened it, so how could have given authorization? Is Microsoft in breach of the CFAA?

> 2. What if it's something like an IDE that reads the surrounding directories?

Reading the directory in a software running on your computer is not the problem. The question is, is data from the surrounding directories transmitted to somebody else's computer, a.k.a. The Cloud?

The data wasn’t transmitted, communicated or delivered to Apple. It’s E2E encrypted, so Apple can’t receive it.

The service isn’t capable of delivering the keychain to anything other than the user’s own devices.

Who do you think the other end is?

It’s Apple. They are the other end where the traffic is decrypted.

And yes they can see your stuff. We know this because law enforcement gets access to it all the time.

The keychain is just another keystore.

Please don't spread lies.

> They are the other end where the traffic is decrypted

Only for certain types of data, with certain settings. That does not include the keychain.

https://support.apple.com/en-us/102651

> And yes they can see your stuff. We know this because law enforcement gets access to it all the time.

What law enforcement typically gets access to is iCloud Backups, which is not end-to-end encrypted by default (but can be) and is not a mandatory feature. iCloud backups do not contain your keychain.

> The keychain is just another keystore

Nobody has said anything else? But Apple does not hold the key to decrypt it.

Your link (Dec 14, 2023) says they E2E encrypt it and do not store escrow keys, but this link (May 13, 2022) says they store escrow keys for keychain:

https://support.apple.com/guide/security/secure-icloud-keych...

Did they announce this change? It's a pretty major UI departure. In particular, if you have one Apple device and loose it, the 2022 article implies you can recover your keychain, but the 2023 article says you're completely screwed.

A lot of people rely on iCloud backup. It seems like there should be a device-wide toggle that lets you choose between the two behaviors for things like passwords, health data, and all the other E2E apps.

The platform security guide PDF (May 2022) on the page you linked is a lot more detailed and explains it better https://help.apple.com/pdf/security/en_US/apple-platform-sec...

The escrow is only an additional layer of security - your device still has to decrypt the downloaded keychain contents using your password AFTER proving to escrow that you're allowed to download the encrypted keychain using device or SMS 2FA or an iCloud security code.

This happened to me with iPadOS 17 beta 4 back in July. https://appdot.net/@lapcatsoftware/110776034855270972

I've also been getting a "Verify Your Recovery Key" warning in Settings on both iPad and Mac ever since beta 4 of iPadOS 17 and Sonoma (and that continues to this day). Settings app was crashing too in beta 4. It was a really bad beta for iCloud stuff.

Also worth noting: iOS and macOS re-enable Bluetooth after every update. https://lapcatsoftware.com/articles/bluetooth.html

Thank for the warning. I use Bitwarden exclusively. It didn't happen on iPhone 13 Pro 17.1.2 -> 17.2. Currently upgrading iPad Pro 4th gen as it took until today to get iPadOS 17.2.

Thanks for telling me about this. It's definitely not acceptable to appropriate such sensitive data without consent.

It’s not being appropriated. It’s E2EE. It’s a bug, but nothing more.

Doesn't feel like a bug to me. After disabling iCloud Passwords I see a big nag in the Passwords menu asking me to enable it again; I don't remember that there on iOS 16.

And when it was enabled there was a nag for Passkeys or password family sharing or something like that. I guess they want people to use that now.

Also I don't understand how you could screw these things up repeatedly for so many features. iMessage is another one that iOS loves to enable again. I just checked: it's enabled again. Turned it off. And the one with Bluetooth that lapcat mentioned. I don't believe these things to be bugs.

But they really crossed the line for me with Passwords.

> Also I don't understand how you could screw these things up repeatedly for so many features.

Seems like a generic bug in the settings system which is fairly complex. Pretty easy to see how something like that could happen.

I agree. It’s easy to see how a user hostile setting would go unchecked by a large corporate company that doesn’t benefit from protecting the privacy of its users.

That’s a weird conspiracy theory. How does anyone figure Apple benefits from this. How is the setting even ‘user hostile’?

I consider sending anything up to the cloud without user's consent is pretty hostile. Passwords especially. I don't care if they claim it's E2EE; programmers and implementations are fallible and I thought a key part of Apple's whole value proposition is it's supposed to retain control in the user's hands.

> I consider sending anything up to the cloud without user's consent is pretty hostile.

If not illegal.

Do these "generic bugs" ever happen the other way around? Meaning, do they ever disable any form of communication to Apple or are they always enabling?

Nobody at this big corporation tested the settings before shipping? It should probably require FaceID and some steps.

That said, if you enable E2EE I don’t think it’s cause for much concern. You already use their closed source OS.

Software has bugs unfortunately.

This is a bad response to Apple stealing personal information from millions of people. OP is not alone when it comes to iCloud partially or completely enabling itself upon updates. The problem is that malware is perfectly legal as long as you have some EULA somewhere to cover it.

The hyperbole seems unnecessary and imo is unproductive.

You shouldn’t call it a hyperbole. Sometimes you have to point things out for what they are rather continue to pretend that it is normal.

Personally I don't let Safari store anything, so there's nothing to sync, even if it was turned on without my consent.

I recently got an OS update on my Macbook Pro and after reboot it forced me to change my password because "you can't have the same password on your laptop as in your icloud account". It's amazing how much apple feels the device I bought actually belongs to them :/

Thank you for taking the time to post, wouldn’t have caught it otherwise

Do you have Advanced Data Protection enabled on your Apple ID?

Configuration Profiles can also be a good way to more strongly force certain settings on devices, including that functionality be disabled. They’re how MDM works in most corporate settings.

Although I'm not particularly happier over here on Android, this makes me glad I switched away from the Apple ecosystem a decade ago. It's a shame as I do occasionally get hardware envy.

Thanks for sharing the story.

For me it's the Medical ID data that turns itself on in iCloud storage devices backup details. I've noticed this last night, turned it off and it's morning here (Europe) and that switcher is set to on again. I have Health app uninstalled and set to off in Apps using iCloud page.

Imagine being in China and finding this out after an update.

I used an iPhone a few years ago and when setting it up, I made sure to turn off all iCloud stuff. When it was time to get a new phone, I noticed all my pictures were in iCloud.

I also did not like how hard it was to try and keep Bluetooth and Wifi turned off. Regularly it would nag me to connect to an open Wifi when I was sure I switched Wifi off completely. Turns out iOS re-enables both Wifi and Bluetooth after OS updates and you can't completely switch them off from the quick settings. If users privacy was so important, wouldn't you want to make sure all that stuff would not happen?

Also, it's good practice to reboot your phone one in a while, so why isn't there a reboot option in iOS?

> Also, it's good practice to reboot your phone one in a while, so why isn't there a reboot option in iOS?

Out of curiosity, what is the advantage of rebooting your phone? I disn't do it for a couple of months and I don't see what gets "better".

Besides, turning it off and on again will reboot it too. Just slighty more inconvienent :)

Modern smartphone security relies on verified boot which cryptographically verifies various components in the boot process all the way to the kernel and beyond to make sure they have not been tampered with. This not only protects against physical attack vectors, but also remote as it can detect and prevent malicious modifications to the firmware and OS.

For example, this makes malware persistence much more difficult, as verified boot checks for integrity at every boot and reverses any unsigned changes.

Persistence on iOS and Android is very difficult. As an example, at least on iOS, threat actors have sometimes failed to achieve persistence, so they hijack the shutdown process and simply fake shutdown by animating the shutdown flow. The user thinks they've shut down the phone, but in reality the device was never shut down and never went through the verified boot process. However, since Steve Jobs decided iOS never needs a manual reboot, gaining persistence may not even be necessary, because people don't reboot their iPhones.

Doesn't that contradict itself? If the attacker fakes the shutdown process (and/or the reboot process), how does a shutdown or reboot help if the process never actually happens?

Sorry my reply was poorly written. Like with anything, there will be vulnerabilities and techniques that allow for verified boot bypass, which most are not trivial and which need to be fixed, but that does not mean verified boot isn't valuable and working. It means extra cost and work for threat actors and the example was just how it was once done, by not attacking verified boot, but the process before it. Maybe because true persistence was too hard to achieve at the moment, thanks to properly implemented verified boot.

Once the battery runs out completely, then you can be sure verified boot is helping you out. I'm sure there are now other mechanisms that fixed the example of faking the boot process I wrote about earlier.

> Imagine being in China and finding this out after an update.

Or in the US. Apple and Uncle Sam wants your passwords.

I mentioned China because there Apple's e2e encryption does not apply.