I’ll cross post what I wrote to folks on the MacRumors forum:
I believe this may be an intentional change to temporarily avoid a security issue, which otherwise hadn't been fixed yet: https://theevilbit.github.io/posts/cve-2022-32929/ (as shown in the blog post and embedded Twitter thread linked earlier)
> The issue is that an attacker can invoke the `AppleMobileBackup` utility and make a backup to a custom location. Thus completely bypassing the protected backup location.
The issue was "fixed" on the macOS side by updating the binary to not support this behavior, but the problem is that you can still swap in a binary from an older version of macOS to get around this.
So, presumably, the problem is blocked from the iOS side now until the issue is resolved from the iOS side to make the older macOS binaries not work with newer iOS. I think it's safe to assume there wasn't time to fix this fully (since it needs to behave differently depending on the version of macOS making the request to avoid making older Macs entirely incompatible despite the prompt) and therefore the fix is temporary, but it would be a shame if it was permanent.
I think the old binaries can be patched for new iOS. Or new binaries can be patched for custom backup locations. Or perhaps the open source libimobiledevice [1] can be used somehow.
In any case, requiring passcode might be a good permanent solution after all.
I believe this is theoretically fixed in Ventura via the mechanism of always checking notarization status upon execution, in which case Apple could publish a notarization revocation ticket for the old insecure AppleMobileBackup binary to make it inoperable without significant intentional user action.
I don't think it's to avoid a security issue. Almost any Mac made in the last 5+ years has had sufficient security to stand up to nearly nation-state attacks on its disk contents.
What I think is far more likely: it's a dark pattern to discourage people from doing their own backups.
One of selling points of iCloud is scaring people into the possibility of their stuff being lost from their phone getting destroyed/lost/stolen.
Up until this change was implemented, it was painless and transparent to do backups of your phone. You just needed to have your Mac or Windows computer turned on and your phone on WiFi with power. It Just Happens.
This is also a convenient way for law enforcement to get people's iMessage history, because iMessage backs up by default to iCloud, unencrypted, including the user's iCloud encryption keys. Without this, if LEOs wanted a criminal's messages they'd have to pound sand.
We know that the FBI has at least a somewhat sympathetic ear at Apple, probably because keeping the FBI happy means Congress doesn't start applying levers on the company.
Given the timing which is right after they deployed the enhanced iCloud security that supposedly E2EE's everything in a (again, supposedly) very secure way, I suspect this was a tradeoff they made to keep the FBI/Congress happy, while also boosting revenue.
'Hey, we'll nerf the local backups, and don't worry too much about enhanced security, most people won't turn it on because it's a pain and we'll put scary warnings on it.'
I believe this may be an intentional change to temporarily avoid a security issue, which otherwise hadn't been fixed yet: https://theevilbit.github.io/posts/cve-2022-32929/ (as shown in the blog post and embedded Twitter thread linked earlier)
> The issue is that an attacker can invoke the `AppleMobileBackup` utility and make a backup to a custom location. Thus completely bypassing the protected backup location.
The issue was "fixed" on the macOS side by updating the binary to not support this behavior, but the problem is that you can still swap in a binary from an older version of macOS to get around this.
So, presumably, the problem is blocked from the iOS side now until the issue is resolved from the iOS side to make the older macOS binaries not work with newer iOS. I think it's safe to assume there wasn't time to fix this fully (since it needs to behave differently depending on the version of macOS making the request to avoid making older Macs entirely incompatible despite the prompt) and therefore the fix is temporary, but it would be a shame if it was permanent.