"Login with Facebook" isn't popular because it saves developer time. It's popular because it massively reduces signup friction which results in higher conversion rates. These things are super important. We offer Google login with our only consumer facing app and we see a solid 40% of accounts use that method vs. email. I would venture a guess that a sizable minority, bordering on majority, of those accounts would simply never sign up in the first place without some sort of SSO.
I agree with your sentiments and frustrations, but whenever something seems to be too ridiculous to be true (as this might seem to some devs) there's often something else at play.
 Squawk - Walkie Talkie for Teams https://www.squawk.to
Signing up via email on each site means a password manager entry at a minimum, and probably no 2FA, or brute force resistance.
You're basically at the mercy of getting hold of google's nearly nonexistant support to get this resolved
I have a one-click button to download all my data from Google (which turns out to be an absolute pain because it's in the ~100s of GB range).
FB SSO isn’t really an option for an early stage consumer product, but if it were I can see Potential benefits to the products that are succeeding avoiding sharing real-time success metrics with FB.
Presumably, Apple is also influenced by data like this via the App Store.
For example Apple probably pays attention to Autosleep and other sleeping apps in deciding to build it into WatchOS.
does it tho? I know that is the sales pitch but is that really the case in 2020 with facebook's login?
But I would not use it in a consumer facing product.
That said, which one it is matters. My order of preference is: Apple, Google, more minor players like GitHub, and way at the bottom of the list, I won't use Facebook's.
I think the concern about "data grabs" is a bit overblown. I don't believe the OAuth logins that inform you of what information is being shared is lying, and if I don't like what is being shared I won't use it.
Is there a bank allowing sign in by Facebook/Google?
> Sometimes websites make it hard to copy and paste passwords.
Yes, and that's why password managers do autofill.
There are a ridiculous number of websites and apps that support neither password paste nor autofill.
Some stupid websites do block paste, but one can use an extension to force enable paste everywhere, which IMHO is required for one's sanity.
To me, installing weird one-off extensions is a far bigger surface area of risk than just using OAuth.
Over half the times I go to use it I sit there trying to trigger it a few times, then give up and have to go and copy / paste the password from the app.
Also, it cuts down on support requests of the type "can you reset my account password?" / "can't login" massively.
We can also ask for more, such as phone number (we dont ask).
That's an even greater cause for worry and I fear what will come of this, I would treat their login SDK as the same poisoned chalice that the Facebook login SDK is. Worst - they're effectively forcing app developers to introduce it if they have any kind of social login in their apps, which is an incredibly dick move. Any other company doing this would get negative attention but in our collective hypocricy we keep painting this in a positive light. It absolutely is _not_ a good thing... but this is HN.
Google isn't perfect either - there is a low but realistic chance that they could kill my account at any time with no support options and I'm looking in to ways to protect against this while retaining the benefits - but in practice switching between mobile platforms and all desktop OS-es works like a charm. I use sing-in with Facebook when Google isn't an option. I'm really not concerned with data tracking - it's omnipresent at this point - not worth the energy to think about personally.
No different than Google sign in while having a hardware ecosystem
I want a one click “upgrade” path from email/password to Apple managing the auth.
Sounds like a nice way to keep you locked into a very expensive ecosystem.
With SSO via Google, FB, you have to agree to share data with them.. email is a thousand times better
Not sure about Google, but with FB you can choose which information to share with the site.
Personally, I always use email, plus 2FA when available. I don’t trust “single” sign-ins anywhere - I’d rather control the access to the credentials myself.
I'd personally never use sign in with Facebook, but for nearly all dev related services I prefer sign in with GitHub over creating another account somewhere.
It also reduces the burden on security, you no longer have to think about where to store the usernames and passwords, how to hash them, how to compare the hashes to the plaintext password in constant time, how to prevent brute force attacks, how to prevent csrf and more. There is a reason that the sign in with X sign up flow is so popular!
Apparently you also need it if you want correct attribution for facebook ads, so the marketing dept might want it as well.
When the “business side” can claim a N% increase in conversion/daily usage/whatever having FB login, a developer will be tasked with implementing it uncritically, because if they speak up, they’ll be punished.
The “business side” doesn’t give a crap about privacy or performance or any of that stuff. They just see the numbers, especially their potential bonuses.
Late-stage capitalism, Baby.
If the "business side" as you say isn't viable, then nothing matters. This has nothing to do with late stage capitalism...this is capitalism 101. If you're not hitting critical mass, you're dead.
This take also continuously misses that most people, and thus must customers, are willing to trade privacy/performance for convenience. If that's not your cuppa, then hopefully there's an alternative.
How does the user know its legit?
On Apple though, your app might be taken down fast if you end up doing that. Doesn't mean you won't fool a few suckers though.
I prefer to educate people to only enter credentials when they
opened the website manually by themselves. That is also easier
than trying to teach someone who can't distinguish between the
address bar and the google-search field, what a domain and TLS is.
Install a Pi-Hole or similar on your network, block all FB domains. It doesn't break the web for you, it actually makes it a lot faster/nicer. Blocking Google is trickier due to core functionality of major sites depending on some of their services, but you can still block lots of it and still have a totally normal (improved) experience in your daily browsing.
(Yes, blocking all FB domains on my network stopped the recent FB bugs from crashing my apps, Spotify/etc worked flawlessly throughout that period, except when I disabled the Pi-Hole temporarily to see what all the fuss was about)
Which does one think is worse? Apple or Google? Becuase there's no way either of those are in any sense "good"
DNS66 for Android (Free, open-source): https://f-droid.org/en/packages/org.jak_linux.dns66/
AdGuard Pro for iOS, luckily back from the dead since Apple reversed their guidelines on content-blocking VPNs:
I have my wife's iPhone set up to automatically connect wireguard unless we are on the home wifi. She has no idea it's even happening. She is just happy that the Internet is always less full of junk.
The only time she had an issue was on a flight, where she was using the wifi without Internet to watch in flight movies. It was still trying to send everything over VPN and failing, so I added United's wifi to the list to not turn on wireguard, and no problems since.
Plus it means she always has access to my internal Nextcloud and Plex instances no matter where she is.
The failure wasn't on the web, it was on iOS.
Their app is clearly phoning home during the self-initialization. For a period of time it was breaking massively, then suddenly not. That means some orders from the home server were bad and causing the SDK to crash the app out. All during a secret self-initialization the developer can't temporarily take out.
The fact developers can't do anything is a good reason not to use the SDK, not just to accept the problem.
If this continues to happen regularly Apple will start taking measures to stop the problem - and banning apps is a (very unlikely) possibility.
Then either FB fixes their nonsense or developers remove the SDK.
Did some HTTP call the initialization code make end up raising an exception on some unexpected status code and end up crashing the entire application?
I don't understand why this kind of control flow is acceptable. Is it documented at least? And if it is documented, how come we can't fork this SDK (seems to be on GitHub, seems fork-eable) and remove this "feature"?
eg the mass Digicert EV cert revocation on Saturday
In https://github.com/facebook/facebook-ios-sdk/issues/1373#iss..., it's noted that FBSDK starts the in the `+load` method. I understand that's what's causing the crashes.
In https://github.com/facebook/facebook-ios-sdk/issues/1427#iss..., someone mentions that