Facebook SDK Causes Crashes
Multiple iPhone and iPad users are seeing their apps crashing at launch as of this afternoon, and the issue appears to be caused by a faulty Facebook SDK that the apps are using.
[…]
Multiple developers on GitHub have attributed the problem to a Facebook software development kit used by the apps for sign-in purposes. Apps are failing to open even when users do not use the Facebook login options included.
Due to a major increase in crashes across the iOS ecosystem caused by an issue with a popular iOS SDK, iOS crash processing in Crashlytics was disabled at 11:00 PM UTC.
So many crashes that it brought down the crash reporter.
To stop crashes from the Facebook SDK, some devs tried commenting out any code that calls Facebook. Nothing worked.
It turns out that by just including the SDK with your app, Facebook runs hidden code on launch. (FBSDKApplicationDelegate.m)
The issue was caused by some bad data being sent by Facebook’s server to their SDK, which caused code in the SDK to crash, which in turn brought down the app that was running the SDK. Since this happened during the initialization of the SDK — something that occurs right after launching the app — the apps simply became unusable. You can read more about it here.
I did find a workaround that allowed me to order dinner though. Since the crash was caused by data sent by Facebook’s servers, I blocked the
facebook.comdomain (and all of its subdomains) on my network using Pi-Hole.[…]
The other solution would be some form of sandboxing that isolates this type of SDK from the main app code. Apple’s operating systems already have and use XPC extensively — and iOS supports extensions — but it still doesn’t expose such functionality to developers.
The flagship mobile apps from Google, Spotify, Apple, NYT, Venmo, Walmart and many other huge companies all broke for about 30 minutes.
[…]
Done right, open source is magic. It gives coders super powers to build things they could never do alone. But it can also be a strategy that makes huge parts of our online experience dependent on a few companies, and vulnerable to their choices. The failure that millions of people experience today was just (“just”) some apps crashing for a little while. A few weeks ago, it was Zoom using a Facebook library that sent data in ways they didn’t disclose. We don’t have a cultural fluency in how to talk about the interconnectedness of all the tech around us.
Apple and Google use the Facebook SDK?
Facebook themselves are no dummies. None of their iOS apps ever break because of a bug from Google or Adobe, because they’re not foolish enough to bake in a dependency they don’t control.
Previously:
Update (2020-05-14): ethanhuang13:
FacebookAuth is for iOS app developers who need to support Facebook login but don't want to use the official SDK.😒
Single closure API. ~100 loc of implementation.
On the one hand, bugs happen. Massive bugs happen, too. Think of ones where Apple’s Unicode decoding crashes and you ultimately can’t launch iMessage even more, or even worse, Springboard won’t even come up because it keeps trying to show an iMessage notification.
OTOH, while I’m not that well-versed on typical practices in the iOS world, a library silently running code at launch seems like something to be avoided, especially in this context where it comes up as slightly creepy. It’s a trade-off between “just drop in the library and it works out of the box”, I get that, but still… FBSDK should have something like
InitFacebookSDK();
that’s mandatory to call on startup. Other benefits include more deterministic behavior: it’s clear when the SDK has successfully launched and when it hasn’t yet.
That doesn’t sound right to me. Also, what’s a “flagship mobile app from Apple”?
But also, I generally don’t understand what Anil is getting at with the OSS framing (and the promote-his-company framing is even stranger). If FBSDK is such a great open-source project, why has nobody looked at the source and noticed that it silently does stuff on startup? Why has nobody changed that?
What he’s really arguing is “it’s great that developers make libraries for each other, and many times, you don’t even have to pay for them”, but as far as community goes, this is a failing of OSS. (Or, perhaps arguably, a subversion of the OSS spirit by Facebook corporate.)
I get Gruber’s point, but it’s only partially true. I doubt that the Facebook app is free of dependencies they don’t control. For starters, it surely has a massive dependency on Cocoa Touch. But also, lots of further stuff in there. If, say, BoringSSL has a bug, Facebook is quite likely to be affected.