Which is kind of the point of all these services.
> you can't sync devices easily
Apple seems to handle this pretty easily with great UX.
I switched to a S20 this year. iMessage is one of the only things that I truly miss about my old iPhone.
Sigh. This again. Ok.
If have end-to-end encryption, you can't read messages on newly connected devices, unless you somehow pass encryption keys to your new device.
If you do not pass keys between devices, and can still read messages sent from other devices, you do not have end-to-end encryption.
If the only thing you put into device when connecting is your login/password, then even if Apple does retrieve keys from your device and passes it to new device, it can pass it to themselves and gain access to your super confidential messages.
So, no, Apple does not handle this pretty easily.
Source: our product has _real_ end-to-end encryption, and it gives the users a rather big amount of discomfort. If you are told you have really secure messenger, but you do not enter anything but your login/password, well, I've got bad news for you.
> Which is kind of the point of all these services.
If your point is privacy, and you really care about it, just run your own communication server for $2/month. You have all the niceties of server side search and device sync, and none of the pain in the ass that is brought by E2EE. And if your privacy isn't worth $2/month, then you probably don't need E2EE either.
> it can pass it to themselves and gain access to your super confidential messages
They can also send your PIN, private keys, all logins and passwords to their own servers, or simply log chats from the system keyboard and UI or any of the OS layers they control. The same is true for any app running on iOS/Android. If you don't trust the OS there is no working around it in software.
According to my rather brief examination of iMessage, you can't verify key fingerprints in iMessage. It means that Apple can install MitM on a probed subject any second, and you would never know that it is there. See:
You <-- end-to-end-encryption --> Apple MitM <-- end-to-end-encryption --> Your buddy
You have _zero_ control over it, and the only thing keeping your secure and private is Apple's pinky promise.
> The same is true for any app running on iOS/Android.
Umm, no. There are such things as open source, verifiable builds, and, yes, decentralized messaging protocols. You can take an open source client (for example, from a reputable source like F-droid), and connect to a server totally unrelated to client developer. You can run an encryption protocol where you can actually exchange public keys, verify your keys fingerprints, and confirm the identity of your chat partner. That's what people really concerned with privacy and security do. Others are satisfied with a promise that sounds good enough.
Indeed, that's what I meant in the last paragraph. It also means an open source, verified client, with fully secure encryption, is still powerless against the OS capturing keystrokes. You have to rely on that pinky promise either way unless you control the hardware.
But yea, it is correct that you can always prove something cannot be done once you tighten up some mutually exclusive constraints. Question is how much it maps the real world and whether some cannot be loosened.
You see, e2ee is only practical against the service provider that you have reasons not to trust. But if you don't trust Apple, then you should not trust it all the way to the bottom: and at the bottom we see that iMessage apps give a user zero control over said e2ee. You don't really know who decides your messages on another end: your chat partner or MitM proxy.
If you trust Apple that they do not have such proxy, you might as well trust them to not snoop on your chats and store them unencrypted on Apple's servers, saving you from a lot of problem worrying about your keys, devices, etc.
Yea, but most people don't think about security in terms of black and white, and neither should they. There is no such thing as "real security & privacy" and it's completely disingenuous to suggest that you've found it when it involves trusting you or your company as a third party in placement of, say, Apple.
As a universal statement, this is far too simplistic of a comment about a system's security and trust. Security without a notion of threat model is quite irrelevant. There's quite a large spectrum between trusting Apple with respect to the binary they serve me not being actively malicious and by-and-large does what it says it does; that they are not actively presenting someone else's key to my chat parties, vs. trusting them with my unencrypted data on their servers. At the very least, the latter would not be safe under subpoena, or data leak, or a rouge employee, for instance. Plus, in practice, if they present a malicious binary to everyone or substitute keys, someone likely notices at Apple scale. If I am that interesting of a target for them that they decide to target me specifically, I have bigger worries, as I am trusting the OS and hardware anyway (and still, there's hopefully some level of forward secrecy). In fact, to me, and to vast majority of people, a random exploit in their OS or physical theft of the phone carries a higher risk than Apple directly attacking them.
So, no, I fully reject that iMessage security is substantially equivalent to say, "Facebook Messenger" (even if run by Apple). I posit the delta is almost as much as HTTPS with Let's Encrypt cert compared to plain HTTP. And yes, there are no doubt use-cases that iMessage is ill-suited for; doesn't mean we should just give up on it for the other 99%.
Trust in entities is fleeting. You trust an entity today, you might not trust it tomorrow. End-to-end encryption, in contrast, is not fleeting, as long as you trust math.
And if someone's trust for his own service is fleeting... uh-oh.
I definitely won't trust my own code to keep me alive, if that's what's preventing a government from killing me or something.
There's a very good chance my homemade server config or encryption code has a big side channel vulnerability or something.
Also, if you are concerned about privacy, chances are, you are not a private individual and have specially trained people to install that server for you.
Then again, even if you DO need encryption to transmit a critical password or something, well, XMPP clients developers know their business (at least, some of them do), so it is unlikely that you'd be able to screw up something.
The typical idea is being concerned that a state will physically seize your server—you know, real security and privacy concerns.
> Also, if you are concerned about privacy, chances are, you are not a private individual and have specially trained people to install that server for you.
Is this not ultimtely what iMessages is to people?
Also, if you are concerned that state will seize your server physically - then you should probably put the server to a place where it can't.
I’m not sure what the point of pretending to be ignorant about encryption is supposed to do.
Of course, if you want a cozy sense of being secure, instead of real security, you say, 'I use end-to-end encryption which I was told makes reading my messages impossible'. With iMessages you can't really verify if your messages are not being sniffed (unlike Signal, or XMPP, I must add), and we now have proven Apple DOES have a potential way to read your messages if they really want it. But you TRUST them not to read your messages. So why bother with E2EE at all, if you already trust them not to spy on you?
(Also, how come people who religiously insist on using an always-on E2EE for their chats are totally fine with Gmail which stores every mail totally unencrypted?)
Among other things, you don’t write all the software that goes on your computer, let alone build the hardware yourself, so you’re not “really” secure at all. And because you do claim “real security”, I can’t square your statements with any threat model I can imagine.
I definitely would trust Apple more than a random "XMPP servers are really good these days you don't need e2e when you run your own" random commenter on the Internet.