It seems Facebook mandates the use of the SDK if apps wish to provide 'Login with Facebook' functionality. My question is this - Why would any company include this SDK, which is basically spyware into their apps, simply in order to have a slightly easier login flow? Is implementing a user authentication system really so complicated, that you guys think it is okay to give away control of your users, and even your app's ability to even startup without crashing, to a third party company over whom you have no control, who has no obligation to not break your app at their whim?
> Why would any company include this SDK
> Is implementing a user authentication system really so complicated
"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[1] 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.
Personally I use login with Google because:
1. I “trust” google auth - I know they won’t store passwords in plaintext or anything funny like that
2. It’s a centralized place I can use to rotate my keys
3. I can revoke accounts
Signing up via email on each site means a password manager entry at a minimum, and probably no 2FA, or brute force resistance.
I never use login with Google, because if one day some automated process decided to suspend my account then I'd also lose access to all other systems I was using Google for authentication.
You're basically at the mercy of getting hold of google's nearly nonexistant support to get this resolved
Unless you get auto-suspended and end up receiving non-answers as explanations until you drum up enough twitter attention for a non-outsourced support employee to revert the decision and say "We identified an error that automatically suspended your account and have resolved the issue" a week of frustration later.
I also pay $dollars/year for Google. Turns out, when you start paying people money, and it becomes a legal liability for them to screw up, they act...better?
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).
We know Facebook uses data they gather for competitive product reasons. I wonder how important Facebook’s insight into signup and login auth for upstart products (like TikTok or fortnite) was for internal intelligence on where the wind is blowing / compete / acquire targets.
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.
It's interesting how modern tech companies took Microsoft's "Embrace, Extend, Extinguish" playbook and ran with it. OAuth was supposed to be a standard that allowed interoperability but instead each company enforces the use of their own OAuth SDK/variant (see also Login With Apple).
Can you clarify why not and what would you recommend?
I am java developer who is developing side project which is using keycloak for user management.
I find it awesome I can plug invarious oath providers (fb, google etc...) While still using my own registration workflow.
Quite easy to plug it in my project as well
Ah, if you are using Java it is probably easier to use/develop for. One of the issue I've found is that the REST API is not well documented at all, and using it from an app perspective is not intuitive at all when you are trying to use it from applications that are not Java based.
My websites have traditional email+password signup forms with Facebook and Google singup buttons beneath the form fields. Over 50% of new users use the social buttons instead of email.
Speaking as a user, I strongly prefer OAuth login whenever possible, so I don't need to manage a new account. I trust the security of big players like Apple, Google, etc. a lot more than random app/website developers. There is some range of value (to me) of services where I will be willing to log in/sign up with an existing OAuth account, but I will not bother if I have to make a new account.
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.
What security do you get from them that you don't get from a password manager and a random password for every service? I specifically avoid all external OAuth flows for my personal accounts because there is almost always an extra data grab associated with it.
Password managers have a few problems. Sometimes they just don't work well (e.g. banking sites that partially obfuscate your username really confuse them). Sometimes websites make it hard to copy and paste passwords. Apps don't always work with password managers, requiring manually retrieving the password. But mainly, password managers are inherently a bit scary as a single point of failure. You might say that OAuth has the same problem, but I think it's better because no passwords are stored anywhere (even if encrypted), and I use a hardware 2FA key for my preferred OAuth account.
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.
It seems like when websites are just janky and/or non-standard, password managers struggle to understand what fields are username/password fields, or whether it is a login vs. signup vs. password reset form, etc.
To me, installing weird one-off extensions is a far bigger surface area of risk than just using OAuth.
I agree. Given randomized passwords I don't see any risk with individual sign-ups rather than login partners. I will not sign up for a site/service if it only uses login partners for authentication.
I don't know the details of what is going on here but it sounds very sketchy. I vastly prefer an OAuth login to installing a native app, let alone one that appears to have very deep system access, and access to all my passwords at the same time.
Using the Lastpass accessibility service on Android only works about 40% of the time for me.
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.
Do you realize you still have to trust the developer implemented their side of oauth correctly? It's not like Google is sending engineers to every implementor to verify that.
Well I don't give the app developer my password, and Google limits the information that they can get about my account on their end. What could a malicious or incompetent app developer do to my Google info?
Facebook SSO is extremely convenient for the end-user: most people have an FB account and it's literally three clicks tops to get logged in, vs manually filling out a registration form, thinking of/remembering a password, confirming the email address...
Also, it cuts down on support requests of the type "can you reset my account password?" / "can't login" massively.
Login with Facebook tremendously reduces friction on signup. We get a verified email that we can trust, the name of the customer and a profile photo that automatically renews. But even more important we dont need to ask for a password.
We can also ask for more, such as phone number (we dont ask).
Login with Apple is coming for them, don't worry. Only a matter of time before Apple makes that even stricter and more dominant. I doubt Facebook's argument to the antitrust board will be compelling as Apple masks login data for the app and data broker, while Facebook only wants to aggregate it.
> Login with Apple is coming for them, don't worry
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.
I definitely agree with you that this is not a good thing and that Apple is pulling a 100% certifiable dick move by doing this. Who in their right mind would want to implement an email authentication method that just paid out 100k because someone found out they weren't actually authenticating emails. I mean come on... I'd love to see Apple eat their own dog-food on this one and then we could see if it's really ready for prime time.
As someone who uses Apple products occasionally (currently on MBP, used iPhones in the past) I doubt I would switch even if I went all in on the Apple ecosystem again. Their devices and software have annoyed me in the past to the point where I made the switch - anything Apple specific like this makes it a PITA move to a different platform.
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.
I fear Login with Apple is another poison pill. Sure it's better than some of the current alternatives, but if it's suddenly in Apple's best interest to abuse their position for data gathering, they will.
On the flip side, people used to argue for SSO as a privacy/security feature - rather than sharing your email and creating passwords with every site, just let a trusted intermediary like Google/Facebook handle those nasty details!
Just use single-correspondent mail addresses for signing up, i.e. weirdwebsite-myname@example.org and strangesite-myname@example.org (using a hyphen instead of a plus sign to get past unhelpful mail address sanitizers), add a regex for * -myname to /etc/aliases and you're set. You don't need to set up special addresses, the regex alias will make sure the mail ends up in your INBOX. I've done this for more than 20 years without being inundated in spam, I never use my 'real' address for interaction with others than friends and family.
But doesn’t that mean if it gets compromised (which I think one popular one did a while back?), then you’re basically screwed for every site you used it with?
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.
This is why FIDO2 is considered a strong alternative to SSO, and, in some cases, persistent session cookies. That said, the likelihood of a site getting compromised is a lot higher than the odds of, say, Google getting compromised. And Google could just deny your logins on unfamiliar devices. Which would cause other problems, but is more likely to happen with Google doing the authentication than at a small random site that doesn’t know what devices I regularly use to begin with. There’s always trade offs of course.
I'm pretty sure it's not about it being hard to implement, but also about reducing friction to sign up/in.
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!
I'm really regretting including their SDK in my code, but I have too many users who have already logged in with FB to migrate away, and I can't take away that functionality since some people need to log back in/switch phones, etc.
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.
I think this is pretty myopic. As someone who straddles both sides of this, the world is not that simple.
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.
That's the whole point of OAuth - you don't enter your credentials on "some random website", but you only have to enter your credentials on the identity provider's site. Frankly I trust Google and Facebook to keep my credentials secure a lot more than some random website.
I can do that as a professional. But even I don't trust
popup-windows for google/facebook/mybank opened from another
website.
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.
So maybe an app could send a request to Apple, then require you to open a new window and log in to the Apple site, navigate to an apps request page, find the right request, allow it, then go back to the original app. Or maybe copy a really long string and paste it, then copy the response and paste it back into the app. But you can see why no one did it this way right?
Facebook doesn't care. Apple doesn't care (enough to block/punish Facebook). These days the only answer is to treat the web like a hostile environment and protect yourself from malicious companies like Facebook, intent on deploying spyware and ruining the user experience in exchange for more data to profit from.
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)
This is so true (and so sad). The web is no longer everyone's playground. If you want to play, you play by Apple's rules, or by Facebook's rules. This is a double-edged sword, because it was, after all, Apple's way that gave way to the phone app renaissance of the 2010s.
Nokia n770 was mostly there. n900 was there. If we'd stuck with that as an alternative instead of having microsoft kill it all smartphones would be so much better. A real aternative that didn't suck and treat users as product really would have slowed if not prevented the ios v android race to the bottom of user hostility.
Which does one think is worse? Apple or Google? Becuase there's no way either of those are in any sense "good"
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.
Considering the SDK is setup to run, and crash, with just being linked in and not even a single call, FB should be responding.
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.
Apple should be responding. If a third party library is leading to massively downgraded performance of user's devices, Apple should be warning developers that their apps could be rejected if they don't guard against the broken behaviour.
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.
What I don't understand here is, how did this break apps that had "old" SDK versions?
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"?
The backtrace in https://github.com/facebook/facebook-ios-sdk/issues/1374 makes it sound like they passed a nil pointer to NSOrderedSet's initWithSet method, from inside FBSDKServerConfigurationManager's processLoadRequestResponse method. That makes it sound like a new version of the data provided by the server didn't have some field that old versions of the SDK expected, and the old code didn't catch that exception.
A couple years ago, after a long-winded process seeing it's inventor drop out of the process in frustration, Open ID Connect was poised to become the portable authentification/identity mechanism of choice for logging in using Fb's, Google's, and other provider's (Apple's/icloud's?) user base. I still don't fully understand what has happened to the few interworking initiatives that were created in the 2010s compared to the 2000s. I mean, using Fb and Google as identity provider has maybe its own set of issues, but the expectations we had towards tech were markedly different in that proprietary protocols were universally rejected.
Probably a business decision. Pushing devs to use the full SDK is going to ease them into using other products provided by the SDK, such as easy remarketing/ROI tracking when using the company's ad platform.
