Many software engineering adjacent courses, starting with AP Computer Science A, are heavy on the Java-style OOP. And you're never designing an actually complex system, just using all the tools to "properly" abstract things in a program that does very little. It's the right idea if applied right, but they don't get a sense of the scale.
The first place this bites a new SWE in the rear, the database. "Let's abstract this away in case we ever want to switch databases."
It's about as secure as any other non-E2EE chat or other kind of service, except it also has E2EE mode, which is limited to 1:1 chats for fair reasons. Plenty of other services advertise themselves as "secure," which doesn't mean a lot. So I don't see anything misleading there.
Aside from that, I don't trust Telegram or its CEO at all, partially because of what you said about open-sourcing (or not) and partially because of his ties to Russia and Azerbaijan.
This was a response to the comment about nuclear weapons proliferation being a cat out of the bag. It's not out of the bag yet. Iran has been "nearly there" for several years already, and that's only wrt the enriched uranium, not the actual weapons.
Another important example because they're at war, Ukraine. And in the vaguely possible event of an Asian Pacific war, Japan and Australia have no nukes, but that's more by choice.
There aren't very many nuclear-weaponized countries in the world right now. Otherwise, the whole Iran Nuclear Deal issue would've been moot. Even Russia won't hand over nukes to Iran.
Positive feedback loop isn't the only risk of nuclear power. Fukushima had a negative void coefficient too, right? Rather than pretending there's negligible risk, I'd rather say it's there but the alternatives are worse.
Separate from our other convo, I just found this spicy note in Telegram's manual: "Multi-device End-to-end encrypted chats are a mess[...] Most of our competitors (notably, Whatsapp and iMessage) solve these problems in ways that make their end-to-end encryption useless (this is a big topic, so requires a separate manual)." And links to a TODO page. Can't just say that and leave us hanging!
The worst thing for me was that app versions expire pretty frequently with no warning, then you just stop getting notifications. Which is extra annoying cause I'm only on it for some bar trivia group that totally doesn't need e2ee (or even e).
Also, Facebook Messenger recently added e2ee, which made it glitchier, fussier, and not really any more secure given that the key is a short numeric code.
Maybe it's similar to adding a new chat participant, except your client says "btw this is also me." I used that way when designing a toy e2ee app a while back. Or maybe there is a central repo of each user's per-device pub keys, and your client signs its updates to it using the original pub key so it's tamper-evident.
Maybe there's some key derivation mechanism so the new pubkey is self-evidently owned by the first one, never heard of one though.
Someone else here probably knows more than me. I don't want to speculate too much about what it actually does, I just know that the original device takes part in authorizing a new one, so it seems like they can't do it on their own.
Multi-device mode is new enough that I might be wrong about this, but afaik the web client still needs to get the priv key from your phone, so they can't authorize a new client unilaterally. Or it'd be a really silly hole if they could.
Edit: Meant to say, the web client needs to somehow be authorized by the phone, not that it takes the privkey exactly. Probably gets a new key that the phone stores, so the phone is still the "master" device. I wouldn't expect the phone client to happily send the chat history to a new device it didn't authorize locally.
I'm not sure if they can add a participant to an existing conversation, and if they did, your client would at least know. Also don't remember if the client will send message history, but I think Signal doesn't.
The simple bad scenario I have in mind is when you're initiating a new chat and the mitm it from the start. Or they could do it halfway through, which would notify you that the other end's key changed, but that message is non-threatening enough and happens enough for random other reasons that most people would probably ignore it.
No, your client asks Signal's server for the other end's public key. There's fundamentally no way for Signal's server to prove to your client that the pubkey you're encrypting for is indeed the one owned by the phone number you keyed in.
The first place this bites a new SWE in the rear, the database. "Let's abstract this away in case we ever want to switch databases."