> but I added Google Sign in to my SaaS several month ago, and since then, it accounts for more than 90% of new sign-ups (users are devs, so rather tech savvy

I do it for services I don't care about. In my mind it is more privacy for me. Keeps you out of my real inbox and my password out of your system and I believe that I can - to some extend - remove myself without having to go through whatever crap account deletion process that services has tried to cobble together.

Worst offenders let me login with google and then immediately asks for name and phone number or email and asks me to verify it.

Wouldn't privacy aware users prefer passkeys or passwords, instead of any kind of SSO?

In general, I do understand that use of SSO is due to convenience. Especially since in many cases websites provide less friction when signing up via SSO instead of using username+password.

I have my HN username at a venerable webmail service. I check it about once a year, tops. My name isn't unimaginably rare, but neither is it "Smith".

I am shocked, shocked, by the number of different K. Strauser people who have typed that email address into some random website or another. I've gotten bank notifications, loan documents, Facebook signup info, meeting minutes from some random volunteer work, and all kinds of other things. When I can figure out from context who the intended recipient is, I try to let them know so they can fix it. On one occasion, the person sent me back a swear-laden diatribe for "hacking their email". Sigh.

I think this has made me a better engineer, though. When someone says something in a meeting like "...as long as they type their email correctly", I can jump in and address that myth head-on. No, people will not type it correctly. If it's a minor pain in the neck for me, with an uncommon name, I can only imagine the traffic that the world's John Smith's get.

The number of support requests I got last year because of [hotmail|gmail|msn|yahoo].con > 30

Absolutely. Users have to wait for the email before signing in, it does not work on devices without email without copying the link, etc.

With password reset, you are also trusting email.

If you are storing sensitive information in the system, by all means, you should act accordingly and require higher-security login than magic links. But if you do, you really should not be accepting username+password either. You need to at least put some 2FA on there to step up one level of security. And not SMS- or email-based 2FA either.

90% of web apps don't handle that kind of information, and for them a magic link is at least as good as passwords (as this article explains). Those that do handle things like personally identifiable information (beyond an email address) really should be enforcing 2FA or proper electronic IDs.

There is a whole profession writing recommendations about information security, and every web developer needs to be able to do this kind of analysis at a rudimentary level. We don't need to wing it, we can analyze security requirements in a systematic way.

No, kudos to them for looking at a piece of data and asking themselves if it's worth storing—more companies should do that with more data. It's not that the rest of the data isn't valuable to some extent, it's that every piece you have makes the blast radius of a leak that much bigger, so why hold stuff you don't need?

Planning for a breach doesn't make you more likely to have one—if anything it makes you less likely!

To be fair to 404, they're trying to limit the amount of data they hold which IS good, but in the end they need to have the email address of subscribers.

In my country even the social security number of people is public information.

The UX debate is valid, but magic links (and emailed one-time codes) are clearly more secure than password + password reset. Control of the email account gets you in either way. Passwords are an additional attack vector.