Telegram: Voice Chats 2.0:Channels, Millions of Listeners, Recorded Chats

Threema solves it by scanning QR codes; for that, you need to physically meet with the other recipients, they need to bring their devices and scan each other QR codes (note that Threema still supports only one device per recipient; otherwise, the users would need to scan each other QR codes for each device).

It is not something that an average Telegram user would be willing to do.

The other bigger drawback with E2E is that the servers of those platforms don't store the chats permanently (they store it for about 30 days or so to deliver the messages to devices when they come online, depending on the platform). So syncing chat history across devices gets affected by this choice (it could still be done, but the complexity and speed of syncing grows a lot).

Wire does E2E for all chats and syncs all chats across devices. But it too doesn't sync chat history on newer linked devices. It also took the (what I consider as inferior) choice of using Electron for its desktop apps, which makes it quite sluggish.

That's an issue with your client and protocol, not with e2e

> No shared history for group chats.

Same

> Scaling get progressively harder with increasing participants.

Same

> No transcoding for video.

Now that's a more palpable issue. Also no size reduction of photos which is probably more used as a media.

That’s a privilege many people don’t have. Think about sexual preferences, controversial opinions or health problems that can be disadvantageous in their career or when obtaining insurance. Or that aren’t problematic now but might be in the political climate in 20 years.

You could argue that people worrying about this still have the choice to use an E2E encrypted messenger. After all different needs are served by different products. But if this behavior becomes the norm, people who hide possibly disadvantageous information can be identified simply by their messenger use, partially defying the purpose of hiding their information in the first place.

I consider this a very strong argument for privacy as the default regardless of particular people's lack of a need for privacy.

EDIT: Removed remarks that could be misunderstood as snark.

Privacy is definitely not binary, but to me it is a bit like using Libre software. You can't realistically expect to live on the 21st century internet with the entirety of services and viewpoints it offers and only use Libre software. At this point you have to either follow your values and stick to a very small part of it that is guaranteed to work on your browser rejecting non-Free javascript, or you can make concessions and accept a bit of proprietary bits here and there. But you can still decide to be Libre-first and accept non-Libre from there, on a bit-by-bit basis. That is what I and others are talking about with e2ee first: Instead of asking "what is worth being hidden and being made public", I feel the more just mindset should be "supposing everything is private by default, what can I disclose and to whom". Your threat assumption regarding your conversations is a good example: of course every software has bugs and all your messages could be read by Telegram. But you're behaving as if Telegram might read it one day, when I believe you should believe as if Telegram is reading it every day. The danger is not that Telegram can make a soap opera out of your drama but that the whole world can.

As you say you take care what you write about and that is a good thing to do. So, following up: if you don't want anyone to be able to read it, then let's go to the end of this and make sure no one physically can read it, by default. Instead of asking what kind of conversations require e2e, let's ask what kind of conversation doesn't require e2e

Ps: hard drive image clones should also do the trick.

I am choosing iMessage with complete e2e every time I can, but iMessage is iOS only and telegram is many years ahead in user convenience even from it.

You might as well continue pushing for pgp for secure email.

User convenience is not optional.

Signal, for example, copies the received messages into per-device queues that belong to the same identity. The problem for the user is that the user has no visibility into what is really assigned to his identity and where copies of his messages are routed encrypted by which keys; it could be used to implement anything between CALEA to Prism access.

I'm not familiar with the Matrix approach, so I won't comment on it.