HN2new | past | comments | ask | show | jobs | submitlogin

Unless I’m mistaken literally all of these services are locked down too, and few have E2E encryption… iMessage is indeed “Apple-only” but the rest is on “all” platforms only for purely economical reasons, as much as iMessage is on Apple platforms only for the same reason.

At least iMessage falls back to SMS (soon RCS) when available, which is much more ubiquitous than the rest tbh…

If you truly want to avoid a lock down you should host your own messaging solution.



I don't know why you're getting downvoted, but I'll throw my hat in this ring as well:

Some of those services require individual opt-in to turn on e2ee. Some of them don't support e2ee for group messaging. Of the services listed that do support e2ee, I have the most trust in Apple's (well, Signal's, but..) being "actually" [0] and "only" [1] end-to-end encrypted. The entire basis of that trust is the money they've spent positioning themselves in the market as a privacy-focused brand.

Meta runs three of the listed services (whatsapp, facebook messenger, instagram), and their positioning is not exactly "privacy-focused". I haven't looked into Telegram much, but I would want to at least understand how they generate revenue before trusting them. Neither Discord nor Slack are what I would call privacy-focused. Signal is probably better than iMessage in terms of how much I trust their company, their clients, and their protocol, but its adoption is so vanishingly small among my friends that I stopped asking people if they used it.

[0] I've seen services in the past [0a] that have tried to argue that as long as every link is encrypted from originating client through servers to destination client, or from originating client to destination server, then it's "end to end encrypted"

[0a] https://hackernews.hn/item?id=21528437

[1] that is, not only are message contents (and as much metadata as is feasible) encrypted such that the same ciphertext passes all the way through the system and the recipient's client can decrypt the ciphertext, but also 1. the intermediary service doesn't have a copy of the recipient's secret key and 2. the plaintext wasn't encrypted also to a public key belonging to the intermediary service or some other party.

edit This other comment https://hackernews.hn/item?id=38537444 talked sense into me -- Apple doesn't seem to have designed iMessage to keep up with the times, crypto-wise. There's a huge, aging installed base that admittedly gets updates more often than any other competitor in their space, but that still means that iMessage has to be able to talk to them. I guess this is similar to the deprecation of SSL 0.9 and TLS 1.0; browser vendors collectively decided to kill them when a low enough proportion of servers were using them, but I don't know if Apple would be willing to cut off the older devices to make things better for owners of newer ones.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: