How a Facebook Bug Took Down Your Favorite iOS Apps (wired.com) 65
An anonymous reader quotes a report from Wired: A little after 6 pm ET on Wednesday, the system started blinking red for iOS developer Clay Jones. Like many devs, Jones uses a Google product called Crashlytics to keep tabs on when his app stops working. Out of nowhere, it registered tens of thousands of crashes. It also pointed to the cause: a chunk of code that Jones' app incorporates to let people log in with their Facebook accounts. By 6:30 pm, Jones had filed a bug report about the flaw in Facebook's software development kit on GitHub, the code repository. He wasn't alone. According to widespread reports and the web monitoring service Down Detector, prominent iOS apps like TikTok, Spotify, Pinterest, Venmo, and more experienced issues on Wednesday. Many users found that they crashed whenever they tried to open the apps, whether or not they used Facebook to log in.
"Yesterday, a new release of Facebook included a change that triggered crashes in some apps using the Facebook iOS SDK for some users. We identified the issue quickly and resolved it," Facebook said in a statement. That change was quite small, given its outsized impact. "It was something like a server value -- which was supposed to provide a dictionary of things -- was changed to providing a simple YES/NO instead, without warning," says iOS developer Steven Troughton-Smith. "A change that simple can break an app that isn't prepared for it."
"Pretty much all these apps -- Pinterest, Spotify, a lot of the big ones -- use the Facebook SDK for the login button," says Jones. "You'll see 'Login With Facebook.' Everyone has it, super common, great for sign-up rates because it's just a one-click thing." And lots of apps that don't use Login With Facebook still use the SDK, which is why the issue Wednesday was so widespread. [...] The good news is that Facebook did fix the issue with haste, as far as these things go. Jones says it took about two hours for things to return to normal.
"Yesterday, a new release of Facebook included a change that triggered crashes in some apps using the Facebook iOS SDK for some users. We identified the issue quickly and resolved it," Facebook said in a statement. That change was quite small, given its outsized impact. "It was something like a server value -- which was supposed to provide a dictionary of things -- was changed to providing a simple YES/NO instead, without warning," says iOS developer Steven Troughton-Smith. "A change that simple can break an app that isn't prepared for it."
"Pretty much all these apps -- Pinterest, Spotify, a lot of the big ones -- use the Facebook SDK for the login button," says Jones. "You'll see 'Login With Facebook.' Everyone has it, super common, great for sign-up rates because it's just a one-click thing." And lots of apps that don't use Login With Facebook still use the SDK, which is why the issue Wednesday was so widespread. [...] The good news is that Facebook did fix the issue with haste, as far as these things go. Jones says it took about two hours for things to return to normal.
Changing the return type on a published API? Yike! (Score:5, Informative)
That change was quite small, given its outsized impact. "It was something like a server value -- which was supposed to provide a dictionary of things -- was changed to providing a simple YES/NO instead, without warning,"
Changing a return type from a pointer/reference/structure/etc. to a boolean, in a published API, is NOT "quite small". It's pretty much guaranteed to cause havoc in any caller.
Re: (Score:1)
Something that was quite possibly done in a oneliner is a small change. You are talking about impact, which the line you quoted already said was much bigger.
Re: (Score:3)
Pedantic argument is pedantic.
Re: (Score:2)
Re: (Score:2)
https://github.com/jsayol/left... [github.com]
No, you need to do a remote network call to left pad your string instead of just using the goddamn native language function.
All of this work, just so that people can avoid having to learn the common denominator, the language.
It's really easy to say that you're the world's greatest developer if you make sure to never write any code yourself. Any mistakes can be blamed on, "well that package didn't work right, so we'll just drop in a new one", even if you're trying to connect
Re: (Score:2)
You probably are doing it - after all, the OS provides a bunch of APIs, the libraries for your graphical environment provide more APIs, and all that. Many of those are single vendor - if someone screws up a change in say, the C library, it can keep your system from booting or at least working properly. I
Re:Changing the return type on a publishedt (Score:2)
This isn't the type of error that would get caught be a C compiler, this is a RUNTIME failure, not something that would get caught at compile time.
This is the equivalent of leaving the header files the same for a C function in a library, while changing the actual function call in the compiled library itself. Normally it returned a pointer to a struct, now it just returns an int by value. Now lets see how a C program reacts to that(not well).
In code:
Now first in the header file:
Re: (Score:2)
Re: (Score:2)
While I tend to agree with all your points, it's likely they did that testing with the apps it controls. It sounds to me like it was 3rd parties not properly handling a different return than they were expecting.
App:Give me that list of servers?
Service:YES!
App:???? (crash)
Step 3 should have been better prepared for a nonsensical answer. Isn't graceful error handling one of the pillars of using an external service?
On the other hand... (Score:3)
If you are relying on the availability of a 3rd party SDK/API to provide login functionality (or ANY functionality) you should probably have some heavy duty exception handling around that code in case anything goes wrong, as you have no real control over it.
Re: Changing the return type on a published API? Y (Score:3)
Well, when you use third party APIs you definitely account for them breaking. I validate the data structure and if it is not what I expect the user gets an error and in this case they would be told they can't use FB sign in (not that I have ever used fb stuff in anything I have developed for myself). But the app should definitely not crash on broken api responses.
Re: (Score:2)
Re: (Score:2)
This is how my boss works.
He changes, doesn't test, deploys, and waits for the customer support requests to know that his change broke something. He doesn't even communicate major breaking API changes to the team. Nope, it's straight to master and production the instant he saves his changes.
How a Facebook Bug Took Down Your Favorite iOS App (Score:3)
Re: (Score:2)
Re: (Score:2)
Congratulations on not using any of the most popular apps on the market Mr Not-Normal.
Re: (Score:2)
Popular doesn't mean good.
So congratulations indeed on not being a fuckwit, even though that's the default state of most of humanity.
Re: (Score:2)
Hell yeah! Anything I don't use is obviously stupid, and so are the people that use them.
Sure, I don't understand TikTok, but who the hell am I to begrudge someone who does? Unless you don't use a smart phone, or don't use it for anything beyond browsing the internet, I'd be willing to bet there's at least one app on there that has "login with facebook" as an option. If there's not, congrats, I guess?
Re: (Score:2)
Popular doesn't mean good.
No one is talking about how good an app is. As you having a conversation with yourself? Don't be that guy who walks into a conversation he wasn't invited to, doesn't understand, and therefore attempts to change the subject.
Re: (Score:2)
You attempted to mock someone for not using a popular app, as though being popular was in some way a good thing.
I merely pointed out one of the flaws in your statement.
If you don't want others to join your conversation then don't shout it out in public. I'm not talking to myself, I'm talking to you because you're being silly, you don't understand and I've noticed that you're now trying to change the subject.
I guess you're that guy.
Smells like modern app programming to me (Score:3, Insightful)
You can't catch an exception or fail gracefully?
Yes the data structure changed, but shouldn't you handle it similarly to the API not responding or keys revoked or all the other potential problems? All those errors may br handled differently. But if you can't hang with a 3rd party API, maybe don't depend on it?
Network services and web APIs aren't perfectly rel (Score:3)
> Yes the data structure changed, but shouldn't you handle it similarly to the API not responding or keys revoked or all the other potential problems?
You mean to tell me that generally services my app accesses over the network, and web APIs in particular, aren't perfectly reliable?
Here's something that should scare the shit out of the developers of these apps - a network attacker can make those web APIs return anything and everything they want! What you get back from a web call could be random bytes. O
Re: (Score:2)
Yes, especially over the network / internet (Score:2)
> Doesn't that apply to anything that relies on outside data?
Yes, but especially over the network.
"Internal" operations such as creating a variable CAN fail (out or memory). You're supposed to check the return value every time you do something that allocates memory, but those rarely fail.
Disk access and out-of-process, same-machine calls fail more often. Simply because there is more that can go wrong - a process other than your own could cause a problem.
Operations over the network WILL fail from time to
Re: (Score:2)
Everything is someone else's API these days, but since they haven't written any code themselves, there's no errors to check, and all the brogrammers can hit the bars.
If they wrote error checking code, that'd mean they wrote any code at all! And once you start writing code... well, just grab someone else's package off NPM, don't reinvent the wheel.
There's an API checking package for you that silently transpiles your code with Babel and wraps every statement in a try-catch-pass, so you're guaranteed to run er
Re: (Score:2)
There's an API checking package for you that silently transpiles your code with Babel and wraps every statement in a try-catch-pass, so you're guaranteed to run error-free.
I hope, for the sake of comedy, that something like this exists.
Re: (Score:2)
There are literally dozens of NPM modules that do things like this.
I wasn't referring to any one particular one, but a quick search brought up this one [npmjs.com], among dozens of other packages that do approximately the same.
Wraps files in a try/catch statement to not expose errors.
This kind of shit is why I have such a low opinion of most people pretending to be programmers.
Re: (Score:2)
Re: (Score:2)
I think one of the more offensive practices currently in vogue is the pervasive use of "options" hashes to a function. They just continue accumulating new keys and values, adding increased modes of operation to a single "function", and promote spaghetti-code like structure that we all agreed was terrible, back in the Pascal and BASIC days!
If a programmer now never had to suffer through writing line numbers (or worse, for the punch card jockies before me), they perhaps don't fully grasp how awful their code
lesson learnt ? (Score:3)
hopefully this is a teaching experience
they could use OAuth and OpenID Connect with facebook/google etc but they just want to call a library... this could bloat your app if your not using it for anything else...
use and demand open interoperable standards !
(Facebook does support them if enough people ask for it...)
perhaps someone might convince apple to use the same standard for their login...
Re: (Score:2)
That's how apps are built now. Find all the libraries that kinda do what you want and slap them all together with some duct tape code.
You don't actually think that programmers these days actually know how their programs really work deep down inside. :D
Zoom missed this? (Score:5, Interesting)
Re: Zoom missed this? (Score:3)
Say it isn't so!!!
Re: (Score:2)
Wait, what? Facebook is spying on everyone?
No, some people know how to block it.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You don't control traffic between Spotify and Facebook, and there's constant traffic between Facebook and Spotify regardless if you use the FB login.
Yeah, but who sends data to Facebook from their backend? Have you ever used these trackers at work?
Re: (Score:2)
Yeah, but who sends data to Facebook from their backend
All the sites that use their API. Let me be clear on this: Facebook and Spotify communicate all the time whether or not you use the internet. You cannot block that. The moment you visit Spotify, Spotify is sending data to Facebook on you. You can stop by 1) not using Spotify 2) blocking all traffic between you and Spotify (see #1). Either 1 or 2 means you can't use Spotify.
Have you ever used these trackers at work?
I don't "use" these trackers. The trackers may be working whether I choose to use them the moment I visit a site. At best I can opt out
Re: (Score:2)
Yeah, but who sends data to Facebook from their backend
All the sites that use their API.
No LOL. You are pretending that you know what you're talking about but you've never used the Facebook API as a programmer. It's not normal to send data to Facebook from the backend.
Re: (Score:2)
The blog post, written by product management director David Baser, is mainly about third-party websites and apps that send data about their users to Facebook (FB), regardless of whether those users have Facebook profiles.
Re: (Score:2)
Re: (Score:2)
Facebook is a cancer. Using it to log in to other services? You're just feeding the machine even more of your personal data. Don't do that.
And, yeah: Facebook has been caught (more than once, iirc) sending data to the mothership that they have no business even possessing. Really, the Facebook code probably ought to be banned as malware, or at least thoroughly sandboxed.
Re: (Score:1)
Facebook is a cancer. Using it to log in to other services? You're just feeding the machine even more of your personal data. Don't do that.
And, yeah: Facebook has been caught (more than once, iirc) sending data to the mothership that they have no business even possessing. Really, the Facebook code probably ought to be banned as malware, or at least thoroughly sandboxed.
True. A few years ago somebody at Facebook forgot to renew a cryptographic certificate. For about two days I could not go anywhere on the internet without getting a gaggle of screens complaining about that damn certificate every time I loaded a page. Turns out it was the cursed Facebook button that was causing it. What surprised me was just how widespread that thing was and it wasn't just the Facebook button either they even had a version that as completely embedded in all kinds of pages but wasn't visible
Re: (Score:2)
I was working on an integration in dev on that day and suddenly stuff started breaking in didFinishLaunchingWithOptions:
ApplicationDelegate.shared.application(application, didFinishLaunchingWithOptions: launchOptions)
This is the "hook" for the Facebook SDK that the Facebook SDK docs tell you to put in. It definitely sends an event back to Facebook about application start
Re: (Score:2)
Jesus Christ. (Score:2)
No it didn't (Score:2)
Never has, never will.
Check you return type and handle it! (Score:2)
If a boolean / string boolean was returned where a dictionary was expected, you'd notice that in the type check and handle the error with expected and predicted branching, falling back
Re: (Score:2)
Facebook had an internal problem, which is fine, but they violated the simple concept of the check the data type.
If you can't write an authentication library then you shouldn't be authenticating anything, regardless if you lev
There is no you here (Score:1)
You'd still handle the return check, regardless what library you leverage,
Not if the return check is inside the library. There is nothing to check on your side, the library is wholly at fault here.
Now there's another argument to be made that maybe you shouldn't be including a library that was not written very robustly, and no code I've seen from Facebook indicates being robust is a priority.
The main reason any app integrates Facebook login is to have easy one-click sign-in. But with Apple Login there's no
Re: (Score:2)
Imagine writing a memory manager for a RTOS, which I'm done, that couldn't alert you if memory was being allocated improperly, or if memory faults were occurring. No one would tolerate that kind of slop, so why can Facebook get away wi
If you really, really hate privacy (Score:2)
Sensible versioning (Score:1)
Even with the SDK, why wouldnâ(TM)t you have a properly scoped URI with embedded version so as to âoeprotectâ against breaking changes? So if v1 returned Boolean and v2 returned the pointer to a struct, you donâ(TM)t cause unintended consequences and allow a graceful deprecating of the old call.
This is pretty standard distribute system stuff.
Advice (Score:2)
Never use an app if there is a website that does the same thing.
Man up (Score:1)
Man up and use your own login, or perhaps Apple's.
If someone uses login mechanism of the known bad actor - and the list of Facebook's privacy scandals is longer than list of pi's decimal places - it's hard to feel pity for them if it all goes haywire.