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.
> 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.
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.
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).
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.
Funnily enough, most users I speak to use WhatsApp and they're mostly concerned about their contacts and pictures. I've rarely heard someone say "this is a disaster!" because part of their WhatsApp messages weren't backed up to the cloud the moment they switched phones.
Truth be told, I don't think most users even care that the company their messenger comes from can read their messages. All of the people I chat to on Telegram seem absolutely fine with it. I begrudgingly accept their chats (I don't want to be that guy that people need to install a special app for to communicate with, as much as I'd like Matrix or XMPP to succeed).
And to be honest, who cares if Apple's backups are encrypted. They can push a software update to undo that encryption any time they want to. The only people you need to protect your backups from are criminals (but that's what your password and 2FA is for) and law enforcement ("but I'm not a criminal! I have nothing to hide!"). You can't use Apple's phone/Facebook's messenger without accepting the risk that Apple/Facebook will undo all the security they claim to have added to their software.
> They can push a software update to undo that encryption any time they want to
Of course this is true, but it's such a reductive view of the broader security picture.
If messages are plaintext, they can be leaked by a hacker, accessed by an insider, not wiped from some drives they throw out for recycling... None of these attack vectors require the provider being evil, so removing them already reduces your exposure by a lot.
Secondly, if you're being targeted by hackers that have already gotten into the messaging provider, looking at some rows in a database is waaay easier and safer than somehow sneaking exhilaration code into the next release build of the app.
Finally, if your main adversary are government agents with a warrant, there is a huge legal difference between forcing the company to ship malicious code (possibly to all users) and simply printing out a few rows in a database. IIRC Apple has already won at least once in US court on this exact point.
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.
Yes, but that setting is different from what disappearing messages offers, since it only applies to your account and not the accounts of your conversation partners. Disappearing messages is a really nice feature that’s widely supported across many messengers. Apple is really the exception for not offering it.
I have used Telegram, iMessage, WhatsApp and Signal extensively in multiplatform settings. Only iMessage and Telegram have good overall UX (with the latter far more featureful and smooth than the former). Sure all "work" to some degree but the overall poor UX shows. It's more about polish issues and death with a thousand cuts, rather than one specific problem, although in the case of Signal, the out of place "Story" bullshit is a turn-off.
You can disable stories. The UX still is shit. Again, death by a thousand cuts. As for Indonesia or whatever, I am sure people Stories increases engagement that boosts Signal executives morale thinking they are more relevant and can stick it to Zuck. I just don’t want it in a serious messaging app that hopes to be used in place of iMessage or Google Messages and since we are debating opinions, I take Apple’s judgement on design over aggregate clicks from Indonesians.
Do you have some basis for what you say? It's just a rant at this point; it hardly has a specific criticism and fabricates things about people you probably don't know. Whatever you think, that doesn't make it so.
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.