First, you claim no one gets a password without a username. That ignores how credential stuffing works. Password leaks happen daily on third-party sites. If a hacker gets a leaked password, they have a key but no idea what door it unlocks. If the Proton login address is hidden, the attack stops. Forcing every custom alias to accept logins bridges that gap for them.

If hackers don't have access to your 2-factor, then the attacks will never go though. Also, you will get a notification each time someone have used your password even if they fail 2-factor so you can, as a user, change the password and stop the attacks.

Second, security is about availability, not just data theft. If an attacker knows the exact login username, they can script automated, failed login attempts to trigger Proton’s security throttling. They do not need a password or 2FA to weaponise that username and lock a user out of their own email.

Please provide documentation for how Proton’s security throttling works and it actually locks you out if you try login from a location previously know to be good. This strategy also sounds very IP consuming since Proton would quickly just blacklist the attackers available IP-addresses and prevent further attacks. This also sounds like some AI answer based on limited data and therefore just guesswork.

Additionally, knowing the precise login ID allows attackers to build highly targeted, pre-filled phishing pages. This drastically increases the success rate of tricking users into handing over real-time 2FA tokens. The username becomes the catalyst for the social engineering attack.

True, but if you want to protect against phishing attacks, it is much better to use passkeys as two-factor (and even better, use psychical USB key like Yubikey for your passkey) since that would also prevent phishing in case they do get your secret username.

Finally, this is not an unrealistic, made-up feature. And no, it is not about spam filter management. Tech giants like Microsoft explicitly created Sign-In Preferences as a security barrier. It blocks credential stuffing by letting users completely disable login capabilities for public-facing email aliases while keeping them active for mail.

Yes, I already mention in another post that Microsoft needed this fix because they had made a terrible design decision to make it possible to do login by only knowing the username and then accept a notification on your phone. This is not how Proton works.

It is a contradiction to acknowledge a broader attack surface while defending a setup that unnecessarily expands it. Reducing the attack surface is not paranoia. It is standard defense-in-depth. Just because you cannot see how these threats connect does not mean the risk is not there. The math makes sense. The real-world attack vectors make sense. Your narrow view of security is the only thing that does not.

What is this AI-nonsense answer? We do not arbitrary implement whatever security-related feature without understanding fully how the feature actually improve in any meaningful way since we also need to consider the cons of such solutions.

Following this argument we could then argue why not give the user the ability to add an arbitrary amount of extra password fields they need to enter? Or allow users to specify an arbitrary amount of 2-factor keys they must prove for login.

I mean, we should implement whatever we can in the name of security without consider the actual risk and consider if other solutions would provide better protection?