Apps (such as Signal) that care about end-to-end encryption do their own key management. So, Apple / Google servers only ever see ciphertext, and don't have access to the key material that's used for the encryption.

Afaik, e2e messengers don't include ciphertext with push notifications. It's an empty push to wake the client. Then the client contacts the origin to fetch the ciphertext.

This is how it used to work; notifications can be encrypted now and Signal uses an extension to decrypt them.

A Signal developer 12 days ago said Our FCM and APN notifications are empty and just tell the app to wake up, fetch encrypted messages, decrypt them, and then generate the notification ourselves locally.[1]

[1] https://news.ycombinator.com/item?id=47723445

Ah, yes, they would be right. I feel like I had read that someone had migrated at some point, maybe it was WhatsApp or something.

Sending public keys through the notification system is an unnecessary complication.

Which clients?

Isn’t that what Contact Key Verification solves? Or do I misunderstand how that works?

... and hold participants' private keys truly private, which you cannot verify without a rooted phone.

You don’t need a rooted phone. An open source OS with reproducible builds is enough. That way you can validate what the code does without giving up verified boot, or opening up another attack vector, etc.

> You don’t need a rooted phone.

I disagree.

1. I need to be able to change SSL root cert, disable SSL cert pinning, and intentionally MITM installed apps and see what they are sending about me to their servers. Open source OS isn't enough if the apps aren't open source.

2. "Apps sending information about me to their motherships that I don't consent to them sending" is a MUCH bigger problem these days than people messing with SSL, so I accept the risks of (1)

3. Verified boot is big brother's dream. I want to be able to verify my own OS.