First, when you buy a new iPhone, the way you authenticate yourself is by entering your Apple ID and password. Once entered, your new device will begin receiving iMessage data. This means that Apple is capable of provisioning a virtual device with your credentials, which will receive your messages. From there, they can be either stored or forwarded to third parties.
Wrong. As others who have examined the protocol have noted, your password is used to unlock a keybag on the device itself. Apple doesn't have your password (only a secure hash) and therefore can't unlock the keybag. The security depends on the strength of your password, which is a weakness, but it is in your control, not Apples.
Yes, the binaries of any system can contain arbitrary spyware or be infected with such at any stage from development through to decommissioning. Open source is no absolute protection against that.
At the moment we are trusting that companies are not baldly lying to us, even Google.
> As others who have examined the protocol have noted,
> your password is used to unlock a keybag on the device
> itself. Apple doesn't have your password (only a secure
> hash) and therefore can't unlock the keybag.
Re-read what I wrote, and think about what it means.
Setting up iMessage on a new iPhone does not involve copying a "keybag" (sic), inputting a private key, or any other form of strong client-side authentication. All you have to do is sign into the device using your Apple ID, and you can then receive iMessage messages.
If there were any additional barrier preventing Apple from provisioning iMessage entpoints, iPhone users would not be able to activate iMessage with only their Apple ID.
Do you understand now?
> Yes, the binaries of any system can contain arbitrary
> spyware or be infected with such at any stage from
> development through to decommissioning. Open source is
> no absolute protection against that.
It's not an absolute protection, but it is very good protection.
Staying inside your house is not absolute protection against being eaten by bears, but your chances of being eaten by bears are much much lower than if you walk around Yellowstone dressed in steak.
Re-read what I wrote, and think about what it means.
I think it means you have a false belief about the limits of the system.
If there were any additional barrier preventing Apple from provisioning iMessage entpoints, iPhone users would not be able to activate iMessage with only their Apple ID.
Wrong. Apple doesn't have your password. Only a hash. Verifying against the hash allows apple to add another device to the backend but does not unlock the keys to the message history. Only the password does that.
There are other sources around the net that you can refer to to understand more about how such a protocol can be built, but I don't have a lot of faith in you as a conversation partner now that you've demonstrated that you can't be bothered to inform yourself before responding incorrectly with condescending certainty.
> Verifying against the hash allows apple to add another
> device to the backend but does not unlock the keys to
> the message history
Isn't this what I've been claiming? If Apple can provision additional endpoints, they can provision a virtual endpoint which receives messages and forwards them to third parties.
Doing that wouldn't provide access to the history. Unless they always do this for every single device, there is no mountain of data to analyze.
The point we are discussing is not whether iMessage provides perfect security. The point is that iMessage doesn't give Apple a stockpile of personal data that can be indiscriminately targeted at any time the way GMail can.
I'm not saying it's a panacea or arguing in favor of Apple. iMessage proves that Google could engineer a system to protect users privacy by not stockpiling data if they wanted to, which you have incorrectly denied.
> iMessage proves that Google could engineer a system
> to protect users privacy
iMessage does not protect privacy, because Apple is capable of intercepting your messages messages and sending them to third parties. To be a private communications medium, it should be considered impossible for messages to be intercepted.
The only thing worse than a product that doesn't offer privacy is a product which claims to, but actually doesn't.
IMO, Apple's claim that iMessage is private is irresponsible because it endangers people who take that claim at face value.
No modern computer can be constructed by an individual without trusting a corporation not to have coopted some part of the system. Therefore no communication system can exist that meets your criteria. (E.g. Because the CPU could be compromised)
Your argument is the equivalent of 'we can't trust any corporation'. It's a coherent position to take but it is extreme and doesn't lead to meaningful discussions about what is possible.
> Therefore no communication system can exist that meets
> your criteria. (E.g. Because the CPU could be compromised)
For the purposes of this discussion it's reasonable to assume that consumer hardware does not contain backdoors, because such extensive compromise of the computing infrastructure would require conspiracy on a massive scale (approximately every electronics manufacturer in the world).
Any evidence of this? I had read and posted about the same, but more recently found an older discussion on HN (which, absurdly, I cannot find now) which explains in more detail how the end to end encryption actually works and does so in a way that Apple almost definitely cannot intercept the plaintext messages.
Short version: Users can enable iMessage on their devices by signing in to their Apple account. Therefore, Apple is capable by themselves of configuring which devices receive messages from particular accounts. Therefore, Apple is capable of configuring a device you do not control to receive your messages.
They could do so, yes, but it would pop up a message on your actual devices which you would have to agree to before that device can receive and decrypt new messages.
You still don't understand how this works. Apple can't complete the provisinig process alone - the user unlocking the keybag on the device with their password is an essential part of provisioning a device.
When a new device is added to the keybag, the other devices report the change - this isn't controlled by the server and isn't optional. Apple can control the transport infrastructure, but they cannot enrol new devices into the cryptographic session without the user being involved.
Fair enough, but actually your other point doesn't stand either because the prevailing understanding is that the keybag mechanism allows the clients to detect and report when another device is provisioned, and that the password is needed to join a new device to the keybag.
Therefore although Apple could add another device to the communication protocol, without the password another device cannot be added to the encryption session, or without alerting the end user.
Wrong. As others who have examined the protocol have noted, your password is used to unlock a keybag on the device itself. Apple doesn't have your password (only a secure hash) and therefore can't unlock the keybag. The security depends on the strength of your password, which is a weakness, but it is in your control, not Apples.
Yes, the binaries of any system can contain arbitrary spyware or be infected with such at any stage from development through to decommissioning. Open source is no absolute protection against that.
At the moment we are trusting that companies are not baldly lying to us, even Google.