← Back to context

Comment by Arcuru

7 hours ago

If a service offers "Login with Google/Apple/Facebook/etc" you should never do that if they offer a username/password. It just increases the single point of failure. Avoid places that only offer the "Login with Foo" if at all possible (looking at you Tailscale).

As an ex-googler, the only reason I was comfortable keeping even my personal email there was because I could reach out internally if there was a problem. I left Google, and left gmail behind too.

One of the other articles on HN's front page right now, is that Germany's implementation of eIDAS will require a Google or Apple account.

  • I genuinely feel like there is something happening where hackernews articles come in bunch/reference-to-each-other :]

    So one of the comments on one hackernews post on front-page almost somehow always refer to something within a hackernews post on the same front-page. I have seen this witnessed too many times that it might be time to name this phenomenon.

We offer Login with Google and Login with Facebook on our apps. The fun part is both FB and Google started blocking Selenium and any other automated agents from logging in. So basically there's no way to run end to end tests that confirm the login flows using FB or Google, which have wrinkles that our normal login doesn't hit.

  • > We offer Login with Google and Login with Facebook on our apps.

    This has the nefarious side effect of allowing Google or Facebook to track people across the Internet and apps. Webmasters like you are, often for no imperative reason, complicit of this by providing such login options.

    • This is an issue that regulators need to address. Asking small businesses to forego the significant impact on their business of not implementing common features that users demand is not a good solution to public policy failures.

      I don’t know what the exact revenue/growth difference is, but if my paycheque depended upon getting more users to sign up, I don’t think I could justify making it into a political stance when Google isn’t going to notice my tiny boycott.

    • “For no imperative reason”

      App developers have repeatedly stated that offering those options increases user account creation. There is lower friction to using “login with <big tech>” than to create username/password creation flow. My guess is that most of the world hasn’t figured out a password manager workflow that works for them (or they aren’t willing to pay for it).

> Avoid places that only offer the "Login with Foo" if at all possible (looking at you Tailscale).

Tailscale is the only serious company that I can ever recall offering /only/ third party login. It's bit bizarre on the face of it. Anyone know the reason?

  • I think I read somewhere (but could be wrong) that it was because they didn’t want to own any “authentication” services. Their infrastructure was zero trust (as in they don’t hold any passwords or private keys), just a discovery server for different devices.

  • I use my own OIDC connection to Tailscale. I don't use a third party for login. It's not hard to set up.

  • Curious isn't it, especially as it's such a bad fit for their product - authenticating with GitHub in order to ssh made the whole thing so much more painful than it needed to be. I subsequently tried switching to using a passkey when that became an option, but it's not possible to make the passkey user the owner of a tailnet created by a GitHub org user, so I'm stuck with two users in my Tailscale and can't delete the GitHub org user. It's the main thing that keeps me looking for a reliable alternative to Tailscale.

  • My other annoyance lately is companies that don't let you set a password. It's either passkey only (which I'm not sold on, yet), or "we'll email you a login link". Great, now I have to wait for the email to show up, click the link, hope it doesn't expire if I get distracted while waiting, and then also delete your emails, sometimes multiple times a day?

    What a shit tier authentication mechanism.