The big Facebook crash of 2020 and the problem of third-party SDK creep

UPDATE JUL 10, 2020: It has come to my attention that implementing the Facebook login flow without using their SDK is against their terms of service for third-party applications, further confirming that Facebook is more interested in gathering data about an app's users than it is in providing a useful service (shocker).

NOTE: I know we’re not living in the best time of our lives right now. If you're the type of person who worries about their privacy and security online, this post may cause you anxiety.

May 6th, 2020. It was 8 pm, I had just finished work for the day and was about to order dinner from one of my favorite places when the app I use for that simply wouldn’t launch. It crashed on launch every single time.

I happen to have a friend who works on that app’s engineering team, so I sent them a video of the issue just to make sure it was on their radar, when I was told it was actually a problem with the Facebook SDK and that it was crashing many other iOS apps as well. So I tried launching TikTok, and it crashed. Spotify, crashed. The app I work as a contractor for, crashed. It was bad.

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.com domain (and all of its subdomains) on my network using Pi-Hole. I wasn’t going to starve because of Facebook.

The big SDK problem

You know how people are saying these days that it’s dangerous how companies like Apple and Google control their ecosystems, to the point of accusing them of monopoly? I’m not going to dismiss that completely here, but I think we have a much bigger problem that’s been lurking in our apps for several years, unnoticed: third-party SDK creep.

It’s quite possible that every single app you use on any particular day is running code from Facebook, Google and other data-gathering and data-mining companies. Because of the way this code is integrated — by linking to a dynamic library at build time — it means these companies can effectively control those apps, or worse, access all of the data those apps have access to.

We saw a demonstration of this power yesterday: it was as if Facebook had an “app kill switch” that they activated, and it brought down many of people’s favorite iOS apps — Apple’s appocalypse video never felt so real. Of course it was a bug and not something done intentionally, but it highlights the point that they do have control over apps that include their code.

Even if you don’t sign in with Facebook in a particular app, the app will run Facebook’s code in the background just for having the SDK included. You don’t need a Facebook account for it to track you either, they can track people very well without one.

The technical solution

There are some technical workarounds which could be applied to this problem. It’s clear that many people want to use Facebook as a login method, so “just remove it” is not as easy as it might seem. The same thing goes for “Just implement Sign in with Apple”. Whenever someone starts a phrase about programming with “just”, any senior developer’s eyebrows rise.

The first solution would be for developers to implement features such as Facebook login without employing their SDK. Facebook even offers documentation on how to do that. Implementing the login flow without using their SDK would ensure that only users who actually log in with Facebook get their data processed by Facebook.

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.

Having analytics SDKs isolated from main app code would prevent those SDKs from slurping user data without the app explicitly sending it to the SDK, it could also be used to implement some form of permission dialog. Imagine launching an app and seeing a prompt that reads “This app would like to send your location to Facebook. Is that ok?”.

It’s not a matter of developers just being careful with what SDK code they call. Yesterday’s problem would happen to an app even if it just included the SDK, even if it never called any methods on it.

The cultural solution

Many people rush to blame engineers for these types of problems. “Of course it’s the engineers’ fault: they included the SDK after all, didn’t they?”.

Even though it was technically an engineer who programmed the SDK into their company’s app, those types of decisions are usually top-down. Someone over at marketing decides they want better analytics on their Facebook campaigns, they talk to the product people and the product people just order that from the engineers.

And that’s where the problem is. This type of decision must go through engineering — and preferably someone from infosec as well — the marketing department shouldn’t have the power to mandate that random third-party code be added to an app.

Unfortunately, I don’t see this changing any time soon, so I believe the solution will have to be technical.

Let’s see what WWDC brings this year.