With Google password-based encryption or Keychain, you lose your data if you lost your devices and forget your Google Account password. I suspect that is a use case that is too risky (frequency x impact of data loss) for the Apple customer base that they don't want to risk it.

The e2ee for Google backups is based on the user's screen lock code, not account password. https://security.googleblog.com/2018/10/google-and-android-h...

Unlike the account password that users need only once in a blue moon, users are required to practice entering their screen lock code at least once a week to continue using their device. Probably more often in most cases. And it's much shorter.

Chrome sync also supports e2ee, and using it requires that you set a sync passphrase that is separate from your Google account password. The account password is known to Google servers and so can't be used to secure e2ee data. The screen lock code, in contrast, is never stored in a form accessible to Google.

Yea, the problem I am pointing to is not the security side, but backup resilience aspect; in any of those scenarios (device passcode^ as you suggest for Android, or account password by default for Chrome, or a separate encryption password for Chrome), if you lose your client device and you forget the password, there is no way to get back the data, by design. I have personally encountered anecdotal situations where this happened to family and they would hate to lose their photo library, so it is not that unlikely. Me personally would opt for losing it--that almost certainly won't be the trade-off an average Apple customer wants to make. They likely expect from Apple to be able to give them their data back if their device is stolen and they have forgotten everything and go to Apple Store and present an ID.

^: I concede that this might be an acceptable thing to assume they won't get to forget. At the same time, I don't think this is a worthwhile encryption given the average 4-6 digit passcode length because you do not have the ability to mix in on-device keys (otherwise backups can't restore in other devices without another key).

I think you missed my point that the screen lock code is not at all like the account password in terms of resilience to forgetting. I know people who have forgotten their account passwords and lost photos etc, similar to what you describe. However, I know nobody who has lost access to the phone they use every day by forgetting the screen lock code. That is very unlikely.

I addressed it in the footnote: 6-digit encryption key without tying it to device is just security theatre (and people might still forget: many users are old). Longer passwords people will forget.

It's not security theater. You didn't read, or didn't understand, the blog post I linked that explains how it provides strong security despite the low entropy passcode by using secure elements in the datacenter. I believe Apple does the same for the categories of data that are e2ee in backups when ADP is not enabled, such as keychain passwords (iMessage should be in this category and the fact that it's not is my whole complaint).

Here's that link again: https://security.googleblog.com/2018/10/google-and-android-h...

I stand corrected then. I knew about Apple doing HSM-based key escrowing server-side, but did not know Google has applied the same technique to Android backups.