The "flaw" was a choice of default preferences which are fundamentally a UX/security tradeoff: WhatsApp did not notify users about key change events by default.

The "flaw" was a choice of default preferences which are fundamentally a UX/security tradeoff: WhatsApp did not notify users about key change events by default. Those who value maximizing security at all costs, even to UX, disliked this default. WhatsApp was trying to switch end-to-end encryption to on-by-default for its over a billion users. An understandable requirement of doing so was to ship E2E encryption in such a way that did not involve changes to the UX. Whether or not this tradeoff is the best compromise is certainly debatable, but it is just that: a tradeoff, not a "backdoor", not a "vulnerability", and not a "flaw". It's a deliberate design decision. Why is it not a "backdoor", not a "vulnerability", or "flaw"? Well, let's examine what would happen if the default were reversed: let's say users were notified by default. Would this keep them more secure? I have doubts. These notifications are not high signal or immediately actionable. They do not indicate an attack. They indicate "a key changed" and whether or not that's abnormal is up to users to determine. The overwhelming majority of these events will be innocuous, leading to alert fatigue. It's also unclear how well an average end user would even understand or be able to react to these alerts. I am certainly willing to give WhatsApp's UX designers the benefit of the doubt here. UX design is hard and the tinfoil hat crowd saying things to the contrary have a history of producing unusable software by demanding security misfeatures which tick off a box on a threat model without actually improving user outcomes. While some people in the tinfoil hat crowd seem to think bombarding users with a bunch of low-signal security alerts is a good idea, practitioners working with IDS/SIEM systems probably have a different opinion: that low quality / low signal alerts are worthless. There are solutions to providing high-quality signals about key change events to users without asking them to manually confirm key fingerprints in person, but they are complicated, haven't been largely deployed, and it's still unclear how they'll work... I'm talking about CONIKS and Google Key Transparency, which implement logs which users' own devices can monitor to discover changes to their keys as advertised through a key server. These systems can ask a very simple question to users when this happened: "Did you just log in on another device?" If they didn't, the user can select no and publish an alert indicating they were compromised.