A custom-written third party client could theoretically do this (and mitigate most of the other attacks here). What Apple provides won't help with this though.
Think of an SSH client that never verifies host keys and never warns you when they change. That's basically what iMessage is.
Even a custom-written third party client still doesn't eliminate the requirement to trust Apple. They're delivering your closed source operating system, which could very easily include hostile behaviors like key logging and screen recording.
At least with iMessage, the entire ecosystem is managed by one company, so you only have to trust one company.
> Even a custom-written third party client still doesn't eliminate the requirement to trust Apple. They're delivering your closed source operating system, which could very easily include hostile behaviors like key logging and screen recording.
It does eliminate the requirement to trust Apple actually. That's the point of (real) end to end encryption. With a custom client, you could use them as a conduit to deliver your message without using any Apple software on either client if you wanted to. As long as the users can verify the keys.
> At least with iMessage, the entire ecosystem is managed by one company, so you only have to trust one company.
I just explained at least 3 different reasons why that is not true. You can fully "trust" Apple and still compromise an iMessage conversation.
>> Even a custom-written third party client still doesn't eliminate the requirement to trust Apple. They're delivering your closed source operating system, which could very easily include hostile behaviors like key logging and screen recording.
> It does eliminate the requirement to trust Apple actually.
As the parent comment indicated (emphasis added), in an extreme hypothetical scenario, Apple could (be compelled to) write a backdoor specifically for your device that captures all text and touch input events, or periodically takes screenshots and sends them somewhere.
You're missing the part where "custom client" means you aren't using an Apple device at all, if you don't want to be.
This is like sending a PGP message over gmail using mutt on linux via IMAP. Google owns gmail, but they can't backdoor you or read your message in this scenario. Any non-broken secure messaging protocol should have this property, regardless of if people use it that way. This is what end-to-end encryption means.
> Any non-broken secure messaging protocol should have this property
Okay then, tell me how you could build a system that
* Guarantees secure transmission of public keys
* Can be installed safely on a closed-source operating system
* Is impervious to the whims of the hardware vendor or the operating system vendor
* Is sufficiently straightforward that mums everywhere will happily use it
* Doesn't require users to become security experts
Given the practical realities Apple has to contend with, I think they've done a pretty good job -- certainly a lot better than what anyone could have expected, arguably a lot better than anything comparable that has come before it.
No, Apple has definitely done worse than what we have expected. Worse, they haven't provided what they claimed. That being a secure end-to-end messaging protocol.
This discussion about backdooring applications isn't even interesting or relevant here. The protocol itself is not secure.
Think of an SSH client that never verifies host keys and never warns you when they change. That's basically what iMessage is.