Imagine there is a break in a cryptographic algorithm, say AES256-CBC.
Now can I replace it in my messaging app, without having to coordinate with every other messaging app provider?
Suddenly governments have a lever to prevent adoption of securer standards.
Why wouldn't you be able to bump the API of your messaging app? Sounds orthogonal to me. You are required to publish a working and open API. You are doing it. They can consume the new API with the new default cypher.
Why not?
Can you come up with examples?
Are you worried that they would use automation to generate a new "API" per second, so consumers would need to play catch-up?
Do you think that would hold in court, if/when this initiative has been legislated?
A messenger just refuses to upgrade.
So Alice who was sending Bob messages with no problem yesterday, today breaks.
So back to having to use the same messenger.
iMessage and WhatsApp both already have encryption backdoors that escrow the endpoint secret keys or plaintext to cloud services, undermining the end-to-end encryption. That ship has sailed.
iCloud Backup was introduced in iOS 5, released in 2011. It escrows either message plaintext or device secret keys (depending on OS version and configuration) to Apple, encrypted with Apple keys (non-e2e) and readable to Apple (and the FBI and others, some of whom access the data without probable cause or a warrant under FAA Section 702).
WhatsApp backup backs up chat plaintext to cloud services (I think Google is the default), also non-e2e and readable to the cloud storage service (who often shares it with government snoops without a search warrant, also under FAA Section 702). They added an e2e option late last year but it doesn't matter if you turn it on because none of the people you chat with are likely to have it enabled (so all of your chats will be backed up in plaintext from the other end).
OK so that doesn't support what you said at all. That's an optional feature (that I do not use), and it's not in any way a "backdoor". Unencrypted backups are a front door. Yes, that iCloud Backups aren't E2EE is bad. Arguably worse (and this would be a more productive area for the EU and others to focus on) is that they're the only general wireless option, that's MUCH more of a nasty tie than messaging. iOS should have a standard API for backing up that any service at all (including a server one runs themselves) can implement and then get pointed at. But none of that is a backdoor in the encryption of iMessage and you do the whole space a real disservice by conflating them.
It doesn't matter. Everyone you chat with uses it because it's on by default, so all of the iMessages you send and receive are backed up in effectively plaintext to Apple (who turns them over to third parties).
> But none of that is a backdoor in the encryption of iMessage and you do the whole space a real disservice by conflating them.
Unencrypted (or encrypted to the ZK middle service, in this case Apple, being the operator of both iMessage and iCloud Backup) key escrow of end-device secret key material in a system that is advertised as end-to-end encrypted is indeed a backdoor in the end-to-end encryption of that system, as now the secret keys don't exist just on the endpoints - the transit service in the middle has a copy of them, allowing message decryption on a non-endpoint as they transit the middle service.
That is definitionally not end-to-end encrypted. It's end-to-middle-and-end encrypted if the middle device has a usable copy the endpoint secret keys, which Apple does.