This isn't the first time, nor will it be the last: the only reason I'm actually using iCloud Keychain is because, despite always turning it off and feeling like I needed to keep doing it over and over again every time I got a new device, one day I was in a discussion with someone about it and I went to show them how I turn off most of the iCloud features, and I discovered I had actually failed and now had already been using iCloud Keychain and so all my passwords were already in it.
I had the exact same experience with iCloud Drive (or whatever it is/was called) years ago. I kept turning it off and never agreed to use it and one day discovered it was on anyway and a bunch of my stuff was already in the cloud.
This is precisely the problem. Apple treats its users as dumb cattle. "We know better. Shut up and be happy with what we force down your throat."
Of course, Apple can do no wrong. Forced lock-in? "Don't you feel so much more secure now that you're firmly in our garden? Our walled garden that you cannot escape from?"
Because automatically sharing credentials between devices by default is what most people want, especially younger customers for whom this has always been the normal state of affairs.
What you say makes sense for new installs, although even there an explicit and optional consent screen is warranted before doing something as privacy- and security-sensitive as syncing passwords to the cloud. But it's not definitely what's wanted by most people who previously had the feature disabled before the OS update.
Actually, I figured it out, when an app I wrote, that uses the keychain, started allowing me to log into the app, using Sign in with Apple (which has some stuff that is only available when the login is set up), on devices that were not the ones that I set up.
In my case, I liked that, and so will my users.
But I do think that it could be problematic, if this means that authorities could now get ahold of your keychain, when having it restricted to a single device, avoids that.
If people wonder about things, they should install Little Snitch and see how often apple apps phone home. It's amazing. Not only after install, but hours and days later will apps start quietly phoning home.
One thing I learned from using Little Snitch is that a lot of Apple apps are seemingly immune from these types of firewalls, due to Apple shenanigans around k-ext signing etc [0].
Ref also [1]:
> In Big Sur Apple decided to exempt many of its apps from being routed thru the frameworks they now require 3rd-party firewalls to use (LuLu, Little Snitch, etc.)
> Q: Could this be (ab)used by malware to also bypass such firewalls?
> A: Apparently yes, and trivially so
But another way around is the way VMWare Fusion let you set up networking in Bridged mode. Any traffic from the VM went through without a peep from Little Snitch running on the host. No reason malware couldn't be designed in the same way.
VMware Fusion isn't sandboxed and installs daemons running as root (which requires Gatekeeper approval or bypass to run, followed by an admin password to install the daemons).
AFAIK, XProtect is the only remaining line of defense against malware installed in this way.
So, Little Snitch helps unless your adversary is either really good at what they do or really rich. Maybe nothing can be done in those cases, but I'd like to see the limitations of such software placed on the box.
Isn't the workaround here to back up your keychain file, remove your passwords from the keychain, update to Sonoma, disable iCloud keychain, then import the backup? Not a trivial process, but should be easier than the author's attempted workaround of disabling SIP and installing while offline.
Long term I suspect the actual answer will be that if you don't want to use iCloud Keychain then you just can't use the keychain at all, which is a shame as it once was one of the good parts of macOS.
> Perhaps disabling System Integrity Protection disables the malware scan too? I haven't checked this, but it's not really viable for me as a Mac software developer, because I need to test the same runtime environment as my users, otherwise I could write code that works for me but not for my users.
I'd be a bit careful here by the way. Disabling SIP results in other weird differences too, that may cause programs to run for you but not most of your users.
For example, LD_ and DYLD_ environment variables are no longer sanitized [1] for system processes.
Fun fact: the GitHub Actions Mac environment also disables SIP. So it might run for you and in CI, but not for your users.
I disabled SIP in our CI environment because with ~5 Xcodes installed and VM images that were reset to a baseline every day or two the malware scanning often literally didn't finish before the VM was reset and it was forced to start over, and while it was running builds took 2-3 times as long.
I probably could have done something fancy where the VMs were left running a day or two before being frozen and deployed, but disabling SIP was the much simpler solution to the problem.
About suspicious things lately, I remember that it regenerated my FileVault (disk encryption) password after the past two updates. It happened to more people out there.
The latest 'national security' bill signed into law this April grants the US govt access to any and all commercial hardware. This as I understand it, am I wrong?
Doesnt this imply that every cloud service should be assumed insecure?
macOS yes, though it breaks a lot of the “just works” style integration. On iOS I don’t know how you’d install anything beyond the apps included out of the box so it would be very limited.
An example of "Keychain" abuse is how Facebook so disgustingly tracks you even after you delete all apps, and can track you even after you restore an iCloud Backup ON A NEW PHONE!
• It shows my previous accounts even after I delete the app.
• Clearing Safari's cache does not work.
• Disabling iCloud Drive and iCloud Keychain does not work.
• Even completely signing out of iCloud does not work!
----
WHY can't the user see this data?
WHY can't the user delete this data without going through the app?
WHAT ELSE do apps store on our devices that we aren't even aware of? (This is just what we can see: The list of saved accounts for "quick login")
HOW MANY other apps are secretly doing this?
WHY does Apple even allow this in the first place??
Worst of all, WHY aren't more people raising more of a ruckus about this extremely appalling practice?!
I had to blink twice last time when I installed Sonoma on a new partition that I did not have to provide a wifi password.
This appears to confirm that. While I can understand that some people would appreciate this, I'm not exactly chuffed by a fresh install silently grabbing passwords from an old install.
It has the SSID in plaintext in current-network and preferred-network, not the passphrase. I’m not sure how it’s obfuscated or encrypted but it is not plaintext
The other commenter is correct - the last (few?) Wi-Fi passwords are stored in NVRAM so that the recovery environment can connect to the network more conveniently.
Even with so-called standard data protection, iCloud Keychain passwords are always end-to-end encrypted, and Apple cannot decrypt them.
"For additional privacy and security, 15 data categories — including Health and passwords in iCloud Keychain — are end-to-end encrypted. Apple doesn't have the encryption keys for these categories, and we can't help you recover this data if you lose access to your account."
> If it did turn out that Apple was actually able to do what they claim they can't…
My friend, I'm afraid I have no idea what you mean. What do you believe Apple claims they can't do that conflicts with this? (If your answer is "end-to-end encryption", Apple has supported this for at least a decade.)
> "How do we validate claims of end-to-end encryption?"
I'm not a security expert, and you can't prove a negative, so AFAIK the only evidence is the lack of reported incidents where Apple's iCloud Keychain data has been directly hacked or compromised. Given that iOS and iDevices are among the highest-value targets for hackers and nation-states, that seems like reasonably solid evidence.
From a business perspective, lying about such a thing would have virtually zero upside but unimaginably massive downside. It's a great Apple-hater fantasy, though.
> so AFAIK the only evidence is the lack of reported incidents
Thank you. That's exactly what I wanted to hear from you. The link you provided is in no way, shape or form actual evidence of what you're suggesting.
> From a business perspective, lying about such a thing would have virtually zero upside but unimaginably massive downside.
What are users going to do? Buy a Surface tablet and a Samsung phone?
> It's a great Apple-hater fantasy, though.
I just dipped my toe into the Apple waters again and bought an m1 air a year or so go. I'm currently shopping for a used iPhone.
I don't have brand loyalty and I use what works, and it just so happens that Apple has been making stuff that works pretty well in my opinion recently. But I'm under no illusion that I can trust them.
It's not just trust in a company. Matthew Green was geeking out about iCloud Keychain privacy a few years ago. He sometimes speaks of contacts in Apple security who are really committed and competent engineers. Their professional reputations are on the line too. Nothing would damage their careers like a backdoor that conspiracy types love to speculate on.
Apple claims they cannot decrypt. What will you do if that claim turns out false? That is what the person you are talking with means, and it is very clear throughout the conversation.
Great, so what does he mean by "how would you explain the source that you linked to?", since no part of that conflicts with what I've said or anything else? (I really appreciate the parsing help!)
The source you linked to makes one claim yet you can't verify that claim - that's what they mean.
And we have plenty of historical examples, including recent ones, that big companies are simply lying through their teeth almost every time they open their mouths. Companies that rely heavily upon marketing are lying more so than others.
"Macs don't get viruses" claim made while several Mac viruses existed at the time. It's been lies for decades.
