[jmillikin]

  > 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.

[embolism]

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.

[jmillikin]

  > 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).

[embolism]

Then you haven't explained how Apple could join another device to the encryption session without the user's password.

[embolism]

   IMO, Apple's claim that iMessage is private is irresponsible because it endangers people who take that claim at face value.

By this logic, your claims are irresponsible. Apple's claim is true and you are misleading people into not taking advantage of the privacy they offer.

[LoganCale]

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.

[jmillikin]

See my first post in this thread.

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.

[LoganCale]

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.

[jmillikin]

In the case of a wiretap, I assume Apple would choose not to notify the target that they have been wiretapped.

[embolism]

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.

[embolism]

You are pretending that this is equivalent to asserting that they have access to arbitrary message histories, which they in fact do not.

[jmillikin]

No, I'm not. At no point have I ever claimed that being able to intercept messages is equivalent to having access to previous messages.

[embolism]

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.