8 ms·

Can Facebook provide postmortems on their iOS SDK crashes?

204 points by Austin_Conlon 6y ago

bgdam 6y ago
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?
- shaggyfrog 6y ago
  You answered your own question. 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.
  - zumachase 6y ago
    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.
- cocoflunchy 6y ago
  Because everything is a tradeoff, and often having a good conversion rate is higher on your priority list than a lot of other things...
- zumachase 6y ago
  > 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. [1] Squawk - Walkie Talkie for Teams https://www.squawk.to https://www.squawk.to
  - sargun 6y ago
    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.
    - KiwiJohnno 6y ago
      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
      - pcr0 6y ago
        As a user with a $19/year Google One subscription, I find Google support quite easy to reach.
        catalogia 6y ago
        But will they still treat you that way after an errant classifier puts you in the wrong bin?
- gnur 6y ago
  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!
- gruez 6y ago
  >simply in order to have a slightly easier login flow? Apparently you also need it if you want correct attribution for facebook ads, so the marketing dept might want it as well.
- vmception 6y ago
  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.
  - AlexandrB 6y ago
    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.
    - vmception 6y ago
      Then it'll be ironic if an antitrust lawsuit turns into court ordered or legislative wins for user privacy and data-property.
    - sebastien_b 6y ago
      Yup, they’ve introduced APIs in iOS 14 to make it easier to convert a regular login to “Sign in with Apple”: https://developer.apple.com/videos/play/wwdc2020/10666/ https://developer.apple.com/videos/play/wwdc2020/10666/
      - toomuchtodo 6y ago
        As an Apple ecosystem user, I’m very much looking forward to Sign In with Apple replacing most of my password manager entries. I want a one click “upgrade” path from email/password to Apple managing the auth.
  - rubber_duck 6y ago
    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.
- wonnage 6y ago
  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!
  - ffpip 6y ago
    They still get your email with SSO. And name, profile pic too. Which they don't via the normal method. With SSO via Google, FB, you have to agree to share data with them.. email is a thousand times better
    - lstamour 6y ago
      That’s not true of Apple which means it’s not true of all SSO. Sometimes users are offered a choice of claims. It’s allowed, just rarely implemented.
    - dan15 6y ago
      > With SSO via Google, FB, you have to agree to share data with them Not sure about Google, but with FB you can choose which information to share with the site.
  - sebastien_b 6y ago
    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.
    - lstamour 6y ago
      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.
- creato 6y ago
  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.
  - Larrikin 6y ago
    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.
    - zmer 6y ago
      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.
    - creato 6y ago
      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.
      - 6y ago
- AlexandrB 6y ago
  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).
  - oblio 6y ago
    Debatable. You could implement the login with Google/Facebook/... APIs and not use their official clients, but many companies don't bother.
    - yoavm 6y ago
      It's apparently forbidden to implement the API directly without using the SDK when developing a native app. https://github.com/facebook/facebook-ios-sdk/issues/1385#issuecomment-656702268 https://github.com/facebook/facebook-ios-sdk/issues/1385#iss...
  - akerro 6y ago
    What about https://www.keycloak.org/ https://www.keycloak.org/? Is it any good for such solution to half-own OAuth provider?
    - X-Istence 6y ago
      If you are an enterprise and need to set up some way to do OpenID Connect/Oauth2/SAML 2... yes. But I would not use it in a consumer facing product.
      - random_kris 6y ago
        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
- mschuster91 6y ago
  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.
- mgraczyk 6y ago
  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. https://hunches.app/login https://hunches.app/login
- jackewiehose 6y ago
  I never understood "Login with ..." from a user-perspective. I'm supposed to enter my facebook/google login-credentials on some random website? How does the user know its legit?
  - hn_throwaway_99 6y ago
    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.
    - jackewiehose 6y ago
      But how do I, as a website-user, know who I'm telling my credentials?
      - sp332 6y ago
        You can check the address bar and TLS certificate.
        jackewiehose 6y ago
        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.
        sp332 6y ago
        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?
- orasis 6y ago
  Most of us app developers don’t use it for login, we use it to optimize Cost Per Install campaigns when we advertise on a Facebook property.
- deleted 6y ago
  [deleted]
- kochthesecond 6y ago
  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).
  - deleted 6y ago
    [deleted]
- xenospn 6y ago
  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.
- deleted 6y ago
  [deleted]
kevin_b_er 6y ago
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.
- onion2k 6y ago
  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.
  - kevin_b_er 6y ago
    Apple could ban the hooking trick the SDK uses to run w/o an initialization call and prevent app updates. Then either FB fixes their nonsense or developers remove the SDK.
swagonomixxx 6y ago
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"?
- justinclift 6y ago
  Although it's speculation, the observed behaviour matches what would happen if some depended-upon HTTPS certificate expired or was revoked. eg the mass Digicert EV cert revocation on Saturday
- geofft 6y ago
  The backtrace in https://github.com/facebook/facebook-ios-sdk/issues/1374 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.
  - saagarjha 6y ago
    (That’s the old crash.)
ObsoleteNerd 6y ago
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)
- dvt 6y ago
  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.
  - harry8 6y ago
    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"
  - Wingman4l7 6y ago
    People cried out warnings against Apple's walled garden ecosystem. Nobody listened. It's for your own good, they said. It will protect you, they said.
- jonny_eh 6y ago
  > treat the web like a hostile environment The failure wasn't on the web, it was on iOS.
person_of_color 6y ago
I’m saddened that an app just completely disappears with no dialog to the user during an unhandled exception...
exikyut 6y ago
Question. In https://github.com/facebook/facebook-ios-sdk/issues/1373#issuecomment-625092730 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#issuecomment-656656106 https://github.com/facebook/facebook-ios-sdk/issues/1427#iss..., someone mentions that <key>FacebookAutoInitEnabled</key> <false/> disables auto init. Couldn't this potentially eliminate all FBSDK-related startup/non-interactively-caused crashes?
tannhaeuser 6y ago
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.
- judge2020 6y ago
  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.
jeffrallen 6y ago
Not while Github is down, they can't...

204 points by Austin_Conlon 6y ago

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?

shaggyfrog 6y ago
You answered your own question. 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.
- zumachase 6y ago
  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.
cocoflunchy 6y ago
Because everything is a tradeoff, and often having a good conversion rate is higher on your priority list than a lot of other things...
zumachase 6y ago
> 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. [1] Squawk - Walkie Talkie for Teams https://www.squawk.to https://www.squawk.to
- sargun 6y ago
  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.
  - KiwiJohnno 6y ago
    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
    - pcr0 6y ago
      As a user with a $19/year Google One subscription, I find Google support quite easy to reach.
      - catalogia 6y ago
        But will they still treat you that way after an errant classifier puts you in the wrong bin?
gnur 6y ago
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!
gruez 6y ago
>simply in order to have a slightly easier login flow? Apparently you also need it if you want correct attribution for facebook ads, so the marketing dept might want it as well.
vmception 6y ago
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.
- AlexandrB 6y ago
  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.
  - vmception 6y ago
    Then it'll be ironic if an antitrust lawsuit turns into court ordered or legislative wins for user privacy and data-property.
  - sebastien_b 6y ago
    Yup, they’ve introduced APIs in iOS 14 to make it easier to convert a regular login to “Sign in with Apple”: https://developer.apple.com/videos/play/wwdc2020/10666/ https://developer.apple.com/videos/play/wwdc2020/10666/
    - toomuchtodo 6y ago
      As an Apple ecosystem user, I’m very much looking forward to Sign In with Apple replacing most of my password manager entries. I want a one click “upgrade” path from email/password to Apple managing the auth.
- rubber_duck 6y ago
  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.
wonnage 6y ago
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!
- ffpip 6y ago
  They still get your email with SSO. And name, profile pic too. Which they don't via the normal method. With SSO via Google, FB, you have to agree to share data with them.. email is a thousand times better
  - lstamour 6y ago
    That’s not true of Apple which means it’s not true of all SSO. Sometimes users are offered a choice of claims. It’s allowed, just rarely implemented.
  - dan15 6y ago
    > With SSO via Google, FB, you have to agree to share data with them Not sure about Google, but with FB you can choose which information to share with the site.
- sebastien_b 6y ago
  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.
  - lstamour 6y ago
    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.
creato 6y ago
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.
- Larrikin 6y ago
  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.
  - zmer 6y ago
    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.
  - creato 6y ago
    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.
    - 6y ago
AlexandrB 6y ago
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).
- oblio 6y ago
  Debatable. You could implement the login with Google/Facebook/... APIs and not use their official clients, but many companies don't bother.
  - yoavm 6y ago
    It's apparently forbidden to implement the API directly without using the SDK when developing a native app. https://github.com/facebook/facebook-ios-sdk/issues/1385#issuecomment-656702268 https://github.com/facebook/facebook-ios-sdk/issues/1385#iss...
- akerro 6y ago
  What about https://www.keycloak.org/ https://www.keycloak.org/? Is it any good for such solution to half-own OAuth provider?
  - X-Istence 6y ago
    If you are an enterprise and need to set up some way to do OpenID Connect/Oauth2/SAML 2... yes. But I would not use it in a consumer facing product.
    - random_kris 6y ago
      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
mschuster91 6y ago
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.
mgraczyk 6y ago
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. https://hunches.app/login https://hunches.app/login
jackewiehose 6y ago
I never understood "Login with ..." from a user-perspective. I'm supposed to enter my facebook/google login-credentials on some random website? How does the user know its legit?
- hn_throwaway_99 6y ago
  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.
  - jackewiehose 6y ago
    But how do I, as a website-user, know who I'm telling my credentials?
    - sp332 6y ago
      You can check the address bar and TLS certificate.
      - jackewiehose 6y ago
        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.
        sp332 6y ago
        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?
orasis 6y ago
Most of us app developers don’t use it for login, we use it to optimize Cost Per Install campaigns when we advertise on a Facebook property.
deleted 6y ago
[deleted]
kochthesecond 6y ago
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).
- deleted 6y ago
  [deleted]
xenospn 6y ago
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.
deleted 6y ago
[deleted]

kevin_b_er 6y ago

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.

onion2k 6y ago
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.
- kevin_b_er 6y ago
  Apple could ban the hooking trick the SDK uses to run w/o an initialization call and prevent app updates. Then either FB fixes their nonsense or developers remove the SDK.

swagonomixxx 6y ago

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"?

justinclift 6y ago
Although it's speculation, the observed behaviour matches what would happen if some depended-upon HTTPS certificate expired or was revoked. eg the mass Digicert EV cert revocation on Saturday
geofft 6y ago
The backtrace in https://github.com/facebook/facebook-ios-sdk/issues/1374 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.
- saagarjha 6y ago
  (That’s the old crash.)

ObsoleteNerd 6y ago

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)

dvt 6y ago
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.
- harry8 6y ago
  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"
- Wingman4l7 6y ago
  People cried out warnings against Apple's walled garden ecosystem. Nobody listened. It's for your own good, they said. It will protect you, they said.
jonny_eh 6y ago
> treat the web like a hostile environment The failure wasn't on the web, it was on iOS.

person_of_color 6y ago

I’m saddened that an app just completely disappears with no dialog to the user during an unhandled exception...

exikyut 6y ago

Question. In https://github.com/facebook/facebook-ios-sdk/issues/1373#issuecomment-625092730 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#issuecomment-656656106 https://github.com/facebook/facebook-ios-sdk/issues/1427#iss..., someone mentions that <key>FacebookAutoInitEnabled</key> <false/> disables auto init. Couldn't this potentially eliminate all FBSDK-related startup/non-interactively-caused crashes?

tannhaeuser 6y ago

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.

judge2020 6y ago
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.

jeffrallen 6y ago

Not while Github is down, they can't...