This is a great illustration of how you can only take Apple's security claims seriously if you don't understand them.
One of the primary benefits of end to end encryption is that it can protect messages from an untrusted carrier. In other words, a proper encrypted messaging setup is not vulnerable to man-in-the-middle attacks
>When sending and receiving Signal, iMessage and WhatsApp messages, Beeper Cloud's web service acts as a relay. For example, if you send a message from Beeper to a friend on WhatsApp, the message is encrypted on your Beeper Cloud client, sent to the Beeper Cloud web service, which decrypts and re-encrypts the message with WhatsApp's proprietary encryption protocol.
> Using native chat apps independently may be more secure than connecting to other encrypted chat networks with Beeper Cloud.
So is the issue that there's a cloud web service that interacts with some of the proprietary protocols? That definitely is another point of trust and it would seem weird that they do it that way, especially for protocols that aren't proprietary. For proprietary ones, this might be necessary to dodge intellectual property liability claims that could take the whole thing down, which is a great argument for not allowing security-critical proprietary code to be protected by law in this way, but that's just a plausible reason for them to have this problem, not a reason it doesn't matter
I appreciate you pointing out specifically what the problem was rather than just repeating that it was insecure, rather than how, and admit what I said was, as far as I now know, wrong
That said, what are the odds that Apple would accept a solution that was encrypted on-device? If this were feasible, would Apple still block the interoperation with their network, and do we agree on whether they'd be wrong to?
I think the main issue I see with iMessage that this highlights is that it's presented in a way that's deceptive to its users, and thus might give them a false sense of security in their messaging. An interoperating client on android is a band-aid for this problem at best, but it's a weird move to block it. I guess for now there's the plausible deniability of what appears to be a real issue though. The way Apple's messaging has addressed it still leaves a bad taste in my mouth, because they do not make clear that what you point out is the issue
>what are the odds that Apple would accept a solution that was encrypted on-device?
We probably agree that the odds hover just above 0%
>would Apple still block the interoperation with their network, and do we agree on whether they'd be wrong to?
We could agree in principle that they would be wrong to, _if_ there were a clear path to continuously verifying that a third party client is behaving above board. Unfortunately that's just not the case. AFAIUI, this is still an intractable issue with encrypted communications. Is it an impossible problem? Probably not, but the amount of sustained effort this would require from Apple (and the 3rd parties) seems unworkable. So given that reality (I think), I don't think Apple are wrong to disallow third party clients for their E2E encrypted service.
>The way Apple's messaging has addressed it still leaves a bad taste in my mouth, because they do not make clear that what you point out is the issue
Yeah, I don't disagree here. I can only say that this is par for the course when it comes to Apple's PR. They would basically never explicitly state that their E2E encrypted service is at risk of a MiTM attack due to third party clients. Instead we will get very generic language and be left to fill in the blanks ourselves.
Keep in mind that you are linking to the FAQ for the original Beeper (now renamed Beeper Cloud), this is a Matrix-bridge-based where the bridge and homeserver have access to the plaintext. You could still technically self-host both components if you wanted to.
Beeper Mini was a completely self-contained app that implemented the iMessage protocol on-device and did not use bridges. Its only optional cloud component was a push notification bridge that wasn't actually given the E2E keys (the cloud proxy would receive your messages but not be able to decrypt them, instead it just sends a push to wake up your device which will fetch and decrypt them).
The discussion of the technical details of this has such a low signal-to-noise ratio, and I think the blame for that lies mostly with companies who try to set themselves up as infrastructure but maintain significant secrecy about how their tech actually works
One of the primary benefits of end to end encryption is that it can protect messages from an untrusted carrier. In other words, a proper encrypted messaging setup is not vulnerable to man-in-the-middle attacks