3 ms·
> I thought iMessage was implemented as a protocol with end-to-end encryption. At least Apple claims that it is. Sorry, let me be more precise: iMessage is not
by dsacco 9y ago
> I thought iMessage was implemented as a protocol with end-to-end encryption. At least Apple claims that it is.
Sorry, let me be more precise: iMessage is not a true "zero knowledge" protocol construction - Apple could, theoretically, port your iMessage history to another iPhone without using your device's private key or iCloud password. This might be helpful to read: https://blog.cryptographyengineering.com/2013/06/26/can-apple-read-your-imessages/ https://blog.cryptographyengineering.com/2013/06/26/can-appl...
> I don't see how security and usability can be opposites. They are in conflict with each other to an extent, but increasing security doesn't necessarily hurt usability or vice versa. There are many products which have become both more usable and more secure over time, or which are both more usable and more secure than their competitors.
Let me try to formalize it a bit. Security is offered through confidentiality, integrity or authentication (increasingly integrity is just a sub-feature of authentication). Before you add authentication, a user might have been able to access their data or account somewhere without needing to log in. But access control was required, so now they need to enter a password, which requires password management of some kind.
When you add a security service, what capabilities in the application are now impossible, or more difficult? Maybe those capabilities were undesirable or negligible, but they were there; by removing those capabilities you have added a cost, or a friction in its place. A possible workflow has been diminished, even if its for good reason.
In practice you can reduce the impact of these quite a lot, i.e. encrypted messaging doesn't have to be PGP, it can be like iMessage. But fundamentally security (or cost) and usability have been transacted.
- mikeash 9y agoInteresting, so it's "end-to-end" in that the messages are encrypted on one end and decrypted on the other without being decrypted in between, but nothing stops Apple from inserting themselves in the middle without our knowledge? I agree that the two are generally in tension, but I don't think they're opposites, and they don't always fight. Consider, for example, switching from a plaintext network protocol to one that uses encryption with an unauthenticated key exchange. The result isn't particularly secure since it's vulnerable to a MITM attack, but it's a definite improvement since it shuts down passive snooping, and it doesn't impact usability at all. Or consider something like HSTS. You shut down a real avenue of attack and the user never even sees the difference.