Can Facebook provide postmortems on their iOS SDK crashes? | Hacker News Reader

Can Facebook provide postmortems on their iOS SDK crashes?

github.com

204 pointsAustin_Conlon97 comments

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.

[1] Squawk - Walkie Talkie for Teams https://www.squawk.to

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

As a user with a $19/year Google One subscription, I find Google support quite easy to reach.

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).

Yeah, good luck with that button after they've pushed theirs first.

But will they still treat you that way after an errant classifier puts you in the wrong bin?

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 popular because it massively reduces signup friction which results in higher conversion rates

does it tho? I know that is the sales pitch but is that really the case in 2020 with facebook's login?

Yes. HN isn’t real life. Billions of people still use FB.

the visitors for work definitely aren't from HN. It had such a little affect on conversions and sign ups it was later removed.

Agreed. Email/password login can end up being less privacy conscious because they might sell your email and store your pws in plaintext

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).

What about https://www.keycloak.org/? Is it any good for such solution to half-own OAuth provider?

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.

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.

oh alright... I thought there was more to it.

Debatable. You could implement the login with Google/Facebook/... APIs and not use their official clients, but many companies don't bother.

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#iss...

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

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.

> banking sites that partially obfuscate your username really confuse them)

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.

> 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.

How does a website control autofill if the password manager extension does it?

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.

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.

Do password managers work inside native apps? That's the number 1 place I use sign in with Google/Apple.

There's an accessibility service that my password manager installs that allows it to autofill native apps.

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?

You can lose your data you put to the service, obviously, if someone can get over the broken oauth implementation.

What use does an app developer have for your password to their own service?

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.

Seems like they're using it on all of their websites.

So what if you choose to mask your email?

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.

No different than Google sign in while having a hardware ecosystem

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.

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/

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.

Then it'll be ironic if an antitrust lawsuit turns into court ordered or legislative wins for user privacy and data-property.

What happens to all your connections if you stop owning Apple devices?

Sounds like a nice way to keep you locked into a very expensive ecosystem.

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.

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

> 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.

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.

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.

Because everything is a tradeoff, and often having a good conversion rate is higher on your priority list than a lot of other things...

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!

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.

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.

>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.

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.

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.

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?

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 wonder how easy it would be to spoof a "login with facebook" flow on a mobile app.

Can't be that hard.

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.

But how do I, as a website-user, know who I'm telling my credentials?

I mean, it is rather obvious if one has taken the time to go through such a flow (or even to just look at screenshots of how it works).

You can check the address bar and TLS certificate.

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"

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.

Block all of AS32934.

Pi-Holeing your home network doesn't help with this issue unless you never go outside, in which case why do you even have a phone?

Here's an equivalent you can take with you.

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: https://apps.apple.com/app/apple-store/id1126386264 https://adguard.com/en/blog/adguard-pro-is-back.html

Pi-Hole + wireguard works really well.

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.

> treat the web like a hostile environment

The failure wasn't on the web, it was on iOS.

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.

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.

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.

(That’s the old crash.)

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

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.

Question.

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

  <key>FacebookAutoInitEnabled</key>
    <false/>

disables auto init. Couldn't this potentially eliminate all FBSDK-related startup/non-interactively-caused crashes?

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

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

Reply on news.ycombinator.com