Why would it? Diffie-Hellman key exchange is a thing.

An argument, not a valid argument.

"How can we be sure a 3rd party implements the encryption properly" is the counter-argument.

How would you refute that? Trust users to check that some code is the same on both devices? What would prevent a bad actor from MITMing the whole thing from the start?

Pretty simple actually, it either decrypts successfully or it's not implemented correctly. Same way push notifications work.

FWIU, this[1] was decrypting imessages successfully. But was also storing all your imessages in a serverside database accessible to the server (instead of being e2e encrypted like imessage is supposed to be) and leaking the authentication token to access the imessages over unencrypted HTTP.

https://arstechnica.com/gadgets/2023/11/nothings-imessage-ap...

Hmm, but it’s OK to trust that web browsers implement TLS properly? And your router isn’t MITMing you? Or your SSH app exfiltrating all your server information? Why is this different?

> And your router isn’t MITMing you

Can it do so if the encryption and key management is at the client?

> Or your SSH app exfiltrating all your server information

That's a small niche, and most service don't expose SSH to public.

> OK to trust that web browsers implement TLS properly

hmm, you may have a point, maybe they'll ensure that only whitelisted browsers can access it, like Chrome with DRM for HTML. Only purpose is public safety. /s

> What would prevent a bad actor from MITMing

It's not man-in-the-middle, it's man-on-the-end. If your chat app wants to spy on you, there is nothing you can do, but at least it becomes obvious and easy to analyze because it's client side code. It's not a counter argument to interoperability. You need to trust both sides, the same way web works.

Encryption makes it practically impossible to transform messages between different protocols, since the cyphertext contains not only the text content of the message, but also formatting, some attributes (e.g. `reply_to`). Even if it were the same, E2EE algorithms also differ between protocols, and you can't reencrypt the message for other protocols server-side.

I thought the opposite, at least as a first thought: Roughly two or three years ago, facebook announced their intent to integrate their messengers - so that you could send a message from your fb inbox to whatsapp, from whatsapp to instagram. And since whatsapp has E2E as a major part of their marketing, I'd think adding it to FB and IG rather than removing it from WA would be the way to go.

(though of course it's not REALLY: it harasses you to backup your messages all the freaking time, and when I say "never", as I ALWAYS do, it asks again in 2 weeks. I assume once they're backed up on Meta's servers, there goes the encryption. But that's a parlor trick and they STILL have that data, as I assume at least 80% back up anyway and the rest is mostly worn down by the constant prompting.)

Except this change seems to be triggering a reversal of that integration: https://help.instagram.com/654906392080948

That's because a single org controls all three messengers and they can develop them to converge to the same message format and to the same encryption mechanism. At the same point Signal or XMPP will use a different format and a different mechanism, making them incompatible with messages from Meta, unless a client with a private key reencrypts them.

WhatsApp doesn't backup to Meta servers. It only supports Google Drive on Android and iCloud on iOS.

You can also optionally encrypt the backups.

but then, why do they not take no for an answer and keep nagging about it, and interpret "never" as "not in the next two weeks, but ask again, please!" if they don't have an interest in having these messages there?

(and no, "it's to help YOU, the hapless user! is of course never the right answer. Corporations never do things for users without an interest of their own.)

That's why we need internet standards for IM. Sadly, not many people seem to care about if their messenger is XMPP compatible or not.

I'm not sure what Diffie-Hellman has to do with anything here, but yeah, there's no reason encryption would prevent interoperability as long as all clients are using the same protocol (which they would have to do anyway in order to be interoperable).

So is key management, key exchange and discovery, revocation, etc.

That stuff is very hard to get right within a single app.

Now do it across mutually-antagonistic companies with incentives to not cooperate.

Interoperability and encryption do not contradict each other. OMEMO is such a federated encryption protocol for example.