Taking HN thread replies or users as a sample for anything is almost never a good idea.
Even in this thread there's a split between people who can replicate it and people who can't, so it's more likely an edge case and not a global issue affecting all Google SSO implementations.
> Even in this thread there's a split between people who can replicate it and people who can't
I don't think "even the buggy behaviour is not reliably reproducible" is really the selling point you should be touting, if your claim is that Google "does it better".
I can't reply below yours, so I'll add this:
> The point is that globally rolled out solution that billions of users use every day and companies depend on is obviously better tested, better monitored, fixed quicker, more accessible than a one-off handcrafted solution for most use cases and companies where that is not their core competency.
None of those things are obvious, and the original topic of this is from the context of a software developer, that also offers their own direct "email + password" sign in option, so clearly the monumental task of storing a password, and offering password resets is not too much for them.
Your claim that large companies do things "better, obviously" is honestly laughable.
The point is that globally rolled out solution that billions of users use every day and companies depend on is obviously better tested, better monitored, fixed quicker, more accessible than a one-off handcrafted solution for most use cases and companies where that is not their core competency.
Even in this thread there's a split between people who can replicate it and people who can't, so it's more likely an edge case and not a global issue affecting all Google SSO implementations.