thats part of why NIST updated their password rotation recommendations from 90 days to indefinite: people pay lip service to security if it is too inconvenient. you have to try to meet people where they are.

Preaching is not a strong motivator for long.

because if your parents are not smart, you're not likely be either.

It also gives some valid argumentation to people who promote race theory... which is, obviously, a racist ideology.

Smart people tend to have gifted children, this is, unfortunately, factual.

Being smart is a poor proxy for success, you have to have access to the right knowledge and resources at the right time, and often the “smart” move is short term.

It could be argued (and often is), that the reason intelligence is strongly predicted based on heritage (though of course: not guaranteed) is due to your parents interactions with you as a child.

like many things, I’m not qualified to answer.

Sufficed to say that some of the smartest people I personally know are more limited in their success than some of the confident yet much less intelligent people I know: who seem to be, in general, much more successful.

Nice try sneaking Slack into a 1:1 secure messaging debate… That’s like comparing a corporate chatroom (with admin access) to a personal diary.

Telegram’s client-server default, with optional E2EE, is closer to pre-Microsoft Skype: tight client/network control, 1:1 focus, no major leaks despite a major spotlight on it for a decade+

You dodged Skype because it’s not the piñata Slack is. Weak move.

Re: Slack; yeah, that’s not apples-to-apples for secure 1:1 messaging (it’s enterprise group chat with admins often having god-mode access anyway).

A better comp might be old-school Skype pre-Microsoft: client-server backbone (after ditching full P2P), tight client/network control, no E2EE, yet no major leaks despite heavy scrutiny.

It worked for millions in a “good enough” threat model without pretending to be bulletproof. Secure messaging apps that default to client-server (like Telegram’s non-secret chats) are similar. They pay lip service to groups but prioritise 1:1, and the security theatre of optional E2EE doesn’t change the core trust calculus.

If you don’t trust the provider, don’t trust their code. Simple as.

The standard threat model for secure messaging does assume a potentially compromised provider.. that’s exactly why the client-trust issue matters.

If the provider is compromised (maliciously or via hack/subpoena), they can alter the client to capture data before E2EE engages, rendering it moot.

E2EE protects past messages from server-side access, sure, but it doesn’t prevent future compromises via client backdoors, which are a real vector under laws like Australia’s TOLA or US CLOUD Act, again: providers have been compelled to modify software (e.g., Lavabit’s resistance led to shutdown, but others comply quietly).

You’re right that client-server alone fails catastrophically on server compromise, but E2EE isn’t a panacea if the same actor controls the client supply chain.

Trust is binary: If you don’t trust the provider, don’t use their client. reproducible builds help a tiny fraction, but for most, it’s unverifiable.

In partial-trust scenarios (e.g., worrying about hacks but not full malice), client-server with distributed keys and TLS can suffice without E2EE’s complexities.

I’m hand-waving a bit here; but I’m talking about peoples actual realities, not some hypothetical.

How does E2EE hold up if a subpoena forces a silent client update? You won’t know, and history shows that’s the path of least resistance for adversaries.

That’s fair for a purely malicious provider in client/server mode (they’ve got the plaintext on the server, no fancy footwork needed), but that’s missing the forest: if the provider is adversarial, E2EE doesn’t magically fix it either. They control the client codebase and distribution (app stores, updates), so backdooring it to snag plaintext pre-encryption is trivial—it’s basically a built-in supply chain vuln they own.

Point is, E2EE only “protects” against server-side compromise if you assume the client is golden, which loops back to trusting the provider not to mess with it. If they’re bad actors, they can (and govts do compel them to) inject client-side leaks (again, see Australia’s TOLA Act forcing software mods), or historical cases like Lavabit’s key handover pressure.

In trusted-provider scenarios (which is most users’ reality), client/server + TLS + encrypted storage suffices against external threats, with less complexity than E2EE’s multi-device key mgmt headaches.

If distrust is total, bail! Because neither model’s your friend. Supply chain worries aren’t a distraction; they’re the real vector, as SolarWinds and Jia Tanning of xz remind us. E2EE’s great tech, but you are pretending that it is a cure-all, which ignores practical realities.

I know it's trite to bring in logical fallacies, but you're hinging a response on an appeal to authority without tackling the logic head on. Worse so, you're also engaging in a bit of hyperbole.

E2EE provides strong theoretical guarantee's, but not so if the client is under the network providers control. Governments have already pressured companies to alter clients (Australia's "Assistance and Access Act" allows compelling backdoors in software).

If you don't trust the operator, it's irrational to trust the client they supply, they can do anything before E2EE even kicks in.

I'm not saying E2EE is useless technology, it's just useless in cases where the provider and the network are the same thing. You are gaining very little over TLS in those cases. You can configure "self-deleting" messages if you're worried about other clients logging in.

Regardless, most reasonable security researches I know are actually more concerned with supply chain attacks than ensuring E2EE everywhere, which is precisely what I'm arguing.

client-server is good enough, if you trust the server.

If you don't trust the server, then you shouldn't trust them to supply you a client either. Since a client is basically "whatever code they decided".

Very few people are building from FOSS, and those that do will include binary blobs too. It's theatre.